The label type that can be switched is placed in the encoding attribute of the switching service. For example, in 802.1Q the label type is a VID (or vlan identifier), and of course, the terminology was changed in carrier ethernet so we have STAG and CTAG. Very lucky for us ;-) If we use the existing vlan URI we would have something like this: <nml:SwitchingService id="urn:ogf:network:example.net:2012:vidSwitchingService" encoding="http://schemas.ogf.org/nml/2013/03/ethernet#vlan" labelSwapping="true"> <nml:Relation type="http://schemas.ogf.org/nml/2013/03/base#hasInboundPort"> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_X:1780:in"/> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_Y:1781:in"/> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/03/base#hasOutboundPort"> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_X:1780:out"/> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_Y:1781:out"/> </nml:Relation> </nml:SwitchingService> This indicates a switching service that can switch a packet on the 802.1Q VID. John On 2013-10-31, at 9:37 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:

Hi

On Wed, 30 Oct 2013, Jeroen van der Ham wrote:

...

This is the decision regarding encoding and labeltype that was made for NML:

https://forge.ogf.org/sf/sfmain/do/go/artf6577 :

...

NML has currently a one-to-one relation between the layer encoding (a URI to define the layer of sublayer of a specific Port of Link) and the label type (a URI to define the resource label of a technology).

Make sense. Thanks for clarifying the difference.

Right now we don't use the encoding in the NSI topology. Is this something we should consider? I am not entirely sure what the benefits are though.

...

There is not a one-to-one correlation, because encodings (such as Ethernet) still allow traffic without labels at all.

Shouldn't a switching service have an encoding AND a labelType? An ethernet encoding could have both regular and VLAN and carrier ethernet vlan (with q-in-q / s-tag+c-tag), and might only be capable of changing one of them. How would I know which label types can be swapped?

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

You are correct. This was how Freek also explained it to me. He also recommended that all Ethernet based SwitchingServices have the same generic Ethernet encoding label. It looks like we have a bit of an issue then. If encoding is really the protocol encoding (Ethernet), then we need a label type to identify the label that is switched by the SwitchingService. John On 2013-10-31, at 11:05 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:

On Thu, 31 Oct 2013, John MacAuley wrote:

...

The label type that can be switched is placed in the encoding attribute of the switching service.

That is not how I understood Jeroens answer (or the NML spec), but I could be wrong.

From GFD.206 (the NML spec):

* The encoding attribute defines the format of the data streaming through the Port

* labeltype to refer to a technology-specific labelset, e.g. a URI for VLANs

Doesn't sound like the same. If the encoding is ethernet, there are options for no label (trunk), vlan, and q-in-q (s-tag/c-tag). I could imagine that certain types of labels might be available on different encodings.

Currently we don't really use encodings in NML for NSI, but they can be specified on port(groups) and link(groups).

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

Hi, On 1 Nov 2013, at 10:05, Henrik Thostrup Jensen <htj@nordu.net> wrote:

...

It looks like we have a bit of an issue then. If encoding is really the protocol encoding (Ethernet), then we need a label type to identify the label that is switched by the SwitchingService.

Yes. That seems to be something missing for the NML switching service.

Freek/Jeroen: What is your take on this?

If that is the case, we can also use the labelSwapping attribute to refer to the labeltype URI instead of a boolean. Jeroen.

Is there a valid scenario where we would define a switching service and not have a label value specified? On 2013-11-01, at 8:51 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:

On Fri, 1 Nov 2013, Jeroen van der Ham wrote:

...

If that is the case, we can also use the labelSwapping attribute to refer to the labeltype URI instead of a boolean.

