Peoples, I discussed the slightly cryptic response from Jeroen. I now have the context and will explain what I believe is his primary point. urn:ogf:network:example.net:2013:A2?vlan=1781 The above STP identifier contains an opaque portion (urn:ogf:network:example.net:2013:A2) that will never change for the life of the resource and is globally unique. The only part of the STP that can be safely "looked at" is the portion after the "?", which can be variable based on whether the STP is fully qualified or under specified. I think we can all remember the discussion about formulating a URN that never changes for the life of the resource. Jeroen was reminding us of this fact. This means that we cannot derive any information from the STP identifier except an equality test against another STP. I am not permitted to determine the identity of the network an STP is a member of by looking at anything within the URN. I can only determine this by searching for the STP identifier within the defined topology of each network. In our P2PS service we are specifying more than what we would consider the STP Identifier to allow for routing by networkId. We also break out the label as it is done in NML: <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> I believe we can normalize our naming by changing the definition of what we are including in the STP within the P2PS service: <sourceStp> <networkId>urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed</networkId> <stpId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1?vlan=1781</stpId> </sourceStp> We maintain the networkId in the request for loose routing, but it is no longer part of the STP identifier. The stpId component is inline with what Jeroen has defined for the STP Identifier, and the separate Label and LabelGroup are dropped as the information is included in the stpId. Specification of the part after the "?" in the stpId follows the same rules we would have used in the Label and LabelGroup within NML. John On 2013-11-28, at 4:09 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg