Determining the Network of an STP
During today's call, Jerry brought up the following issue: (Jerry, please correct me if I'm wrong, and sorry if I mixed up the NSI with the NML terminology). A path computation engine needs to know in which domain a STP lies. There are solutions to this: 1. The domain can be inferred by parsing the URN identifier of the STP. 2. Each domain announces a full list of it's STPs, and the path computation engine keeps a table of all STP-Domain relations. 3. Each connection request must not only list the URN of the STP, but the URN of the domain as well. The current solution is (1), but that conflicts with the choice in NML that a URN may not contain the domain identifier and should not be interpreted/parsed. Solution (2) or (3) do not have this drawback. Solution (2) seems less scalable compared to solution (3). Regards, Freek
Hi Freek- you are essentially correct. But there is some added comments inline. On 6/27/12 6:00 PM, Freek Dijkstra wrote:
During today's call, Jerry brought up the following issue: (Jerry, please correct me if I'm wrong, and sorry if I mixed up the NSI with the NML terminology).
A path computation engine needs to know in which domain a STP lies. Bingo. At least for the inter-domain environment in which NSI operates.
There are solutions to this: 1. The domain can be inferred by parsing the URN identifier of the STP. 2. Each domain announces a full list of it's STPs, and the path computation engine keeps a table of all STP-Domain relations 3. Each connection request must not only list the URN of the STP, but the URN of the domain as well.
The current solution is (1), but that conflicts with the choice in NML that a URN may not contain the domain identifier and should not be interpreted/parsed. Solution (2) or (3) do not have this drawback. Solution (2) seems less scalable compared to solution (3). #1 was adopted by NSI WG in SLC last summer as an interim approach for v1 topology. A lot of issues were still unclear, so we took the interim step to use the simple DToX model (and we even needed to modify it a bit too.) Part of this decision included munging the 2-tuple STP name into a single URN string (this was not a unanimous approach - but it got us off the mark.) This #1 approach does require that NSA aggregators need to parse the STP URN to determine the home network - I am not strictly opposed to parsing an *NSI* STP name to decompose it into some structural components, but I do agree that parsing a *URN* specifically is counter to the purpose of a URN. And mapping any content or structure onto a URN besides administrative scoping is almost always a bad idea. (I think some v1.x implementations cheated with this approach and used the RDF topology as a directory to look up STP URNs to get name-domain mappings...while this avoided parsing the URN, it is not strictly conformant to the NSI framework and breaks if the STPs are not all defined in the topology. The NSI framework will work as long as the STP 2-tuples are used for STP references. )
#2 is essentially a directory service - whether your distribute STPs as part of the topology or as a separate phonebook, you have the same problem: All STPs must be defined and announced in this global directory before they can be used in a Reservation Request. This phonebook/directory service is computationally tractable, but it nonetheless has scalability issues for a global inter-domain service like NSI. It is centralized (bad), or it is distributed (requiring complex protocol to keep it coherent and convergent.) And frankly, for simple end system STPs it is unnecessary as long as the STP reference includes the network id innately - which it currently does. Unless we want a flat name space without hierarchical structure, then our 2-tuple model provides a basic hierarchical interdomain mapping that precludes the need for a global STP directory service. I would phrase #3 a bit differently: The STP name is already and *by definition* a 2-tuple consisting of the network (domain) identifier and a local identifier. These two elements together comprise the STP name. I would suggest that an STP reference might be a compound object ala: <stp_ref> <net_id>nordu.net</net_id> <loc_id>svr1-1-204</loc_id> </stp_ref> This #3 is (IMO) the best solution. It explicitly delineates the <networkid> component from the <localid> component - which means parsing a single string or URN is not required, and the name-domain mapping is explicit in the reference precluding the need for a directory. With the compound reference, as long as the network can be found in the topology, the NSI PF does not need to know specifically how to route to the local end point. the local NSA will resolve that internally. I would surmise that this compound STP object could still be given a URN, which would make it useable within the current RDF/OWL topology. But this then would re-introduce the need for directories. The aspect that I like about #3 using the compound reference is that it allows us to separate the naming of objects internal to the NSI code implementations from the names that users and engineers may wish to use to identify their networks and end points more generally and which users will wish to use when specifiying their requests. The URNs for user interfacing are horrid. One last observation: By referencing STPs as compound objects we obviate the need for global directories. We also do not need to define STPs globaly if/when they only have local significance. (An STP is "only locally significant" if it does not share an SDP with another network.) Thus we don't need to advertise these local only end point names in topology as the path finders get what they need from the STP reference itself. However, this *does not* preclude the need to advertise STPs that *are* part of an NSI SDP adjacency(!!). These adjacencies must still be advertised as part of the topology - indeed, these SDPs define the topology, the inter-connectivity among networks. Hope this helps! Have a nice weekend! Jerry
Regards, Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
LOL - That is how I originally defined the STP in our NSI schema but you Jerry argued against it and made me change it to a string!!!! I think I might start ignoring you and do what I think is best. It seems to be the correct answer in the end ;-) On 2012-06-29, at 12:37 PM, Jerry Sobieski wrote:
I would phrase #3 a bit differently: The STP name is already and *by definition* a 2-tuple consisting of the network (domain) identifier and a local identifier. These two elements together comprise the STP name. I would suggest that an STP reference might be a compound object ala: <stp_ref> <net_id>nordu.net</net_id> <loc_id>svr1-1-204</loc_id> </stp_ref>
This #3 is (IMO) the best solution. It explicitly delineates the <networkid> component from the <localid> component - which means parsing a single string or URN is not required, and the name-domain mapping is explicit in the reference precluding the need for a directory. With the compound reference, as long as the network can be found in the topology, the NSI PF does not need to know specifically how to route to the local end point. the local NSA will resolve that internally.
Aside from the snarky comments, I guess we agree that solution #3 is best from these listed solutions:
A path computation engine needs to know in which domain a STP lies.
There are solutions to this: 1. The domain can be inferred by parsing the URN identifier of the STP. 2. Each domain announces a full list of it's STPs, and the path computation engine keeps a table of all STP-Domain relations. 3. Each connection request must not only list the URN of the STP, but the URN of the domain as well.
There is an open questions which variant to use: A connection request must contain for each endpoint ... 3a. ... a globally unique identifier of the network (*) and a STP identifier that is unique within the context of this network. or 3b. ... a globally unique identifier of the network (*) and a globally unique STP identifier. For the record, ITU-T G.800 seems to follow 3a, while NML chose 3b. The reason for NML was that 3b removed the need for scopes -- so NML would also work in a scenario where the STP identifier is known, but the Topology (network) identifier is unknown. Arguably this leads to a bit of redundancy in the identifier in this use case. I nevertheless argue that it is useful to use the same identifier as NML uses. The alternative is either to maintain a NSI-NML identifier lookup table, or a proposal to the NML group to revert the earlier choice, along with a clear definition how to identify Ports, remembering that Ports can be identified both in the scope of a network, as well is scope of a device (without further knowledge of the network). Freek (*) I use the terms "topology", "network" and "domain" interchangeably in this email. I'm referring to the concept of NML Topology or NSI Network.
On Mon, 2 Jul 2012, Freek Dijkstra wrote:
There is an open questions which variant to use:
A connection request must contain for each endpoint ... 3a. ... a globally unique identifier of the network (*) and a STP identifier that is unique within the context of this network.
This strikes me as the obvious one. (but I am not a topology expert - and I don't think I want to be).
3b. ... a globally unique identifier of the network (*) and a globally unique STP identifier.
How will you make a globally unique STP identifier without putting the network in it? (and in a way that makes sense please). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On 04-07-2012 14:27, Henrik Thostrup Jensen wrote:
How will you make a globally unique STP identifier without putting the network in it? (and in a way that makes sense please).
Here is a globally unique identifier: urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66 (created by following the first link on Google using `create uuid', and prepending urn:uuid: as per RFC 4122) As the proud owner of this UUID identifier, I hereby certify that I will use it to represent a STP in my home network. There you go. Freek PS: Yes, the urn:ogf:network syntax is much prettier, but there is nothing that prevents me from using the above, and they are essentially the same thing -- persistent, globally unique identifiers.
On Wed, 4 Jul 2012, Freek Dijkstra wrote:
How will you make a globally unique STP identifier without putting the network in it? (and in a way that makes sense please).
Here is a globally unique identifier: urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66 (created by following the first link on Google using `create uuid', and prepending urn:uuid: as per RFC 4122)
As the proud owner of this UUID identifier, I hereby certify that I will use it to represent a STP in my home network.
There you go.
I said in a way that made sense :-) Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On 05-07-2012 10:18, Henrik Thostrup Jensen wrote:
How will you make a globally unique STP identifier without putting the network in it? (and in a way that makes sense please).
Here is a globally unique identifier: urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66
As the proud owner of this UUID identifier, I hereby certify that I will use it to represent a STP in my home network.
I said in a way that made sense :-)
You asked how I made a globally unique STP, and the procedure was really simple:
(created by following the first link on Google using `create uuid', and prepending urn:uuid: as per RFC 4122)
I understand there are more ways to create an globally unique identifier, but to me this makes perfect sense. After all, an identifier is just that, an identifier: a persistent globally unique name. There is no need to add any meaning to it. Any meaning should be taken from the context. If you feel better if I add some syntactic context, here you are: <nsi:STP id="urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66"> <nsi:network idRef="urn:ogf:network:nordunet.net:2011:org"/> </nsi:STP> This tells you that the above identifier represent a STP, and in which network it is located. Does this make more sense to you? urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66 is not that different from the identifier "urn:isbn:9780300124873", which you may recognize as a book identifier. This may give you a bit of context about the publisher (just like a urn:ogf:network identifier may tell you a bit about the organisation that assigned the URN), but doesn't tell you everything: it does not tell you the author or the name of the publisher. That's information that you need to get from either a lookup service, or the context. I propose for NSI to simply add this context in the original request. If you are more interested in a distributed lookup service, that's also possible: I recommend to look at a Resolution Discovery System (RDS) [RFC 2276] such as Dynamic Delegation Discovery System (DDDS) [RFC 3401-3405]. Regards, Freek
So if we were to go with:
<nsi:STP id="urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66"> <nsi:network idRef="urn:ogf:network:nordunet.net:2011:org"/> </nsi:STP>
Would I add the VLAN ID as per Jeroen's proposal: <nsi:STP id="urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66?vlan=1791"> <nsi:network idRef="urn:ogf:network:nordunet.net:2011:org"/> </nsi:STP> Just trying to understand how these different proposals come together. Thanks, John On 2012-07-05, at 1:51 PM, Freek Dijkstra wrote:
On 05-07-2012 10:18, Henrik Thostrup Jensen wrote:
How will you make a globally unique STP identifier without putting the network in it? (and in a way that makes sense please).
Here is a globally unique identifier: urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66
As the proud owner of this UUID identifier, I hereby certify that I will use it to represent a STP in my home network.
I said in a way that made sense :-)
You asked how I made a globally unique STP, and the procedure was really simple:
(created by following the first link on Google using `create uuid', and prepending urn:uuid: as per RFC 4122)
I understand there are more ways to create an globally unique identifier, but to me this makes perfect sense. After all, an identifier is just that, an identifier: a persistent globally unique name. There is no need to add any meaning to it. Any meaning should be taken from the context.
If you feel better if I add some syntactic context, here you are:
<nsi:STP id="urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66"> <nsi:network idRef="urn:ogf:network:nordunet.net:2011:org"/> </nsi:STP>
This tells you that the above identifier represent a STP, and in which network it is located. Does this make more sense to you?
urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66 is not that different from the identifier "urn:isbn:9780300124873", which you may recognize as a book identifier. This may give you a bit of context about the publisher (just like a urn:ogf:network identifier may tell you a bit about the organisation that assigned the URN), but doesn't tell you everything: it does not tell you the author or the name of the publisher. That's information that you need to get from either a lookup service, or the context.
I propose for NSI to simply add this context in the original request. If you are more interested in a distributed lookup service, that's also possible: I recommend to look at a Resolution Discovery System (RDS) [RFC 2276] such as Dynamic Delegation Discovery System (DDDS) [RFC 3401-3405].
Regards, Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, On 6 Jul 2012, at 01:02, John MacAuley wrote:
So if we were to go with:
<nsi:STP id="urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66"> <nsi:network idRef="urn:ogf:network:nordunet.net:2011:org"/> </nsi:STP>
Would I add the VLAN ID as per Jeroen's proposal:
<nsi:STP id="urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66?vlan=1791"> <nsi:network idRef="urn:ogf:network:nordunet.net:2011:org"/> </nsi:STP>
Just trying to understand how these different proposals come together.
Yes, that's exactly how that would work. In that case the urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66 would point to a PortGroup (STPGroup) and vlan=1791 identifies a single element of that group. It is possible for the NSI to restrict the identifier form to the "urn:ogf:network:example.com:2012:stp:exampleport" form. That would have to become part of the standard then though. Jeroen.
On 06-07-2012 01:02, John MacAuley wrote:
So if we were to go with:
<nsi:STP id="urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66"> <nsi:network idRef="urn:ogf:network:nordunet.net:2011:org"/> </nsi:STP>
Would I add the VLAN ID as per Jeroen's proposal:
<nsi:STP id="urn:uuid:66314cd0-c5f2-11e1-9b21-0800200c9a66?vlan=1791"> <nsi:network idRef="urn:ogf:network:nordunet.net:2011:org"/> </nsi:STP>
For the record, I do not propose this specific syntax for NSI. I was mostly making a point that it is very well possible to create a globally unique identifier without including the name of a network _in the URN_. If we agree on the principle idea of providing both network and STP name in a request, I am happy to give a practical example (which will include the "?vlan=1791" Port selector). I hadn't done that yet, because that will open some new questions on how to deal with unidirectional or bidirectional ports, as well as dealing with multipoint-to-multipoint connections. Freek
John MacAuley wrote:
Just trying to understand how these different proposals come together.
Here is a more realistic NSI sample (namespaces are left out of simplicity, and I just made up some NSI names, as I'm not familiar with the NSI syntax):
<connectionrequest> .... <endpoints> <endpoint> <Topology>urn:ogf:network:nordu.net:2012:org</Topology> <source>urn:ogf:network:nordu.net:2012:onsala-tx?vlan=1791</source> <sink>urn:ogf:network:nordu.net:2012:onsala-rx?vlan=1791</sink> </endpoint> <endpoint> <Topology>urn:ogf:network:sne.science.uva.nl:2012:org</Topology> <source>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress?vlan=1791</source> <sink>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-ingress?vlan=1791</sink> </endpoint> </endpoints> .... </connectionrequest>
This syntax allows multipoint-to-multipoint connections, if desired. The nml:Topology tells the recipient in what NSAnetwork the endpoint is located. NML is unidirectional, and the explicit source and sink makes sure the direction is unambiguous. These sources and sinks contain URNs of a PortGroup, with a query part added ("?vlan=1791") that uniquely identifies a single Port within the PortGroup. It is also possible to use a URN that just defines a Port directly (without the query part). I can imagine that a NSI requester does not care about the specific VLAN that is chosen, and likes to say "just pick any VLAN in this PortGroup". How exactly that is done, and how to distinguish it from "please connect ALL VLANs in this PortGroup" is an open question for NSI to answer. Regards, Freek
So the <Topology> party is to allow an intermediate NSA to route the message to the target domain without needing to know the STPs within that domain? On 2012-07-06, at 7:14 AM, Freek Dijkstra wrote:
John MacAuley wrote:
Just trying to understand how these different proposals come together.
Here is a more realistic NSI sample (namespaces are left out of simplicity, and I just made up some NSI names, as I'm not familiar with the NSI syntax):
<connectionrequest> .... <endpoints> <endpoint> <Topology>urn:ogf:network:nordu.net:2012:org</Topology> <source>urn:ogf:network:nordu.net:2012:onsala-tx?vlan=1791</source> <sink>urn:ogf:network:nordu.net:2012:onsala-rx?vlan=1791</sink> </endpoint> <endpoint> <Topology>urn:ogf:network:sne.science.uva.nl:2012:org</Topology> <source>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress?vlan=1791</source> <sink>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-ingress?vlan=1791</sink> </endpoint> </endpoints> .... </connectionrequest>
This syntax allows multipoint-to-multipoint connections, if desired. The nml:Topology tells the recipient in what NSAnetwork the endpoint is located. NML is unidirectional, and the explicit source and sink makes sure the direction is unambiguous. These sources and sinks contain URNs of a PortGroup, with a query part added ("?vlan=1791") that uniquely identifies a single Port within the PortGroup. It is also possible to use a URN that just defines a Port directly (without the query part).
I can imagine that a NSI requester does not care about the specific VLAN that is chosen, and likes to say "just pick any VLAN in this PortGroup". How exactly that is done, and how to distinguish it from "please connect ALL VLANs in this PortGroup" is an open question for NSI to answer.
Regards, Freek
On Jul 6, 2012, at 7:14 AM, Freek Dijkstra wrote:
John MacAuley wrote:
Just trying to understand how these different proposals come together.
Here is a more realistic NSI sample (namespaces are left out of simplicity, and I just made up some NSI names, as I'm not familiar with the NSI syntax):
<connectionrequest> .... <endpoints> <endpoint> <Topology>urn:ogf:network:nordu.net:2012:org</Topology> <source>urn:ogf:network:nordu.net:2012:onsala-tx?vlan=1791</source> <sink>urn:ogf:network:nordu.net:2012:onsala-rx?vlan=1791</sink> </endpoint> <endpoint> <Topology>urn:ogf:network:sne.science.uva.nl:2012:org</Topology> <source>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress?vlan=1791</source> <sink>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-ingress?vlan=1791</sink> </endpoint> </endpoints> .... </connectionrequest>
This syntax allows multipoint-to-multipoint connections, if desired. The nml:Topology tells the recipient in what NSAnetwork the endpoint is located. NML is unidirectional, and the explicit source and sink makes sure the direction is unambiguous. These sources and sinks contain URNs of a PortGroup, with a query part added ("?vlan=1791") that uniquely identifies a single Port within the PortGroup. It is also possible to use a URN that just defines a Port directly (without the query part).
The query stuff may have just been shorthand, but in case it's not, overloading the URN to include a query parameter seems a bad idea to me. I'd rather see something like (all in short-hand): <source> <port> <port_group idRef="urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress" /> <vlan>1791</vlan> </port> </source> For the "connect any vlan", you could presumably leave the vlan parameter out: <source> <port> <port_group idRef="urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress" /> </port> </source> You could presumably override the set of 'any' VLANs by doing something like: <source> <port> <port_group idRef="urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress"> <vlans>1790-1800</vlans> </port_group> </port> </source> I'm not positive what the "connect ALL vlans" would look like because I'm not sure what the result of that operation would be. i.e. would it be a port with multiple VLANs, or would it be a PortGroup that functions as a port, or would it be a ridiculous number of ports (depending on how many VLANs are in the PortGroup)? Cheers, Aaron
I can imagine that a NSI requester does not care about the specific VLAN that is chosen, and likes to say "just pick any VLAN in this PortGroup". How exactly that is done, and how to distinguish it from "please connect ALL VLANs in this PortGroup" is an open question for NSI to answer.
Regards, Freek _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
On Thu, 28 Jun 2012, Freek Dijkstra wrote:
The current solution is (1), but that conflicts with the choice in NML that a URN may not contain the domain identifier and should not be interpreted/parsed.
I understand that you do not want to have things like vlans and such in the STP, but these requirements seem somewhat strict. How did you come with these? All URNs require some parsing to split the namespace and ns-specific part. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (6)
-
Aaron Brown -
Freek Dijkstra -
Henrik Thostrup Jensen -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley