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