[Nsi-wg] Encoding & Labeltype

[Jerry Sobieski]

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

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