NSI topology representation using NML
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
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
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
Of course, we always do have the option of encoding structure into the STP identifier similar to X.500/LDAP common names and remove the need for a separate network Identifier. This would bind the name of a resource to a network (and they name of that network). If the resource ever changed networks it would get a new name rooted under the network portion of the common name. I think we are at a decision point now, and need input from the group: 1. Continue with the opaque STP Identifier strategy and implement the change described below; 2. Implement a hierarchical STP identifier composed of a network identifier portion and a local identifier portion. Thank you, John On 2013-11-28, at 8:17 PM, John MacAuley <john.macauley@surfnet.nl> wrote:
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
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi John, For my understanding. Given the following topology description fragment: <BidirectionalPort id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232"> <Port id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232:out"/> <Port id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232:in"/> </BidirectionalPort> <Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> <Port id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232:out"> <Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1799</Label> </Port> </Relation> <Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <Port id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232:in"> <Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1799</Label> </Port> </Relation> In a reserve request, are the following two STP IDs equivalent and is either of them allowed? On 29/11/13 02:17, John MacAuley wrote:
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
nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hmm, accidentally hit the send button :( On 04/12/13 14:09, Hans Trompert wrote:
For my understanding. Given the following topology description fragment:
<BidirectionalPort id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232"> <Port id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232:out"/> <Port id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232:in"/> </BidirectionalPort> <Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> <Port id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232:out"> <Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1799</Label> </Port> </Relation> <Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <Port id="urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232:in"> <Label labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1799</Label> </Port> </Relation>
In a reserve request, are the following two STP IDs equivalent and is either of them allowed?
<stpId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232?vlan=1799</stpId> and <stpId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232</stpId> Another advantage of folding the labels into the stpId is that it will be less messy to specify the source and destination STP in a reserve request when the STPs are from different service domains, one domain with labels and one without labels, for example an EVPL domain and an EPL domain. HansT.
On 29/11/13 02:17, John MacAuley wrote:
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
nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Technically the one without the vlan is underspecified, but resolves to the single STP with the vlan. On 2013-12-04, at 8:16 AM, Hans Trompert <hans.trompert@surfnet.nl> wrote:
<stpId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232?vlan=1799</stpId>
and
<stpId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:232</stpId>
Another advantage of folding the labels into the stpId is that it will be less messy to specify the source and destination STP in a reserve request when the STPs are from different service domains, one domain with labels and one without labels, for example an EVPL domain and an EPL domain.
HansT.
Hi On Wed, 27 Nov 2013, John MacAuley wrote:
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.
This wouldn't work with the current NML structure, as you cannot encode network (topology) id and port id in the same urn, unless you restrict the naming somehow.
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?
So, I can argue for both things here, and we have discussed this issue at least once before AFAIK. However, as I see it, this does not change anything fundemental in the protocol. So I don't really see a reason for it, as the current moment. I'd much rather try and get this thing out the door. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (4)
-
Hans Trompert -
Henrik Thostrup Jensen -
Jeroen van der Ham -
John MacAuley