In the schema that is a boolean, so not really possible with the current schema (but I am not sure if that's what you meant).

If we go for a rehash of the XSD, I think we should just allow an attribute named labelType.

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

I was asking to determine optionality of attributes when labelSwapping="false". The default behaviour is that if there is not a SwitchingService for a specific label type then only identical labels can be connected. I think we need to extend that to the pair <encoding type, label type> must be identical otherwise an adaptation would be required to connect them. Is that a bridge too far? John On 2013-11-01, at 10:10 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:

On Fri, 1 Nov 2013, John MacAuley wrote:

...

Is there a valid scenario where we would define a switching service and not have a label value specified?

I assume you mean label type and not value.

label type = http://schemas.ogf.org/nml/2012/10/ethernet label value = 1780

(AFAIK)

But I guess most switching services would have a label type defined.

However I can up with a pedantic example: If you want to show, that you can NOT switch any labels an encoding, you could have a switching service that has an encoding and labelSwapping="false".

This also raises a question regarding the default behaviour in NML. Can all ports (of the same encoding) be connected by default (this is what we have now), or should there be a switching service explicitely stating which ports can be cross-connected?

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

On Thu, 7 Nov 2013, Henrik Thostrup Jensen wrote:

...

The default behaviour is that if there is not a SwitchingService for a specific label type then only identical labels can be connected. I think we need to extend that to the pair <encoding type, label type> must be identical otherwise an adaptation would be required to connect them.

Is that a bridge too far?

I think it sounds reasonable (with "I am not an NML expert" caveat).

On a site note: I think the idea of listing ports on switching services is silly. It should just be a generic capability of the topology. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

I agree with Henrik. This whole issue of trying to make different internal switching technologies evident is making things far more complex than there is any real use case to justify. J On 11/7/13 10:31 AM, Henrik Thostrup Jensen wrote:

On Thu, 7 Nov 2013, Henrik Thostrup Jensen wrote:

...

...

The default behaviour is that if there is not a SwitchingService for a specific label type then only identical labels can be connected. I think we need to extend that to the pair <encoding type, label type> must be identical otherwise an adaptation would be required to connect them.

Is that a bridge too far?

I think it sounds reasonable (with "I am not an NML expert" caveat).

On a site note:

I think the idea of listing ports on switching services is silly. It should just be a generic capability of the topology.

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

Sorry, I should have stated the actual A-GOLE requirements at this point. 1. There are networks that can do VID swapping. 2. There are networks that cannot do VID swapping. 3. There are networks that can do 802.1D-to-802.1Q encapsulation/decapsulation. We need to be able to describe these is a simple and straight forward manner. John On 2013-11-07, at 10:31 AM, John MacAuley <john.macauley@surfnet.nl> 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.

2. A switching service with no ports means it applies to all ports of that specific label type.

3. When a switching service of a specific label type contains ports, it then means only those ports can be interconnected using that switching service. I also assume that if label swapping is set to false then only like labels can be interconnected.

We have to be very careful in our drive for simplification that we do not oversimplify too much such that we have built a toy that can be used in very few scenarios. I am committed to seeing this work in as simple a way as possible, however, Tomohiro already has use cases that are breaking the simplified NSI topology model.

John

On 2013-11-07, at 8:57 AM, Jerry Sobieski <jerry@nordu.net> wrote:

...

I agree with Henrik. This whole issue of trying to make different internal switching technologies evident is making things far more complex than there is any real use case to justify.

J

On 11/7/13 10:31 AM, Henrik Thostrup Jensen wrote:

...

On Thu, 7 Nov 2013, Henrik Thostrup Jensen wrote:

...

...

The default behaviour is that if there is not a SwitchingService for a specific label type then only identical labels can be connected. I think we need to extend that to the pair <encoding type, label type> must be identical otherwise an adaptation would be required to connect them.

Is that a bridge too far?

I think it sounds reasonable (with "I am not an NML expert" caveat).

On a site note:

I think the idea of listing ports on switching services is silly. It should just be a generic capability of the topology.

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

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

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

Hi, Just to add to this, the NSI group has already decided sometime back that any network can expose as much topology in NML format as it wants to. Networks can choose to expose switching services to pathfinders, or they can choose to have pathfinders discover through requests what is and is not possible. Jeroen.

Okay, I will bite! What I am trying to do from a path finding perspective is take a detailed NML document and reduce it down to four objects: Network, TransferFunction, STP, and SDP in the context of each service request. Therefore, if I get a service request for an EVTS serviceType I must be able to do path finding in the context of network resources supporting the EVTS serviceType. In Madrid we agreed that we will associate a serviceType with an STP, so I can filter out all the STP not supporting the target serviceType. This then lets me determine the applicable SDP. So from a path computation perspective I have Networks (vertices) and SDP (edges) in my graph, however, this is not enough in that I also need the TransferFunction to determine if a Network can interconnect an ingress and egress SDP. These are the basics of the NSI architecture. I am not looking at any technology specifics. I am just using the defined components of the NSI connection services architecture as defined by the collective brain trust :-) Now comes the somewhat harder bit … How do I use the NML constructs to describe the NSI constructs of Network, TransferFunction, STP, and SDP in a correct and flexible way. This has been the discussion on calls and e-mail over the last few weeks. Here is what the group has almost agreed upon: 1. The NML Topology object maps to the NSI Network object. 2. The NML Port object maps to the unidirectional NSI STP object. 3. The NML PortGroup object maps to the underspecified unidirectional NSI STP object. 4. The NML BidirectionalPort object maps to both a bidirectional NSI STP object and an underspecified bidirectional NSI STP object. 5. The NML SwitchingService object maps to the NSI TransferFunction object. 6. For the NSI SDP object there are a number of NML objects available to do the modelling (Link and BidirectionalLink) but we are using the isAlias reference in the unidirectional Port/PortGroup to identify connectivity between networks. Now I understand your argument 100% (or at least my filtered version of it). I am building the simplified view you are looking for by using a more detailed NML view. I end up treating STP as an abstracted string and grouping them in the transfer service as follows: TransferService id="urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed:evts" { urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1780 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1781 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1782 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1783 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet:1:vlan=1780 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1781 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1782 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:nordunet::1:vlan=1783 } SDPs I create by concatenating their STP ids together: SDP id="urn:ogf:network:uvalight.net:2013:netherlight:vlan=1796::urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1796" { urn:ogf:network:uvalight.net:2013:netherlight:vlan=1796 urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1796 } STPs are the standard networkId, localId, and labelType, but I make the id using local and label: STP id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1:vlan=1780" { networkId = "urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed" localId = "urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1" label (vlan = "1708") serviceType="EVTS.A-GOLE" directionality="bidirectional" other service related attributes … } And of course a network is a combination of all these: Network id="urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed" { List of TransferService List of SDP List of STP } I have created this NSI view of topology for my path finder to help prove or disprove the current definitions within the NSI architecture. So far I have been able to do basic path finding, but we are only now drilling down into some of the technology hurdles we will face when trying to create this higher level abstraction. Yes we are discussing the technology specific details in the context of NML, but we are trying to understand how it would be modelled in detail so we can understand what we need, and how it relates back to our abstractions. Yes, I agree we could simply use NML to model no more than what we currently need in NSI, but I would like to make sure the standard if flexible enough to handle more detailed needs. John On 2013-11-05, at 2:12 AM, Jerry Sobieski <jerry@nordu.net> wrote:

