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@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@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