UvA/TUD topology exchange proposal
Hello all, During the meeting in Atlanta and in several of the NSI calls the University of Amsterdam and Delft University of Technology announced that they were also preparing a proposal for exchanging topologies combined with path finding. Attached to this mail is the document describing this topology exchange, and a small discussion on how we can apply it to the NSI work. Feel free to comment and ask questions. Regards, Ralph (UvA) and Farabi (TUD) -- Ralph Koning SNE research group, University of Amsterdam Tel: +31 20 525 7928 | http://staff.science.uva.nl/~ralph
Hi Okay, deep breath. On Tue, 19 Aug 2014, Ralph Koning wrote:
Attached to this mail is the document describing this topology exchange, and a small discussion on how we can apply it to the NSI work. Feel free to comment and ask questions.
Section 1: * 1 optimal path finding on the provided topologies Could you please define optimal. (the finer point here is that network is shared infrastructure, which makes this a very complicated thing to do). Section 2: After finishing the document, I realized I had read it wrong. I thought section 2 and 3 where discussions about topology (or as it is commonly called "routing") models, but I realized later that this is just an alternative way of distributing NML. However you don't actually mention NML until section 9 (yay, a detective story), which makes the document incredibly difficult to read. Anyway, what I had hoped to find in section 2 was something like link-state vs. distance vectoring, information push vs. pull, discussion of transit, peerings, and customer connectivity and link/transit AUPs. Further the control and data plane symmetry (or lack of it) would be good to have. It would also have been nice to see some discussion of what is considered the only two successfull inter-networking protocols: BGP and SS7. Especially why they are successfull. Section 2.1: The more time I have spend with NSI topology, the more convinced I am that it is just routing, and that most of time stuff we are doing is actually 30-40 years old. Anyway, could you please list the number of successfull centralized routing protocols? Have you considered why there are none? It is not just because networks don't want to rely on a single service, but also because you cannot cram the policies of a network into a single service (there are technical, economical, political and legal reasons for this)
The topology database can also have a dedicated path finder,
No. It really cannot. We will never succeed in cramming in the policies and state of networks into a single point of decision. You cannot tell NORDUnet how to deliver data into on of their customer networks. This is an agreement between NORDUnet and the customer. Similarly, NORDUnet cannot tell their customers how to get the data to the university / research institution. You only get to hand over the data to NORDUnet at place. The sooner we kill of the notion of centralized path finders, the sooner we can start making something that can actually be used. Section 2.2:
Hence, frequent topology exchanges could be expected between domain controllers for path finding purposes.
Why? Section 2.3:
However, full disclosure of internal do- main information may pose a threat to the domain due to possibilities of attack, sabo- tage, or competitive intelligence between do- mains.
This is rather speculative. Sure commercial networks are like, but most NRENs list their topology openly.
The advantage of providing a minimized internal do- main view is that less information needs to be processed during path finding, and for safety concerns. However, insufficient topology information may lead to suboptimal path or even failure to compute paths.
Do you know how much information is exchanged via BGP? Optimal is still not defined. Section 2.4 If you mean the GNS approach, say the GNS approach.
This discloses even less topology information.
Because more is better? (scandinavian culture does not assert this btw.)
The routing is done locally, per domain, based on the information of itself and its direct neighbours leading to a locally optimal route
Like BGP? :-) (ok, BGP has AS paths, but it is also common to override MEDs, so we end up with the same thing).
It is not possible to provide a different view to the requester domain
WHAT!? Split horizon and reverse poisoning are 40 year old techniques, was used in RIP, and covered in all textbooks on routing.
malicious domains can easily provide false reachability information and break global path finding.
BGP has the same problem. It also has a solution. Section 3:
Since we believe sharing topology information provides more flexibility over sharing reachability information, we propose a hybrid approach to exchange topologies:
When you dismiss something due flaws also found in BGP it is something difficult to take it serious. Also the two models do no exclude eath other (BGP does MEDs for IPs, but still do AS-Paths for adjecency). I fail to see how the TI is more useful than a list of URLs. Sorry. The notion of foreign domains is slighly interesting though. The trust model is not listed in the section, but it looks like all-to-all. Again, I don't want to depend on your central service. The neighbour list isn't entirely clear on the data vs control plane peering issue. Section 7.6. Again. You cannot do path computation centrally. Won't fly. Sorry. Section 8: How to deal with: Complex transit policies AUP for links. E.g., some project have private links (they have a lot of traffic). These might be listed, but you can only use them if you have certain credentials. Some links have AUPs that are under NDAs. Section 9: NML isn't mentioned before this section, but the entire document is based on the NML model. Section 9.1:
Key distribution is problematic, since many developments within NSI did not focus too much on the security aspects giving no facil- ity to distribute information with end-to-end security.
And forcing all-to-all trust is much better? -- Sorry for being an ass about this. But I am tired of seeing technology first solutions (and NML and its derivatives is certainly so). Policies are much more important for finding paths than technology. BGP and SS7 is successfull because they allow policies to be expressed. For BGP, announcing different reachability to different networks, and with different priorities for where to deliver traffic, and the ability to override the latter locally. SS7 is more complicated (because telco), but interestingly enough it is circuit based. The basic model needs to allow networks to figure out they want to connect. Having user or centrally driven path finding is a pipe dream. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi Henrik, Thanks for your comments; it seems that some things are left unclear and let me elaborate on this. Naturally, we will improve the text in the next document version. As both Miroslav and me will be present at the Nordunet conference we can further elaborate and clarify the model. #0 The document is a proposal for a topology exchange - It is not a requirements document (upcoming/promised by Chin/John) - It is not a comparison of routing techniques - Chapter 2 introduces three main approaches to routing / topology exchange but doesn't describe specific implementations #1 Topology exchange != routing We distinguish between 'topology exchange' and 'path calculation'. #2 We propose an infrastructure for any type of topology documents - NML is used as an example and we think it is a good example - We use NML to exchange inter-domain topology information - Topology documents that are exchanged could represent both link-state and distance vector information. - NML might not be the right format to model link-state and distance vector(s), and NML may need to be extended to support both of them. #3 Path finding is not centralized - Every domain provider can run its own path finder which is seen as a TC - The path finding implementation we present is distance-vector but we do not mandate it. #4 Every provider can choose the level of topology information to present to the consumer - NRENs don't seem to be always 'open' in practice - Policies can be applied based on consumer - Policies can be applied on the path the consumer intends to take so this allows for peering agreements - This is done by adding/removing links/nodes/ports from the topology presented to the consumer #5 We support different levels of trust - In order to do key distribution you need to trust the TI - When using other methods for this its up to the TC and TP to decide what levels of trust to accept - The TP can provide a minimal topology when trust is low - The TP can provide a custom topology for given consumer based on key verification #6 The only centralized component in our proposal is the TI - TI is just a collection of URLs - It can be omitted if you know the TP URLs - It can notify you of updates and aid in finding TPs - You can distribute the TI #7 We say 'optimal path finding given the provided topologies' - let's define it as the solution that maximizes the given objective function based on the information (e.g. topologies, policies, etc.) known to path computation element - If the exchanged topologies are not complete this solution may not be globally optimal (in a strict sense). - we are aware that the problem is hard, and has a large state space - we present a solution to exclude certain paths, or specify the paths to be included - we assume that scheduling may become very important problem in the future of resource reservation within the networks - you can always choose to aggregate to make the problem easier (and choose your own algorithm for this) but you can not easily ask for more specific information when you are dictated by just aggregated information - sharing more topology information may provide a environment where research to new innovative routing algorithms can be done Cheers, Ralph On 02-09-14 16:11, Henrik Thostrup Jensen wrote:
Hi
Okay, deep breath.
On Tue, 19 Aug 2014, Ralph Koning wrote:
Attached to this mail is the document describing this topology exchange, and a small discussion on how we can apply it to the NSI work. Feel free to comment and ask questions.
Section 1:
* 1 optimal path finding on the provided topologies
Could you please define optimal.
(the finer point here is that network is shared infrastructure, which makes this a very complicated thing to do).
Section 2:
After finishing the document, I realized I had read it wrong. I thought section 2 and 3 where discussions about topology (or as it is commonly called "routing") models, but I realized later that this is just an alternative way of distributing NML. However you don't actually mention NML until section 9 (yay, a detective story), which makes the document incredibly difficult to read.
Anyway, what I had hoped to find in section 2 was something like link-state vs. distance vectoring, information push vs. pull, discussion of transit, peerings, and customer connectivity and link/transit AUPs. Further the control and data plane symmetry (or lack of it) would be good to have.
It would also have been nice to see some discussion of what is considered the only two successfull inter-networking protocols: BGP and SS7. Especially why they are successfull.
Section 2.1:
The more time I have spend with NSI topology, the more convinced I am that it is just routing, and that most of time stuff we are doing is actually 30-40 years old.
Anyway, could you please list the number of successfull centralized routing protocols? Have you considered why there are none? It is not just because networks don't want to rely on a single service, but also because you cannot cram the policies of a network into a single service (there are technical, economical, political and legal reasons for this)
The topology database can also have a dedicated path finder,
No. It really cannot. We will never succeed in cramming in the policies and state of networks into a single point of decision. You cannot tell NORDUnet how to deliver data into on of their customer networks. This is an agreement between NORDUnet and the customer. Similarly, NORDUnet cannot tell their customers how to get the data to the university / research institution. You only get to hand over the data to NORDUnet at place.
The sooner we kill of the notion of centralized path finders, the sooner we can start making something that can actually be used.
Section 2.2:
Hence, frequent topology exchanges could be expected between domain controllers for path finding purposes.
Why?
Section 2.3:
However, full disclosure of internal do- main information may pose a threat to the domain due to possibilities of attack, sabo- tage, or competitive intelligence between do- mains.
This is rather speculative. Sure commercial networks are like, but most NRENs list their topology openly.
The advantage of providing a minimized internal do- main view is that less information needs to be processed during path finding, and for safety concerns. However, insufficient topology information may lead to suboptimal path or even failure to compute paths.
Do you know how much information is exchanged via BGP?
Optimal is still not defined.
Section 2.4
If you mean the GNS approach, say the GNS approach.
This discloses even less topology information.
Because more is better? (scandinavian culture does not assert this btw.)
The routing is done locally, per domain, based on the information of itself and its direct neighbours leading to a locally optimal route
Like BGP? :-) (ok, BGP has AS paths, but it is also common to override MEDs, so we end up with the same thing).
It is not possible to provide a different view to the requester domain
WHAT!? Split horizon and reverse poisoning are 40 year old techniques, was used in RIP, and covered in all textbooks on routing.
malicious domains can easily provide false reachability information and break global path finding.
BGP has the same problem. It also has a solution.
Section 3:
Since we believe sharing topology information provides more flexibility over sharing reachability information, we propose a hybrid approach to exchange topologies:
When you dismiss something due flaws also found in BGP it is something difficult to take it serious. Also the two models do no exclude eath other (BGP does MEDs for IPs, but still do AS-Paths for adjecency).
I fail to see how the TI is more useful than a list of URLs. Sorry. The notion of foreign domains is slighly interesting though.
The trust model is not listed in the section, but it looks like all-to-all.
Again, I don't want to depend on your central service.
The neighbour list isn't entirely clear on the data vs control plane peering issue.
Section 7.6.
Again. You cannot do path computation centrally. Won't fly. Sorry.
Section 8:
How to deal with:
Complex transit policies
AUP for links. E.g., some project have private links (they have a lot of traffic). These might be listed, but you can only use them if you have certain credentials. Some links have AUPs that are under NDAs.
Section 9:
NML isn't mentioned before this section, but the entire document is based on the NML model.
Section 9.1:
Key distribution is problematic, since many developments within NSI did not focus too much on the security aspects giving no facil- ity to distribute information with end-to-end security.
And forcing all-to-all trust is much better?
--
Sorry for being an ass about this. But I am tired of seeing technology first solutions (and NML and its derivatives is certainly so).
Policies are much more important for finding paths than technology. BGP and SS7 is successfull because they allow policies to be expressed. For BGP, announcing different reachability to different networks, and with different priorities for where to deliver traffic, and the ability to override the latter locally. SS7 is more complicated (because telco), but interestingly enough it is circuit based.
The basic model needs to allow networks to figure out they want to connect. Having user or centrally driven path finding is a pipe dream.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
-- Ralph Koning SNE research group, University of Amsterdam Tel: +31 20 525 7928 | http://staff.science.uva.nl/~ralph
Hi again (sorry for the slow response time) On Mon, 8 Sep 2014, Ralph Koning wrote:
Hi Henrik,
Thanks for your comments; it seems that some things are left unclear and let me elaborate on this. Naturally, we will improve the text in the next document version. As both Miroslav and me will be present at the Nordunet conference we can further elaborate and clarify the model.
#0 The document is a proposal for a topology exchange - It is not a requirements document (upcoming/promised by Chin/John) - It is not a comparison of routing techniques
#1 Topology exchange != routing We distinguish between 'topology exchange' and 'path calculation'.
You cannot separate these. The requirements inherently affect what information is published/exhanges between networks/NSA. Similarly the routing algorithm affects how the information gets passed around. The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case. You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit). I wish more people would look at BGP. There is a notion in the group, that BGP is somehow bad or restrictive. However, the reason BGP is successfull it because it allows representing the underlying policy of the network AND being able to change up/downstream. This is completely impossible with the single description-per-network idea of NML (which mainly seems to come out of multi-layer pathfinding research, and if you are just interesting in hardware capabilities that approach is fine). It is not BGP that creates the policy, it just exposes it. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi Henrik, Sorry to jump into this discussion. Given the agenda of the upcoming NSI meeting on monday I am very interested in the restrictive policies you have that are not easy to describe or should only work when the control plane and data plane er equal (chain).
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
If I understand your example well, A is allowed to transit B to reach C, but B is not allowed to send traffic back to A (see diagram below), right? If this is correct, I think you should be able to describe this policy in NML with the unidirectional ports and links. Or do you mean B is allowed to transit C, but A is not allowed to transit C through B? This would be hard to describe. I think the only way is to make a list of source domains that are allowed to transit. But I do not see how domain C could do this with BGP without the cooperation of domain B. Can you explain? A — B — C — D Kind regards, Diederik SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300 | Diederik Vandevenne | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG | Amsterdam | | T 06 4798 8196 | diederik.vandevenne@surfsara.nl | www.surfsara.nl | On 18 Sep 2014, at 15:48, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi again (sorry for the slow response time)
On Mon, 8 Sep 2014, Ralph Koning wrote:
Hi Henrik,
Thanks for your comments; it seems that some things are left unclear and let me elaborate on this. Naturally, we will improve the text in the next document version. As both Miroslav and me will be present at the Nordunet conference we can further elaborate and clarify the model.
#0 The document is a proposal for a topology exchange - It is not a requirements document (upcoming/promised by Chin/John) - It is not a comparison of routing techniques
#1 Topology exchange != routing We distinguish between 'topology exchange' and 'path calculation'.
You cannot separate these. The requirements inherently affect what information is published/exhanges between networks/NSA. Similarly the routing algorithm affects how the information gets passed around.
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
I wish more people would look at BGP. There is a notion in the group, that BGP is somehow bad or restrictive. However, the reason BGP is successfull it because it allows representing the underlying policy of the network AND being able to change up/downstream. This is completely impossible with the single description-per-network idea of NML (which mainly seems to come out of multi-layer pathfinding research, and if you are just interesting in hardware capabilities that approach is fine). It is not BGP that creates the policy, it just exposes it.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi Diederik On Thu, 18 Sep 2014, Diederik Vandevenne wrote:
Sorry to jump into this discussion. Given the agenda of the upcoming NSI meeting on monday I am very interested in the restrictive policies you have that are not easy to describe or should only work when the control plane and data plane er equal (chain).
So chaining allows better control of how you connect different networks together. That is, how the data should transit.
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
If I understand your example well, A is allowed to transit B to reach C, but B is not allowed to send traffic back to A (see diagram below),
I don't know any cases like that (but I won't say they don't exist).
right? If this is correct, I think you should be able to describe this policy in NML with the unidirectional ports and links. Or do you mean B is allowed to transit C, but A is not allowed to transit C through B?
Moving diagram up:
A — B — C — D
Yes. You can have cases where A is allowed to transit to C, but not D. This is the case for some NRENs that we provide some transit services too, but not our full transit services (due to AUPs about R&E/commercial traffic or simply due to the network having their own peering infrastructure in one region of the world but not another).
This would be hard to describe. I think the only way is to make a list of source domains that are allowed to transit. But I do not see how domain C could do this with BGP without the cooperation of domain B. Can you explain?
You can apply filters in BGP for what you choose to announce further (in fact, this is a core part of BGP to avoid loops). Typically you won't re-announce peering stuff from peering links, but we have customers/peers where this is these cases are not clear cut. Say a customer announces an IP range and some AS-paths to us. We may only announce part of the range and as-paths further down. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi Henrik, Thank you for explaining your example. I now do understand your policy problem better. To describe your example in more general terms: you have policies that allow restricted transit to domains that are not your direct neighbors (more than one hop away). I guess this is one of the cases where the policy cannot be exposed only by the topology information itself. However, without going too much into detail, there are other ways to handle these policies. One idea is to indicate for each SDP in the topology file that transit is allowed, denied or restricted. If the pathfinder has to choose between a domain that allows transit and one that has a restricted transit policy, the pathfinder may prefer the domain that always allows transit. If there are only domains with restricted transit to choose from, you could just let the requesting agent try to see if it works, as Jerry suggested, or the domains can for example link to a policy file which can be used by the pathfinder to choose the best path. The proposal of the UvA also allows to distribute personalized topology files based on the identity of the requesting NSA. But I guess I am going again to deep into the technology and finding solutions ;). The point I want to make is that there are solutions for your (policy) problems that can work with a system that uses NML topology files and (tree based) control / signaling planes that are distinct from the data plane. I totally agree with what Guy said during the last conference call: We want to do something new. Why bother with NSI if you only want it to be a copy of BGP? As Guy said, NSI can be seen as a form of SDN where the network is a resource that can be controlled by applications and end users (based on a policy of course). The usefulness of NSI would be limited if it would work in the same way as BGP. Also note that if the services offered through NSI and BGP are not the same, the policies may also be very different. The limitations you see now may not even apply. Kind regards, Diederik SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300 | Diederik Vandevenne | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG | Amsterdam | | T 06 4798 8196 | diederik.vandevenne@surfsara.nl | www.surfsara.nl | On 19 Sep 2014, at 11:24, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi Diederik
On Thu, 18 Sep 2014, Diederik Vandevenne wrote:
Sorry to jump into this discussion. Given the agenda of the upcoming NSI meeting on monday I am very interested in the restrictive policies you have that are not easy to describe or should only work when the control plane and data plane er equal (chain).
So chaining allows better control of how you connect different networks together. That is, how the data should transit.
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
If I understand your example well, A is allowed to transit B to reach C, but B is not allowed to send traffic back to A (see diagram below),
I don't know any cases like that (but I won't say they don't exist).
right? If this is correct, I think you should be able to describe this policy in NML with the unidirectional ports and links. Or do you mean B is allowed to transit C, but A is not allowed to transit C through B?
Moving diagram up:
A — B — C — D
Yes. You can have cases where A is allowed to transit to C, but not D. This is the case for some NRENs that we provide some transit services too, but not our full transit services (due to AUPs about R&E/commercial traffic or simply due to the network having their own peering infrastructure in one region of the world but not another).
This would be hard to describe. I think the only way is to make a list of source domains that are allowed to transit. But I do not see how domain C could do this with BGP without the cooperation of domain B. Can you explain?
You can apply filters in BGP for what you choose to announce further (in fact, this is a core part of BGP to avoid loops). Typically you won't re-announce peering stuff from peering links, but we have customers/peers where this is these cases are not clear cut. Say a customer announces an IP range and some AS-paths to us. We may only announce part of the range and as-paths further down.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On Fri, 19 Sep 2014, Diederik Vandevenne wrote:
However, without going too much into detail, there are other ways to handle these policies.
One idea is to indicate for each SDP in the topology file that transit is allowed, denied or restricted.
This is the wrong way to think about. No one does transit except if they are being paid to do it. The problem with the tree-model is that I can no longer see if I am doing transit or not. And the switching model of NML makes it very difficult for a network to describe it. If NSI becomes a tool for bypassing transit rules, it WILL BE SHUT DOWN. I am trying to prevent that. I really am.
The point I want to make is that there are solutions for your (policy) problems that can work with a system that uses NML topology files and (tree based) control / signaling planes that are distinct from the data plane.
I totally agree with what Guy said during the last conference call: We want to do something new.
New is not a goal in itself. I thought we are trying to provide a point-to-point service with certain qos charactaristicas, and possibility to integrate network services into applicatios.
Why bother with NSI if you only want it to be a copy of BGP?
I don't think I have said that. I am trying to keep the pathfinding from breaking transit rules and link AUPs.
As Guy said, NSI can be seen as a form of SDN where the network is a resource that can be controlled by applications and end users (based on a policy of course).
Asking for certin QoS parameters seem like a thing IP doesn't have.
The usefulness of NSI would be limited if it would work in the same way as BGP.
No, the path finding would just work as BGP.
Also note that if the services offered through NSI and BGP are not the same, the policies may also be very different. The limitations you see now may not even apply.
The policies are not there because of BGP. BGP is there to enforce the policies. A new protocol does not magically bypass these. In fact, it will be scrutinized hard to see if it adheres to this. But what exactly is so bad about BGP? It is extremely flexible protocol with a proven track record. Sure, it doesn't allow user-driven or complicated path finding. But that is it main feature. It allows control over the network. Networking infrastructure are shared resources, often serving millions of users. Not a playground for users to create loops and bypass policies in. And I am not buying the "some users had a bad experience with chain mode" argument. This meant that their transit provider screwed up or they or the protocol could not specify their requirements. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi folks- Topology can easily get overwhelmingly complex. We really have to simplify and minimize the amount of advertised topology. Interdomain Topology Complexity is the key reason prior circuit provisioning services never took root - we MUST simplify and minimize. One of the fundamentals we are missing here is the separation of "topology" (adjacency information) from "forwarding behaviour" (policy in this case). I think NSI is making the topology overly and unnecessarily complex by trying to publicaly express all possible attributes that may affect a reservation decision - ie. by expecting all pathfinders to be able to predict the answer before you ask the question. This is ...crazy. This is an optimization problem and the more information you try to express the more complex and specialized you make all path finders. And after they make their prediction - they still have to ask anyway(!) These are dynamical systems... So all this optimization is simply to reduce the prospect that a reservation request might fail. I.e. you are trying to prune the search space. So we can spend (litterally) years hashing out this age old optimization problem - re-creating complex and mostly only specialized extensions, or we can use a higher degree of automated brute force and emperical experience to make it all work. If we did not announce *ANY* topology information except simple adjacencies ...- what would be the performance of reservation requests to reach a confirmation state? The prospect of a successfull confirmation in any single domain is improved if the domain has a very minimally restrictive or non-existent policy on connection requests, and has ample resources available across its domain (between any STPs) at the time they are needed. Interestingly, the chances of a request being confirmed also increases the less specific the request... i.e. the more specific the request, the less likely the provider will be to have the specific resources available. So neither of these depend upon extensive advertisement of forwarding behaviour or policy. They rely on the provider actually trying to *PROVIDE* services (not restricting them), and the requester specifying only what they *truly require*. Thus a NSI domain with minimal policy (e.g. an OpenExchange ) and with lots of resources (e.g. 100 Gbps edge ports and non-blocking internal facilities) is highly likely to be able to confirm a reservation. A NSI domain with numerous complex and restrictive policies and only a bare minimum of resource (links) will likely fail the request most times. This response is regardless of the policy used. Similarly, if the user requests a connection specifying only what they truly need - e.g. a 10Gbps capacity that terminates on "any" STP at this host and any STP on that nework - and does not get picky about EROs, transit paths, energy consumption, or transit VLANs - will also be highly likely to be confirmed. Regarding policy - if all networks arrange for transit credential for their directly adjacent networks on a bi-lateral basis, then the Chain rule makes policy almost moot...each domain will always have a means of transiting a request down stream. So a best common practice that would solve the immediate policy problem is for directly adjacent networks to work out a transit policy/credentials, and when the chain rule is used, those transit credentials are used. If a requester wants to do a Tree segmentation, fine too - but they have to know an appropriate set of credentials for each domain. There is no need to advertise policy, or to artificially try to deduce what the user is doing by looking at end points... So all this chatter about policy advertisement is missing the Big Picture that our goal is: "Find a successful path." Period. It is not: "Find a successful path, on your first try." As a user I don't care it it took a thousand requests downstream before I receive a confirmed a path - once it is confirmed I know I have my connection at the appointed time. It is important that I get a confirmation ultimately, not that I get a confirmation quickly. We can improve the reservation search performance by improving the request format - allowing the user to relax some components of the request so that the provider can be less rigid - and by maing sure we have sufficient resource in place as providers to meet the demand easily. I really think we are making the path finding process much harder than is necessary - and the degree of complexity you are building into the topology advertisements will make it difficult for networks to field a service and difficult for users to utilize it - so this complexity is very counter productive. (THe token passing authorization is another mechanism I think is fundamentally flawed and therefore adds unecessary complexity ...but that is another posting:-) Let get back to basics and simplify and minimize the topology announcement. You can yell at me in Uppsala:-) Best regards Jerry On 9/19/14, 8:43 AM, Diederik Vandevenne wrote:
Hi Henrik,
Thank you for explaining your example. I now do understand your policy problem better. To describe your example in more general terms: you have policies that allow restricted transit to domains that are not your direct neighbors (more than one hop away). I guess this is one of the cases where the policy cannot be exposed only by the topology information itself. However, without going too much into detail, there are other ways to handle these policies.
One idea is to indicate for each SDP in the topology file that transit is allowed, denied or restricted. If the pathfinder has to choose between a domain that allows transit and one that has a restricted transit policy, the pathfinder may prefer the domain that always allows transit. If there are only domains with restricted transit to choose from, you could just let the requesting agent try to see if it works, as Jerry suggested, or the domains can for example link to a policy file which can be used by the pathfinder to choose the best path. The proposal of the UvA also allows to distribute personalized topology files based on the identity of the requesting NSA. But I guess I am going again to deep into the technology and finding solutions ;). The point I want to make is that there are solutions for your (policy) problems that can work with a system that uses NML topology files and (tree based) control / signaling planes that are distinct from the data plane.
I totally agree with what Guy said during the last conference call: We want to do something new. Why bother with NSI if you only want it to be a copy of BGP? As Guy said, NSI can be seen as a form of SDN where the network is a resource that can be controlled by applications and end users (based on a policy of course). The usefulness of NSI would be limited if it would work in the same way as BGP. Also note that if the services offered through NSI and BGP are not the same, the policies may also be very different. The limitations you see now may not even apply.
Kind regards,
Diederik
SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300
| Diederik Vandevenne | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG | Amsterdam | | T 06 4798 8196 | diederik.vandevenne@surfsara.nl | www.surfsara.nl |
On 19 Sep 2014, at 11:24, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi Diederik
On Thu, 18 Sep 2014, Diederik Vandevenne wrote:
Sorry to jump into this discussion. Given the agenda of the upcoming NSI meeting on monday I am very interested in the restrictive policies you have that are not easy to describe or should only work when the control plane and data plane er equal (chain). So chaining allows better control of how you connect different networks together. That is, how the data should transit.
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
If I understand your example well, A is allowed to transit B to reach C, but B is not allowed to send traffic back to A (see diagram below), I don't know any cases like that (but I won't say they don't exist).
right? If this is correct, I think you should be able to describe this policy in NML with the unidirectional ports and links. Or do you mean B is allowed to transit C, but A is not allowed to transit C through B? Moving diagram up:
A --- B --- C --- D Yes. You can have cases where A is allowed to transit to C, but not D. This is the case for some NRENs that we provide some transit services too, but not our full transit services (due to AUPs about R&E/commercial traffic or simply due to the network having their own peering infrastructure in one region of the world but not another).
This would be hard to describe. I think the only way is to make a list of source domains that are allowed to transit. But I do not see how domain C could do this with BGP without the cooperation of domain B. Can you explain? You can apply filters in BGP for what you choose to announce further (in fact, this is a core part of BGP to avoid loops). Typically you won't re-announce peering stuff from peering links, but we have customers/peers where this is these cases are not clear cut. Say a customer announces an IP range and some AS-paths to us. We may only announce part of the range and as-paths further down.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
In times like these I always ask myself "What would Jerry say?" This has helped me quite a bit since he stopped participating in the daily activities of the NSI-WG. Every time I get too deep into the network technology, I can hear Jerry's voice telling me it is too much detail for what we are trying to achieve in NSI. I take a step back, and try to remove myself from the nitty gritty details of the specific networking technology. Something to think about… I think we need to very careful to keep a separation of concerns. NML is used to describe the NSI service constructs of STP, SDP, Service Domains, and Adaptations. Policy is something that gets applied to these constructs in some way (yet to be defined) to constrain their function. Annotating NML with policy may be a possibility. There are also others. I definitely think we will need to add additional attributes to the NML objects to help better identify them for the enforcement of policy (depending on the types we define). I have been thinking about the policy topic quite a bit, and I think we have policy in a number of places: 1. Within networks as described by Henrik. 2. Within services definitions - policies on the defined services we offer. 3. Within user requests - we talk about path constraints but these are user specified policy to guide the reservation request (and part of the service definitions). The good thing is if a policy can be enforced it can be described. John On 2014-09-18, at 9:48 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi again (sorry for the slow response time)
On Mon, 8 Sep 2014, Ralph Koning wrote:
Hi Henrik,
Thanks for your comments; it seems that some things are left unclear and let me elaborate on this. Naturally, we will improve the text in the next document version. As both Miroslav and me will be present at the Nordunet conference we can further elaborate and clarify the model.
#0 The document is a proposal for a topology exchange - It is not a requirements document (upcoming/promised by Chin/John) - It is not a comparison of routing techniques
#1 Topology exchange != routing We distinguish between 'topology exchange' and 'path calculation'.
You cannot separate these. The requirements inherently affect what information is published/exhanges between networks/NSA. Similarly the routing algorithm affects how the information gets passed around.
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
I wish more people would look at BGP. There is a notion in the group, that BGP is somehow bad or restrictive. However, the reason BGP is successfull it because it allows representing the underlying policy of the network AND being able to change up/downstream. This is completely impossible with the single description-per-network idea of NML (which mainly seems to come out of multi-layer pathfinding research, and if you are just interesting in hardware capabilities that approach is fine). It is not BGP that creates the policy, it just exposes it.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Ah John - what a lovely complement. :-) But you are right. This is the hard part of path selection - knowing all the details about all the choices before making a decision which to use. First, most networks don't want to advertise all their policies. Second, these are only some of the information that may prevent a reservation being confirmed - scheduling could be another. Do you advertise the entire available schedule within your topology as well? THis becomes a very NP hard problem. So if you can't advertise all the relevant information, then how do you deal with it? I say - Try it. See if it works. There was no guarantee that it would work even if you knew the policy, so you would still have to try the reservation - and risk being rejected and having to crank back and try another path. There is no escaping this. So I suggest you don't worry about it - we simplify the advertisements as much as possible, and make a "good" guess rather than trying to solve an optimization problem. If Henrik has funky policy, let him process the request and decide...why should all other pathfinders have to be able to interpret his complex policies? The otehr question is- How do you prune the search space? You may find that policy is not the best way to prune the search space and that other criteria rule out most paths anyway. In which case there are only a few viable paths remaining there is no need to fret over whether you have a valid credential that the remote network will honor... just try it. Try it 50 times if you need to. Thats life in topology processing. So what is the moral? Keep your advertised topology as simple as possible, and let local agents deal with local problems. If you are a directly peering neighbor, you should already know which credentials will allow a reservation through, and if you are a remote NSA, well... no gurantees.. its a hail mary. See you all in Uppsala Jerry :-) On 9/18/14, 3:28 PM, John MacAuley wrote:
In times like these I always ask myself "What would Jerry say?" This has helped me quite a bit since he stopped participating in the daily activities of the NSI-WG. Every time I get too deep into the network technology, I can hear Jerry's voice telling me it is too much detail for what we are trying to achieve in NSI. I take a step back, and try to remove myself from the nitty gritty details of the specific networking technology. Something to think about...
I think we need to very careful to keep a separation of concerns. NML is used to describe the NSI service constructs of STP, SDP, Service Domains, and Adaptations. Policy is something that gets applied to these constructs in some way (yet to be defined) to constrain their function. Annotating NML with policy may be a possibility. There are also others. I definitely think we will need to add additional attributes to the NML objects to help better identify them for the enforcement of policy (depending on the types we define).
I have been thinking about the policy topic quite a bit, and I think we have policy in a number of places:
1. Within networks as described by Henrik. 2. Within services definitions - policies on the defined services we offer. 3. Within user requests - we talk about path constraints but these are user specified policy to guide the reservation request (and part of the service definitions).
The good thing is if a policy can be enforced it can be described.
John
On 2014-09-18, at 9:48 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi again (sorry for the slow response time)
On Mon, 8 Sep 2014, Ralph Koning wrote:
Hi Henrik,
Thanks for your comments; it seems that some things are left unclear and let me elaborate on this. Naturally, we will improve the text in the next document version. As both Miroslav and me will be present at the Nordunet conference we can further elaborate and clarify the model.
#0 The document is a proposal for a topology exchange - It is not a requirements document (upcoming/promised by Chin/John) - It is not a comparison of routing techniques
#1 Topology exchange != routing We distinguish between 'topology exchange' and 'path calculation'. You cannot separate these. The requirements inherently affect what information is published/exhanges between networks/NSA. Similarly the routing algorithm affects how the information gets passed around.
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
I wish more people would look at BGP. There is a notion in the group, that BGP is somehow bad or restrictive. However, the reason BGP is successfull it because it allows representing the underlying policy of the network AND being able to change up/downstream. This is completely impossible with the single description-per-network idea of NML (which mainly seems to come out of multi-layer pathfinding research, and if you are just interesting in hardware capabilities that approach is fine). It is not BGP that creates the policy, it just exposes it.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
I do agree with the comment on funky policies, and and of course the uPA is always the final authority on what can and cannot be done. I do however, believe we should deb able to communicate some common high-level policies so the pathfinders can more quickly converge on a viable path. We need to consider simple ones like network transit policies and any SDP restrictions. This would allow the path finder to prune the easy ones before its first attempt, allowing convergence on a viable path more quickly. My goal is to be successful first try in most of the cases, and have to retry for some of the more funky ones. So if ESnet only allows reservations on their network to source or terminate in their customer's networks then I should know this before starting pathfinding so I don't use them as a transit path. Other types of polices such as end-site STP policies (UNI-N) really don't matter to path finding. Whether I tell the user it is not possible, or the uPA does, they will know in the end and I could not have avoided the issue. John On 2014-09-18, at 3:54 PM, Jerry Sobieski <jerry@nordu.net> wrote:
Ah John - what a lovely complement. :-)
But you are right. This is the hard part of path selection - knowing all the details about all the choices before making a decision which to use.
First, most networks don't want to advertise all their policies. Second, these are only some of the information that may prevent a reservation being confirmed - scheduling could be another. Do you advertise the entire available schedule within your topology as well? THis becomes a very NP hard problem.
So if you can't advertise all the relevant information, then how do you deal with it? I say - Try it. See if it works. There was no guarantee that it would work even if you knew the policy, so you would still have to try the reservation - and risk being rejected and having to crank back and try another path.
There is no escaping this.
So I suggest you don't worry about it - we simplify the advertisements as much as possible, and make a "good" guess rather than trying to solve an optimization problem. If Henrik has funky policy, let him process the request and decide...why should all other pathfinders have to be able to interpret his complex policies?
The otehr question is- How do you prune the search space? You may find that policy is not the best way to prune the search space and that other criteria rule out most paths anyway. In which case there are only a few viable paths remaining there is no need to fret over whether you have a valid credential that the remote network will honor... just try it. Try it 50 times if you need to.
Thats life in topology processing. So what is the moral? Keep your advertised topology as simple as possible, and let local agents deal with local problems. If you are a directly peering neighbor, you should already know which credentials will allow a reservation through, and if you are a remote NSA, well... no gurantees.. its a hail mary.
See you all in Uppsala Jerry :-)
On 9/18/14, 3:28 PM, John MacAuley wrote:
In times like these I always ask myself "What would Jerry say?" This has helped me quite a bit since he stopped participating in the daily activities of the NSI-WG. Every time I get too deep into the network technology, I can hear Jerry's voice telling me it is too much detail for what we are trying to achieve in NSI. I take a step back, and try to remove myself from the nitty gritty details of the specific networking technology. Something to think about…
I think we need to very careful to keep a separation of concerns. NML is used to describe the NSI service constructs of STP, SDP, Service Domains, and Adaptations. Policy is something that gets applied to these constructs in some way (yet to be defined) to constrain their function. Annotating NML with policy may be a possibility. There are also others. I definitely think we will need to add additional attributes to the NML objects to help better identify them for the enforcement of policy (depending on the types we define).
I have been thinking about the policy topic quite a bit, and I think we have policy in a number of places:
1. Within networks as described by Henrik. 2. Within services definitions - policies on the defined services we offer. 3. Within user requests - we talk about path constraints but these are user specified policy to guide the reservation request (and part of the service definitions).
The good thing is if a policy can be enforced it can be described.
John
On 2014-09-18, at 9:48 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi again (sorry for the slow response time)
On Mon, 8 Sep 2014, Ralph Koning wrote:
Hi Henrik,
Thanks for your comments; it seems that some things are left unclear and let me elaborate on this. Naturally, we will improve the text in the next document version. As both Miroslav and me will be present at the Nordunet conference we can further elaborate and clarify the model.
#0 The document is a proposal for a topology exchange - It is not a requirements document (upcoming/promised by Chin/John) - It is not a comparison of routing techniques
#1 Topology exchange != routing We distinguish between 'topology exchange' and 'path calculation'. You cannot separate these. The requirements inherently affect what information is published/exhanges between networks/NSA. Similarly the routing algorithm affects how the information gets passed around.
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
I wish more people would look at BGP. There is a notion in the group, that BGP is somehow bad or restrictive. However, the reason BGP is successfull it because it allows representing the underlying policy of the network AND being able to change up/downstream. This is completely impossible with the single description-per-network idea of NML (which mainly seems to come out of multi-layer pathfinding research, and if you are just interesting in hardware capabilities that approach is fine). It is not BGP that creates the policy, it just exposes it.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
I totally agree with John’s comment. I think that we should be able to describe and communicate most of the policies to speed up the pathfinding. I also think NML (maybe with some extensions) is suitable enough to expose most of the policies relevant for pathfinding. We do not need BGP or any other reachability based routing for that. Kind regards, Diederik SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300 | Diederik Vandevenne | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG | Amsterdam | | T 06 4798 8196 | diederik.vandevenne@surfsara.nl | www.surfsara.nl | On 18 Sep 2014, at 23:23, John MacAuley <macauley@es.net> wrote:
I do agree with the comment on funky policies, and and of course the uPA is always the final authority on what can and cannot be done. I do however, believe we should deb able to communicate some common high-level policies so the pathfinders can more quickly converge on a viable path. We need to consider simple ones like network transit policies and any SDP restrictions. This would allow the path finder to prune the easy ones before its first attempt, allowing convergence on a viable path more quickly.
My goal is to be successful first try in most of the cases, and have to retry for some of the more funky ones. So if ESnet only allows reservations on their network to source or terminate in their customer's networks then I should know this before starting pathfinding so I don't use them as a transit path. Other types of polices such as end-site STP policies (UNI-N) really don't matter to path finding. Whether I tell the user it is not possible, or the uPA does, they will know in the end and I could not have avoided the issue.
John
On 2014-09-18, at 3:54 PM, Jerry Sobieski <jerry@nordu.net> wrote:
Ah John - what a lovely complement. :-)
But you are right. This is the hard part of path selection - knowing all the details about all the choices before making a decision which to use.
First, most networks don't want to advertise all their policies. Second, these are only some of the information that may prevent a reservation being confirmed - scheduling could be another. Do you advertise the entire available schedule within your topology as well? THis becomes a very NP hard problem.
So if you can't advertise all the relevant information, then how do you deal with it? I say - Try it. See if it works. There was no guarantee that it would work even if you knew the policy, so you would still have to try the reservation - and risk being rejected and having to crank back and try another path.
There is no escaping this.
So I suggest you don't worry about it - we simplify the advertisements as much as possible, and make a "good" guess rather than trying to solve an optimization problem. If Henrik has funky policy, let him process the request and decide...why should all other pathfinders have to be able to interpret his complex policies?
The otehr question is- How do you prune the search space? You may find that policy is not the best way to prune the search space and that other criteria rule out most paths anyway. In which case there are only a few viable paths remaining there is no need to fret over whether you have a valid credential that the remote network will honor... just try it. Try it 50 times if you need to.
Thats life in topology processing. So what is the moral? Keep your advertised topology as simple as possible, and let local agents deal with local problems. If you are a directly peering neighbor, you should already know which credentials will allow a reservation through, and if you are a remote NSA, well... no gurantees.. its a hail mary.
See you all in Uppsala Jerry :-)
On 9/18/14, 3:28 PM, John MacAuley wrote:
In times like these I always ask myself "What would Jerry say?" This has helped me quite a bit since he stopped participating in the daily activities of the NSI-WG. Every time I get too deep into the network technology, I can hear Jerry's voice telling me it is too much detail for what we are trying to achieve in NSI. I take a step back, and try to remove myself from the nitty gritty details of the specific networking technology. Something to think about…
I think we need to very careful to keep a separation of concerns. NML is used to describe the NSI service constructs of STP, SDP, Service Domains, and Adaptations. Policy is something that gets applied to these constructs in some way (yet to be defined) to constrain their function. Annotating NML with policy may be a possibility. There are also others. I definitely think we will need to add additional attributes to the NML objects to help better identify them for the enforcement of policy (depending on the types we define).
I have been thinking about the policy topic quite a bit, and I think we have policy in a number of places:
1. Within networks as described by Henrik. 2. Within services definitions - policies on the defined services we offer. 3. Within user requests - we talk about path constraints but these are user specified policy to guide the reservation request (and part of the service definitions).
The good thing is if a policy can be enforced it can be described.
John
On 2014-09-18, at 9:48 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi again (sorry for the slow response time)
On Mon, 8 Sep 2014, Ralph Koning wrote:
Hi Henrik,
Thanks for your comments; it seems that some things are left unclear and let me elaborate on this. Naturally, we will improve the text in the next document version. As both Miroslav and me will be present at the Nordunet conference we can further elaborate and clarify the model.
#0 The document is a proposal for a topology exchange - It is not a requirements document (upcoming/promised by Chin/John) - It is not a comparison of routing techniques
#1 Topology exchange != routing We distinguish between 'topology exchange' and 'path calculation'.
You cannot separate these. The requirements inherently affect what information is published/exhanges between networks/NSA. Similarly the routing algorithm affects how the information gets passed around.
The basic shortcoming of the system is that it is based around a single representation of each network (the NML way of thinking). However this is practially never the case.
You can try and encode switching capabilities into each network description and do pathfinding (the current approach for some in the NSI group), but this falls to the ground when there are restrictive policies about re-transit (i.e., I am allowed to transit a service into another network, but the entity I am selling to is not allowed to re-transit).
I wish more people would look at BGP. There is a notion in the group, that BGP is somehow bad or restrictive. However, the reason BGP is successfull it because it allows representing the underlying policy of the network AND being able to change up/downstream. This is completely impossible with the single description-per-network idea of NML (which mainly seems to come out of multi-layer pathfinding research, and if you are just interesting in hardware capabilities that approach is fine). It is not BGP that creates the policy, it just exposes it.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net
Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list
nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list
nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Thu, 18 Sep 2014, John MacAuley wrote:
In times like these I always ask myself "What would Jerry say?" This has helped me quite a bit since he stopped participating in the daily activities of the NSI-WG. Every time I get too deep into the network technology, I can hear Jerry's voice telling me it is too much detail for what we are trying to achieve in NSI. I take a step back, and try to remove myself from the nitty gritty details of the specific networking technology. Something to think about…
So this seems like an argument to encapsulate the behaviour instead of describing it.
I have been thinking about the policy topic quite a bit, and I think we have policy in a number of places:
1. Within networks as described by Henrik. 2. Within services definitions - policies on the defined services we offer. 3. Within user requests - we talk about path constraints but these are user specified policy to guide the reservation request (and part of the service definitions).
The good thing is if a policy can be enforced it can be described.
Sure, but it doesn't mean that it can be described with whatever is the current fashion in topology description. What BGP did was to throw away complicated routing protocols and simply announce reachabilty (path vectors, which is slighly different from distance vectors) over each link. This gives the network admins full control over what to announce to other networks, and hence completely removes the need to describe policy. If I can tell each of my networks what they can reach through my network, possibly with some preference for multi-homing, they don't need to know anything else. Sure, BGP doesn't capture everything and you need agreements about what can be re-announced, but this is usually not a problem since network don't want to provide transit unless you are handing them money. I am not saying that BGP is the shining light of all routing/pathfinding and we should carbon copy it. But it does represent 40 years of networking. So when someone comes up and presents something completely different, I'd expect a coule of good reasons. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Sure, but it doesn't mean that it can be described with whatever is the current fashion in topology description.
100% agree and I would not necessarily try to do it a solution that way. The combinations of switching services and ports needed to model some of the basic transit policies may get unreasonable, however, annotating NML objects to drive some type of policy description may be one possible solution. John
On 2014-09-19, at 8:45 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
So this seems like an argument to encapsulate the behaviour instead of describing it.
I believe we will end up on a hybrid approach where we describe macro level policies and leave the private or really complex policies to the uPA. I need a high level of success for the first tree path request, not perfect record. It is then up to us to make sure the errors reported are robust enough for the NSA's path finder to avoid the same problem next time. I am all about encapsulation, but nothing is stopping us from exposing useful policy data as we have for topology.
I am not saying that BGP is the shining light of all routing/pathfinding and we should carbon copy it. But it does represent 40 years of networking. So when someone comes up and presents something completely different, I'd expect a coule of good reasons.
I think BGP is a good example of a mechanism in the IP world that does a reasonable job at achieving the end goal. Obviously, every solution has its issues and people who speak out against it. From a connection service perspective there are solutions that also achieve an ends, although in my experience many are proprietary. We need to remember that layer 2 VPN is not the only service NSI can offer, as I believe Tomohiro has demonstrated in their implementation. John
participants (5)
-
Diederik Vandevenne -
Henrik Thostrup Jensen -
Jerry Sobieski -
John MacAuley -
Ralph Koning