I really encourage everyone to think about this from the *service* perspective - i.e. what the network organization is willing to offering as a NSI service feature and what the users really *actually* want - Our NSI Services do not need to announce internal topology at all, nor do they need to express or incorporate every possible hardware capability. Keep it simple (!!!) A simple connection delivered to/from a STP associated with a VLAN tag. You get into a lot of unnecessary topology munging by trying to expose and process every technical hardware capability. Don't do this. Its not necessary. If you keep these topological details internal to a local NRM, then the announced topology is vastly simplified. Let the NRM deal with details internally, but the inter-domain path finding should only need deal with *simple* contiguous services. Don't try to make one NSI service capable of everything under the sun...doing so makes it too complex.

Best regards Jerry

On 10/31/13 9:37 AM, Henrik Thostrup Jensen wrote:

...

Hi

On Wed, 30 Oct 2013, Jeroen van der Ham wrote:

...

This is the decision regarding encoding and labeltype that was made for NML:

https://forge.ogf.org/sf/sfmain/do/go/artf6577 :

...

NML has currently a one-to-one relation between the layer encoding (a URI to define the layer of sublayer of a specific Port of Link) and the label type (a URI to define the resource label of a technology).

Make sense. Thanks for clarifying the difference.

Right now we don't use the encoding in the NSI topology. Is this something we should consider? I am not entirely sure what the benefits are though.

...

There is not a one-to-one correlation, because encodings (such as Ethernet) still allow traffic without labels at all.

Shouldn't a switching service have an encoding AND a labelType? An ethernet encoding could have both regular and VLAN and carrier ethernet vlan (with q-in-q / s-tag+c-tag), and might only be capable of changing one of them. How would I know which label types can be swapped?

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