[Nsi-wg] UvA/TUD topology exchange proposal

Fri Sep 19 11:05:01 EDT 2014

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 at surfsara.nl | www.surfsara.nl |
>
> On 19 Sep 2014, at 11:24, Henrik Thostrup Jensen <htj at 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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20140919/ea42a6b2/attachment.html>