[Nsi-wg] NSI topology representation using NML

[Jeroen van der Ham]

Hi,

I have two words for this: “Location - Identifier”.

The Internet has a legacy for this in the form of IP addresses which serve both functions. Now the IETF is trying very hard to use IPv6 to tear it apart again (and in an ugly way too).

Like with the unidirectional model, this is a one-way street. It may not have much benefit now, but it will block future options.

Jeroen.


On 27 Nov 2013, at 21:10, John MacAuley <john.macauley at surfnet.nl> wrote:

> Peoples,
> 
> I have taken another look over Jeroen's document "Network Service Interface Topology Representation" given the discussion we had today on the call.  I must say that we are totally out of synch with the definition of an STP Identifier in Jeroen's document and what we have in the NSI CS (no specific fault on Jeroen).  Specifically, if we look at section 2.2 and 2.3 the STP identifier is defined as follows:
> 
> STP ID = urn:ogf:network:example.net:2013:A2?vlan=1781
> 
> urn:ogf:network: - describes that it is a network identifier.
> example.net:2013 - DNS name and a (at least) year to make a globally unique prefix creating the network identifier.
> A2?vlan=1781 - The local component identifying the STP in the context of the network identifier.
> 
> The root STP ID "urn:ogf:network:example.net:2013:A2" would be an under specified STP referring to the bundle of STP enumerated by vlan.  I believe, although not specifically stated, that "urn:ogf:network:example.net:2013:A2?vlan=1780-1790" would also allow me to under specify a range of vlan.
> 
> This definition for an STP Identifier is in line with the Baton Rouge discussions.  This is also how I build an internal STP identifier within my path finder implementation so I can refer to an STP using a single string.
> 
> So there is a gap in definition between what we have defined as an STP identifier, and what is defined in the nsi-ext specification.  We have taken multiple fields from NML objects and composed a complex STP Identifier:
> 
> NSI CS STP Identifier = {
> 	networkId = NML Topology Identifier;
> 	localId = NML BidirectionalPort Identifier
> 	choice {
> 		label = NML Unidirectional Port Label; 
> 		labelGroup = NML Unidirectional PortGroup LabelGroup;
> 	}
> }
> 
> To compare the content of the two, here is an example of an STP from the Netherlight topology:
> 
> <sourceStp>
> 	<networkId>urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed</networkId>
> 	<localId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1</localId>
> 	<label type="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1781</label>
> </sourceStp>
> 
> versus something like this:
> 
> urn:ogf:network:netherlight.net:2013:a-gole:testbed:port:uva:1?vlan=1781
> 
> where "urn:ogf:network:netherlight.net:2013:a-gole:testbed:" is the network portion, and "port:uva:1?vlan=1781" is the local portion.
> 
> I must admit I am questioning the value of our complex STP definition.  I understand the value of the being able to route on networkId, and the issue with URN opaqueness, but if we are constructing the URN following a specific set of rules, could we also not parse it similarly?
> 
> John
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg