[Nsi-wg] Encoding & Labeltype

Chin Guok chin at es.net
Sat Nov 9 17:40:39 EST 2013 

There is an added benefit in defining a "switching" service in that if 
you want to expose additional topology (e.g. internal topology) that is 
not part of your STP set, you can still include it in your topology but 
omit it from the "switching" service section.

- Chin
On 11/7/13 2:13 PM, John MacAuley wrote:
> Jerry,
>
> In your statements below you are specifically prohibiting dynamic 
> inter-layer service turn-up by NSI CS.  I know a few of us (Tomohiro, 
> Chin, and myself) have specifically been working towards this goal. 
>  You cannot achieve this using your model, and this was one of the 
> topics we discussed in the NSI -WG call yesterday. I think we have hit 
> a point where we either need to say this is not a supported capability 
> of NSI, or we move forwards with the requirement to support it.
>
> John
>
> On 2013-11-07, at 1:33 PM, Jerry Sobieski <jerry at nordu.net 
> <mailto:jerry at nordu.net>> wrote:
>
>> Hey John - see comments below...
>> On 11/7/13 3:31 PM, John MacAuley wrote:
>>> I don't think it is silly, and there are use cases in the A-GOLE today so it is justified.
>>>
>>> 1. Today we have no switching services defined so the definition is no label swapping on any ports and would be equivalent to having a switching service defined with all ports but label swapping set to false.  This means only like labels can be connected.  The question I have is if this is always the case, even when a switching service is defined.
>> You don't need "switching services".   This is just a throwback to a 
>> desire to map any/all hardware capabilities into a single "service".  
>> Don't do this.   It artificially makes a hard problem where there is 
>> non.  NSI is about the service - not about the hardware. _/Define 
>> simple services and interconnect those and be done. /_    Don't try 
>> to cover all the "what-ifs"(!) of various ancient hardware.
>>
>> If your *service* needs to do label swapping, then build that into 
>> the underlying infrastructure and quit trying to fix broken hardware 
>> (!)    You need to get away from this notion that our *service* must 
>> present all features of our hardware - bad!   If you need 100G, do 
>> you build it from lots 1G switches just because that's what you 
>> have?  Or do you go buy a new set of equipment that does 100G?...  
>> Same thing here - the service defines the engineering and not the 
>> other way around.    If you define the service to be simple, you 
>> don't need to worry about any of this - let the engineers make it so. 
>>    So define a service that has STPs with different labels, and have 
>> the engineers buy hardware that does swapping and quit complaining 
>> about how hard flat VLANs are.    If you need label swapping - build 
>> it!  If flat switches cause problems - don't use them! Get the 
>> correct equipment for the job(!)
>>
>> And now adaptation...  Why do you need to associate "switching 
>> services" with labels?   THis is implicit in the NSI Service they are 
>> part of.  STPs crossconnect to other STPs.   If you add STPs where 
>> this is not possible or does not make sense, then you are changing 
>> the NSI Service...its not a "Connection Service" anymore.    If you 
>> want to tunnel Ethernet frames over Sonnet..build the tunnel in 
>> advance, establsih the peering point between the ingress network and 
>> the egress network, inject it itno the advertised topology, and 
>> ...Wala! Adjacent networks!   No need to define all this global 
>> hardware exposure.   Please try to see it differently - We don't need 
>> to do all this multi-layer adaptation in order to provide the /service/.
>>
>> I strongly STRONGLY encourage everyone to avoid thinking of NSI 
>> service concepts that try to reflect the hardware you already have 
>> (or bought 8 years ago.)    Think of the service in terms of what /we 
>> need it to do /- not in terms of what the devices we already have may 
>> or may not be able to do.
>>
>> Take for instance the label swapping issue - We don't build a 
>> Connection Service in order to do "label swapping".  We build the 
>> COnnection Service to provision connections edge to edge - the label 
>> swapping is simply a technology specific feature that allows us to 
>> engineer more scalable services.   If you think this through, you 
>> will realize that there are many ways to advertise topological 
>> information.   We have a very simple mechanism inherent in the basic 
>> NSI architecture that expose no hardware artifacts...and we are 
>> making it extremely complex in order to do things that you cannot 
>> expect other networks to do.    In the case of a EFTS service that 
>> can't do label swapping, we have ways to advertise this that do not 
>> require the label swaping flag at all, or can set it anyway they 
>> want.   You can't control it.
>>
>> For example:  While everyone denigrated the notion of "stacked" 
>> topologies that each contained a single non-swapping vlan, the fact 
>> is - it works.   And it is simple.     And if some network...say 
>> Nordunet advertised 5 networks that each had a single opaque STP for 
>> each peering point, how would your pathfinder know that?   Its a 
>> valid topological announcement - so your pathfinder should still use 
>> it successfully.    And doing so, I could set the LabelSwaping flag 
>> in each to True and it would *still* work.
>>
>> If everyone used this topological format to announce flat services, 
>> think how simple the pathfinder would be.   We would not need 
>> LabelSwapping flags at all.   And it would be immediately evident 
>> from the expressed topology that only one transit STP will 
>> successfully reach the destination.   So this addresses the 
>> exhaustive search issue as well.
>>
>> We *really* don't need to make NSI so complex.
>>
>> Best regards
>> Jerry
>>
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-- 
Chin Guok                                            NOC: (510) 486-7600
ESnet Network Engineering Group (AS293)                   (800) 333-7638
Lawrence Berkeley National Laboratory

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

More information about the nsi-wg mailing list