[Nsi-wg] UvA/TUD topology exchange proposal

[John MacAuley]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1626 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20140918/ecae22ae/attachment.bin>