[Nsi-wg] UvA/TUD topology exchange proposal

[Jerry Sobieski]

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 at 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 at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> _______________________________________________
> 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/20140918/849d87c6/attachment.html>