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