Dear members of the NSI community, In last call, I promised you an alternative proposal for identifiers. Here it is. In addition, I've included a FAQ to explain the reasoning behind the current NURN (the urn:ogf:network identifiers). We have to change the currently used URNs, so my proposal is as follows: Encode the network identifier in the FQDN. E.g. currently (No Network ID in the NURN): urn:ogf:network:surfnet.nl:1990:port:surfnet6:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1 Uppsala proposal (Network ID in the OPAQUE part): urn:ogf:network:surfnet.nl:1990:surfnet6:port:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1 change it to: urn:ogf:network:surfnet6.surfnet.nl:1990:port:production:2677 urn:ogf:network:manlan.es.net:2013:aofa:1 My apologies for Submitting Yet Another Proposal, John. It is clear that the Uppsala proposal violates the GFD.202 standard (which states that the OPAQUE part of the NURN should not be interpreted), but it took me till this weekend to come up with a counter proposal that did not contain some other drawbacks. The advantage is that this proposal does not violate the existing NURN specification. It is actually possible to keep existing URNs the same, if so desired. I can't think of any disadvantages compared to the proposal that was put forward in Uppsala. That said, the two proposals still shares some disadvantages, but those are inherent to the choice on URNs for identifiers (as I said privately and publically earlier, in retrospect I think we should have chosen the Handle system instead of the URN system. That would have prevented us from re-inventing the idea of a document exchange service.) For those interested, I wrote the FAQ below to help me rethink this problem. FAQ # What is a NURN? NURN stands for "network URN". It is an identifier of the form urn:ogf:network:*. It is defined in GFD.202. # What is the syntax of a NURN? NURN = "urn:ogf:network:" ORGID ":" OPAQUE-PART *1QUERY *1FRAGMENT with ORGID, the ID of an assigning organisation. ORGID = FQDN ":" DATE # What are the properties of a URN? (and thus of a NURN)? * It is globally unique (no name collisions) * It is persistent (not re-used) * It is an identifier (without meaning) # What is an identifier? A label, without meaning, to uniquely identify something. It should not be confused with an address (which tells you where to find this thing) or a route (which tells you how to get there). # Why can't an identifier have a meaning? A resource has properties. If these properties are encoded in an identifier, the identifier is no longer persistent if these properties change. For example, the port number are properties that may change if you buy a new switch, and should in general not be part of an STP identifier. (You don't want to change STP just because you do some internal changes in the network that are irrelevant to your network peers). # Why is the local part OPAQUE? To prevent users from adding volatile properties to the identifier, or worse, parse the identifier to extract these properties, only to find out that the identifier object no longer holds these properties. # How is a NURN globally unique? To avoid global naming collisions, each entity that assigns URNs gets it's own prefix, the ORGID. Each entity (the assigning organisation) is responsible to avoid local naming collisions. # Who assigns ORGID prefixes? It is not assigned, it can be generated. Usually, a naming authority is established. For example, IANA is responsible for the "urn:" namespace, and OGF is responsible for the "urn:ogf:" delegated namespace. For "urn:ogf:network:", we didn't want to devise a new formal organisation within the OGF, which at the time was already in decline. So we decided to simply re-use an existing naming authority: DNS. # Why does ORGID contain a FQDN? We originally thought we could use this as a topology exchange system: given a NURN, find the FQDN, do a DNS lookup for the SRV record for the appropriate service, and fetch it from the returned URL. # Why does ORGID contain a DATE? We quickly got feedback for the IETF URN community that a DNS name is globally unique, but not persistent. It may change over time. To compensate, we simply added a DATE: the owner of a FQDN is unique for a given moment in time. This way we avoid naming conflicts, even if a DNS zone is transferred to a different owner. # What happened to the idea of the topology exchange using the FQDN? It became moot with the addition of the DATE, as the FQDN would no longer have to be unique. At the time, we thought this was good idea, as we liked the idea of an identifier with less meaning. See the question on "Why can't an identifier have a meaning" above. In retrospect, this should have been the time to look at other identifiers schemas which contain both properties: no meaning, and yet a lookup service (e.g. ARK or Handle). # But what's the meaning of the ORGID? Nothing. It has no meaning (anymore). It is just a unique prefix. It could have been randomly chosen. In retrospect, perhaps we should have used the SHA-2 of FQDN + DATE. In the above proposal, it would regain a meaning: that of the network identifier. # Why does the NURN currently not contain a Network ID? Because of flexibility requirements. At the time this was drafted, there was a need for subtopologies, merging of topologies, splitting of topologies, and the option of migrating STPs from one Topology to another (e.g. from the testbed to production). This is non-trivial with the current proposals (although I can think of some ways to add this functionality). # What's the disadvantage of the no-meaning doctrine? Well, since identifier have no meaning, any attributes and relations need to be made explicit. # Why not a hierarchical schema? We thought of a schema along the line of network_ID:node_ID:port_ID:link_ID, but decided against it, particular to avoid meaning in the URN. Such schema would disallow a multi-homed setup. Instead, we thought that a lookup system and explicit relation would be better. # Without a hierarchy, how to I know if two identifers are related? You don't. So it is fully possible in NML to create a two VLAN on a link and use two wildly different identifiers for the two VLANs. This is ugly indeed, but we though this disadvantage would be outweighed by the advantage of flexibility. # How to group two or more VLANs? Use a PortGroup or LinkGroup in NML. # How to select a VLAN in a group? Originally, this was very bad in NML. It entailled looking up the different Ports in a PortGroup, and checking the Label of each Port. This did not scale, as each identifier may be wildly different, so each network would have to publish a large Topology file. Instead, we used a trick: the query component. Just take the URN of the PortGroup, add a query component somehow selecting a specific Port within that group (e.g. by its label), and you have the right Port. # Is the query component part of a URN? Yes and No. No, it is not part of the PortGroup URN. Yes, it is part of the URN that 'selects' the Port URN from the PortGroup URN + Query component. It is not part of the Port URN. E.g. urn.ogf.network:example.net:2011:portgroup:312?vlan=42 may return urn.ogf.network:example.net:2011:port:312_42 # Are query coponents allowed in a URN? First of all, it can be argued that the query component is not formally part of the PortGroup URN, Not yet, but we expect it will be published shortly. https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn#section-4.3 # Why is there a vlan in the query component, not the label? This was not really thought-through. Pick your answer: - to allow for PortGroups with multiple labels (e.g. create a PortGroup with all VLANs in multiple WDM wavelength. You can now select the Port by VLAN + wavelength.) - this was a mistake, it should have been <portgroup ID>?label=<label> instead of <portgroup ID>?vlan=<label>. # What kind of lookup systems do exist? For URN, I'm only aware of Dynamic Delegation Discovery System (DDDS) (RFC 3402), but I haven't come accross any implementation. Handle has a lookup service. E.g. resolve 10.5240/5868-409E-7BFB-536A-6067-E (movie record), 10.1016/j.future.2006.03.007 (publication) or 11230/f461a01a-9254-11e3-ba1c-d89d6771dd88 (scientific data) at any of the existing lookup services. E.g. hdl.handle.net or dx.doi.org. I'm not familiar enough with ARK to know those lookup services. # Why a URN instead of Handle system? Because we made a mistake. # Why not the handle system after all? Every proposal in the NSI faces Much Discussion. I lost the energy. We're good at re-inventing the wheel. Let's continue doing that. -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Wed | Thu |
Hi Freek, Nice proposal. Below a couple of quick question to check if I understand things correctly: * if I have multiple topologies I can either use different TLDs to name them or different sub domains or a combination of both(?) * if I use sub domains I need to register the name by adding a SOA record to one of the TLDs I own(?) * the topology ID will always be a NURN without the opaque part, for example: urn:ogf:network:testbed.surfnet.nl:2014: if I use a sub domain to name my topology(?) Cheers, HansT. On 15/10/14 13:14, Freek Dijkstra wrote:
Dear members of the NSI community,
In last call, I promised you an alternative proposal for identifiers. Here it is. In addition, I've included a FAQ to explain the reasoning behind the current NURN (the urn:ogf:network identifiers).
We have to change the currently used URNs, so my proposal is as follows:
Encode the network identifier in the FQDN.
E.g. currently (No Network ID in the NURN): urn:ogf:network:surfnet.nl:1990:port:surfnet6:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1
Uppsala proposal (Network ID in the OPAQUE part): urn:ogf:network:surfnet.nl:1990:surfnet6:port:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1
change it to: urn:ogf:network:surfnet6.surfnet.nl:1990:port:production:2677 urn:ogf:network:manlan.es.net:2013:aofa:1
My apologies for Submitting Yet Another Proposal, John. It is clear that the Uppsala proposal violates the GFD.202 standard (which states that the OPAQUE part of the NURN should not be interpreted), but it took me till this weekend to come up with a counter proposal that did not contain some other drawbacks.
The advantage is that this proposal does not violate the existing NURN specification. It is actually possible to keep existing URNs the same, if so desired.
I can't think of any disadvantages compared to the proposal that was put forward in Uppsala.
That said, the two proposals still shares some disadvantages, but those are inherent to the choice on URNs for identifiers (as I said privately and publically earlier, in retrospect I think we should have chosen the Handle system instead of the URN system. That would have prevented us from re-inventing the idea of a document exchange service.)
For those interested, I wrote the FAQ below to help me rethink this problem.
FAQ
# What is a NURN?
NURN stands for "network URN". It is an identifier of the form urn:ogf:network:*. It is defined in GFD.202.
# What is the syntax of a NURN?
NURN = "urn:ogf:network:" ORGID ":" OPAQUE-PART *1QUERY *1FRAGMENT with ORGID, the ID of an assigning organisation. ORGID = FQDN ":" DATE
# What are the properties of a URN? (and thus of a NURN)?
* It is globally unique (no name collisions) * It is persistent (not re-used) * It is an identifier (without meaning)
# What is an identifier?
A label, without meaning, to uniquely identify something. It should not be confused with an address (which tells you where to find this thing) or a route (which tells you how to get there).
# Why can't an identifier have a meaning?
A resource has properties. If these properties are encoded in an identifier, the identifier is no longer persistent if these properties change. For example, the port number are properties that may change if you buy a new switch, and should in general not be part of an STP identifier. (You don't want to change STP just because you do some internal changes in the network that are irrelevant to your network peers).
# Why is the local part OPAQUE?
To prevent users from adding volatile properties to the identifier, or worse, parse the identifier to extract these properties, only to find out that the identifier object no longer holds these properties.
# How is a NURN globally unique?
To avoid global naming collisions, each entity that assigns URNs gets it's own prefix, the ORGID. Each entity (the assigning organisation) is responsible to avoid local naming collisions.
# Who assigns ORGID prefixes?
It is not assigned, it can be generated.
Usually, a naming authority is established. For example, IANA is responsible for the "urn:" namespace, and OGF is responsible for the "urn:ogf:" delegated namespace. For "urn:ogf:network:", we didn't want to devise a new formal organisation within the OGF, which at the time was already in decline. So we decided to simply re-use an existing naming authority: DNS.
# Why does ORGID contain a FQDN?
We originally thought we could use this as a topology exchange system: given a NURN, find the FQDN, do a DNS lookup for the SRV record for the appropriate service, and fetch it from the returned URL.
# Why does ORGID contain a DATE?
We quickly got feedback for the IETF URN community that a DNS name is globally unique, but not persistent. It may change over time. To compensate, we simply added a DATE: the owner of a FQDN is unique for a given moment in time. This way we avoid naming conflicts, even if a DNS zone is transferred to a different owner.
# What happened to the idea of the topology exchange using the FQDN?
It became moot with the addition of the DATE, as the FQDN would no longer have to be unique.
At the time, we thought this was good idea, as we liked the idea of an identifier with less meaning. See the question on "Why can't an identifier have a meaning" above.
In retrospect, this should have been the time to look at other identifiers schemas which contain both properties: no meaning, and yet a lookup service (e.g. ARK or Handle).
# But what's the meaning of the ORGID?
Nothing. It has no meaning (anymore). It is just a unique prefix. It could have been randomly chosen. In retrospect, perhaps we should have used the SHA-2 of FQDN + DATE.
In the above proposal, it would regain a meaning: that of the network identifier.
# Why does the NURN currently not contain a Network ID?
Because of flexibility requirements. At the time this was drafted, there was a need for subtopologies, merging of topologies, splitting of topologies, and the option of migrating STPs from one Topology to another (e.g. from the testbed to production). This is non-trivial with the current proposals (although I can think of some ways to add this functionality).
# What's the disadvantage of the no-meaning doctrine?
Well, since identifier have no meaning, any attributes and relations need to be made explicit.
# Why not a hierarchical schema?
We thought of a schema along the line of network_ID:node_ID:port_ID:link_ID, but decided against it, particular to avoid meaning in the URN. Such schema would disallow a multi-homed setup. Instead, we thought that a lookup system and explicit relation would be better.
# Without a hierarchy, how to I know if two identifers are related?
You don't. So it is fully possible in NML to create a two VLAN on a link and use two wildly different identifiers for the two VLANs. This is ugly indeed, but we though this disadvantage would be outweighed by the advantage of flexibility.
# How to group two or more VLANs?
Use a PortGroup or LinkGroup in NML.
# How to select a VLAN in a group?
Originally, this was very bad in NML. It entailled looking up the different Ports in a PortGroup, and checking the Label of each Port. This did not scale, as each identifier may be wildly different, so each network would have to publish a large Topology file.
Instead, we used a trick: the query component. Just take the URN of the PortGroup, add a query component somehow selecting a specific Port within that group (e.g. by its label), and you have the right Port.
# Is the query component part of a URN?
Yes and No. No, it is not part of the PortGroup URN. Yes, it is part of the URN that 'selects' the Port URN from the PortGroup URN + Query component. It is not part of the Port URN. E.g. urn.ogf.network:example.net:2011:portgroup:312?vlan=42 may return urn.ogf.network:example.net:2011:port:312_42
# Are query coponents allowed in a URN?
First of all, it can be argued that the query component is not formally part of the PortGroup URN,
Not yet, but we expect it will be published shortly. https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn#section-4.3
# Why is there a vlan in the query component, not the label?
This was not really thought-through. Pick your answer: - to allow for PortGroups with multiple labels (e.g. create a PortGroup with all VLANs in multiple WDM wavelength. You can now select the Port by VLAN + wavelength.) - this was a mistake, it should have been <portgroup ID>?label=<label> instead of <portgroup ID>?vlan=<label>.
# What kind of lookup systems do exist?
For URN, I'm only aware of Dynamic Delegation Discovery System (DDDS) (RFC 3402), but I haven't come accross any implementation.
Handle has a lookup service. E.g. resolve 10.5240/5868-409E-7BFB-536A-6067-E (movie record), 10.1016/j.future.2006.03.007 (publication) or 11230/f461a01a-9254-11e3-ba1c-d89d6771dd88 (scientific data) at any of the existing lookup services. E.g. hdl.handle.net or dx.doi.org.
I'm not familiar enough with ARK to know those lookup services.
# Why a URN instead of Handle system?
Because we made a mistake.
# Why not the handle system after all?
Every proposal in the NSI faces Much Discussion. I lost the energy. We're good at re-inventing the wheel. Let's continue doing that.
Freek just pointed me to the minutes of last weeks call where I could read that his proposal was rejected. Interesting reasoning ... but I do miss an important implication of this decision: who is going to write the document about the new STP ID and is going to submit that to the OGF? Or are we just ignoring GFD.202 altogether? HansT. On 21/10/14 16:04, Hans Trompert wrote:
Hi Freek,
Nice proposal. Below a couple of quick question to check if I understand things correctly:
* if I have multiple topologies I can either use different TLDs to name them or different sub domains or a combination of both(?) * if I use sub domains I need to register the name by adding a SOA record to one of the TLDs I own(?) * the topology ID will always be a NURN without the opaque part, for example: urn:ogf:network:testbed.surfnet.nl:2014: if I use a sub domain to name my topology(?)
HansT.
On 15/10/14 13:14, Freek Dijkstra wrote:
Dear members of the NSI community,
In last call, I promised you an alternative proposal for identifiers. Here it is. In addition, I've included a FAQ to explain the reasoning behind the current NURN (the urn:ogf:network identifiers).
We have to change the currently used URNs, so my proposal is as follows:
Encode the network identifier in the FQDN.
E.g. currently (No Network ID in the NURN): urn:ogf:network:surfnet.nl:1990:port:surfnet6:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1
Uppsala proposal (Network ID in the OPAQUE part): urn:ogf:network:surfnet.nl:1990:surfnet6:port:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1
change it to: urn:ogf:network:surfnet6.surfnet.nl:1990:port:production:2677 urn:ogf:network:manlan.es.net:2013:aofa:1
My apologies for Submitting Yet Another Proposal, John. It is clear that the Uppsala proposal violates the GFD.202 standard (which states that the OPAQUE part of the NURN should not be interpreted), but it took me till this weekend to come up with a counter proposal that did not contain some other drawbacks.
The advantage is that this proposal does not violate the existing NURN specification. It is actually possible to keep existing URNs the same, if so desired.
I can't think of any disadvantages compared to the proposal that was put forward in Uppsala.
That said, the two proposals still shares some disadvantages, but those are inherent to the choice on URNs for identifiers (as I said privately and publically earlier, in retrospect I think we should have chosen the Handle system instead of the URN system. That would have prevented us from re-inventing the idea of a document exchange service.)
For those interested, I wrote the FAQ below to help me rethink this problem.
FAQ
# What is a NURN?
NURN stands for "network URN". It is an identifier of the form urn:ogf:network:*. It is defined in GFD.202.
# What is the syntax of a NURN?
NURN = "urn:ogf:network:" ORGID ":" OPAQUE-PART *1QUERY *1FRAGMENT with ORGID, the ID of an assigning organisation. ORGID = FQDN ":" DATE
# What are the properties of a URN? (and thus of a NURN)?
* It is globally unique (no name collisions) * It is persistent (not re-used) * It is an identifier (without meaning)
# What is an identifier?
A label, without meaning, to uniquely identify something. It should not be confused with an address (which tells you where to find this thing) or a route (which tells you how to get there).
# Why can't an identifier have a meaning?
A resource has properties. If these properties are encoded in an identifier, the identifier is no longer persistent if these properties change. For example, the port number are properties that may change if you buy a new switch, and should in general not be part of an STP identifier. (You don't want to change STP just because you do some internal changes in the network that are irrelevant to your network peers).
# Why is the local part OPAQUE?
To prevent users from adding volatile properties to the identifier, or worse, parse the identifier to extract these properties, only to find out that the identifier object no longer holds these properties.
# How is a NURN globally unique?
To avoid global naming collisions, each entity that assigns URNs gets it's own prefix, the ORGID. Each entity (the assigning organisation) is responsible to avoid local naming collisions.
# Who assigns ORGID prefixes?
It is not assigned, it can be generated.
Usually, a naming authority is established. For example, IANA is responsible for the "urn:" namespace, and OGF is responsible for the "urn:ogf:" delegated namespace. For "urn:ogf:network:", we didn't want to devise a new formal organisation within the OGF, which at the time was already in decline. So we decided to simply re-use an existing naming authority: DNS.
# Why does ORGID contain a FQDN?
We originally thought we could use this as a topology exchange system: given a NURN, find the FQDN, do a DNS lookup for the SRV record for the appropriate service, and fetch it from the returned URL.
# Why does ORGID contain a DATE?
We quickly got feedback for the IETF URN community that a DNS name is globally unique, but not persistent. It may change over time. To compensate, we simply added a DATE: the owner of a FQDN is unique for a given moment in time. This way we avoid naming conflicts, even if a DNS zone is transferred to a different owner.
# What happened to the idea of the topology exchange using the FQDN?
It became moot with the addition of the DATE, as the FQDN would no longer have to be unique.
At the time, we thought this was good idea, as we liked the idea of an identifier with less meaning. See the question on "Why can't an identifier have a meaning" above.
In retrospect, this should have been the time to look at other identifiers schemas which contain both properties: no meaning, and yet a lookup service (e.g. ARK or Handle).
# But what's the meaning of the ORGID?
Nothing. It has no meaning (anymore). It is just a unique prefix. It could have been randomly chosen. In retrospect, perhaps we should have used the SHA-2 of FQDN + DATE.
In the above proposal, it would regain a meaning: that of the network identifier.
# Why does the NURN currently not contain a Network ID?
Because of flexibility requirements. At the time this was drafted, there was a need for subtopologies, merging of topologies, splitting of topologies, and the option of migrating STPs from one Topology to another (e.g. from the testbed to production). This is non-trivial with the current proposals (although I can think of some ways to add this functionality).
# What's the disadvantage of the no-meaning doctrine?
Well, since identifier have no meaning, any attributes and relations need to be made explicit.
# Why not a hierarchical schema?
We thought of a schema along the line of network_ID:node_ID:port_ID:link_ID, but decided against it, particular to avoid meaning in the URN. Such schema would disallow a multi-homed setup. Instead, we thought that a lookup system and explicit relation would be better.
# Without a hierarchy, how to I know if two identifers are related?
You don't. So it is fully possible in NML to create a two VLAN on a link and use two wildly different identifiers for the two VLANs. This is ugly indeed, but we though this disadvantage would be outweighed by the advantage of flexibility.
# How to group two or more VLANs?
Use a PortGroup or LinkGroup in NML.
# How to select a VLAN in a group?
Originally, this was very bad in NML. It entailled looking up the different Ports in a PortGroup, and checking the Label of each Port. This did not scale, as each identifier may be wildly different, so each network would have to publish a large Topology file.
Instead, we used a trick: the query component. Just take the URN of the PortGroup, add a query component somehow selecting a specific Port within that group (e.g. by its label), and you have the right Port.
# Is the query component part of a URN?
Yes and No. No, it is not part of the PortGroup URN. Yes, it is part of the URN that 'selects' the Port URN from the PortGroup URN + Query component. It is not part of the Port URN. E.g. urn.ogf.network:example.net:2011:portgroup:312?vlan=42 may return urn.ogf.network:example.net:2011:port:312_42
# Are query coponents allowed in a URN?
First of all, it can be argued that the query component is not formally part of the PortGroup URN,
Not yet, but we expect it will be published shortly. https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn#section-4.3
# Why is there a vlan in the query component, not the label?
This was not really thought-through. Pick your answer: - to allow for PortGroups with multiple labels (e.g. create a PortGroup with all VLANs in multiple WDM wavelength. You can now select the Port by VLAN + wavelength.) - this was a mistake, it should have been <portgroup ID>?label=<label> instead of <portgroup ID>?vlan=<label>.
# What kind of lookup systems do exist?
For URN, I'm only aware of Dynamic Delegation Discovery System (DDDS) (RFC 3402), but I haven't come accross any implementation.
Handle has a lookup service. E.g. resolve 10.5240/5868-409E-7BFB-536A-6067-E (movie record), 10.1016/j.future.2006.03.007 (publication) or 11230/f461a01a-9254-11e3-ba1c-d89d6771dd88 (scientific data) at any of the existing lookup services. E.g. hdl.handle.net or dx.doi.org.
I'm not familiar enough with ARK to know those lookup services.
# Why a URN instead of Handle system?
Because we made a mistake.
# Why not the handle system after all?
Every proposal in the NSI faces Much Discussion. I lost the energy. We're good at re-inventing the wheel. Let's continue doing that.
Hans, In the NSI extensions to NML we are specifying a relaxation of the opaque rule of GFD.202. We are not writing a new OGF URN specification to handle this. My feeling is this is okay for our solution since we are still a valid character subset of GFD.202, we just relax the GFD.202 specific opaque rule for the local part. People reading the NSI specification will get enough information to implement the solution and create the correct URNs. John On 2014-10-21, at 11:11 AM, Hans Trompert <hans.trompert@surfnet.nl> wrote:
Freek just pointed me to the minutes of last weeks call where I could read that his proposal was rejected. Interesting reasoning ... but I do miss an important implication of this decision: who is going to write the document about the new STP ID and is going to submit that to the OGF? Or are we just ignoring GFD.202 altogether?
HansT.
On 21/10/14 16:04, Hans Trompert wrote:
Hi Freek,
Nice proposal. Below a couple of quick question to check if I understand things correctly: if I have multiple topologies I can either use different TLDs to name them or different sub domains or a combination of both(?) if I use sub domains I need to register the name by adding a SOA record to one of the TLDs I own(?) the topology ID will always be a NURN without the opaque part, for example: urn:ogf:network:testbed.surfnet.nl:2014: if I use a sub domain to name my topology(?) HansT.
On 15/10/14 13:14, Freek Dijkstra wrote:
Dear members of the NSI community,
In last call, I promised you an alternative proposal for identifiers. Here it is. In addition, I've included a FAQ to explain the reasoning behind the current NURN (the urn:ogf:network identifiers).
We have to change the currently used URNs, so my proposal is as follows:
Encode the network identifier in the FQDN.
E.g. currently (No Network ID in the NURN): urn:ogf:network:surfnet.nl:1990:port:surfnet6:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1
Uppsala proposal (Network ID in the OPAQUE part): urn:ogf:network:surfnet.nl:1990:surfnet6:port:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1
change it to: urn:ogf:network:surfnet6.surfnet.nl:1990:port:production:2677 urn:ogf:network:manlan.es.net:2013:aofa:1
My apologies for Submitting Yet Another Proposal, John. It is clear that the Uppsala proposal violates the GFD.202 standard (which states that the OPAQUE part of the NURN should not be interpreted), but it took me till this weekend to come up with a counter proposal that did not contain some other drawbacks.
The advantage is that this proposal does not violate the existing NURN specification. It is actually possible to keep existing URNs the same, if so desired.
I can't think of any disadvantages compared to the proposal that was put forward in Uppsala.
That said, the two proposals still shares some disadvantages, but those are inherent to the choice on URNs for identifiers (as I said privately and publically earlier, in retrospect I think we should have chosen the Handle system instead of the URN system. That would have prevented us from re-inventing the idea of a document exchange service.)
For those interested, I wrote the FAQ below to help me rethink this problem.
FAQ
# What is a NURN?
NURN stands for "network URN". It is an identifier of the form urn:ogf:network:*. It is defined in GFD.202.
# What is the syntax of a NURN?
NURN = "urn:ogf:network:" ORGID ":" OPAQUE-PART *1QUERY *1FRAGMENT with ORGID, the ID of an assigning organisation. ORGID = FQDN ":" DATE
# What are the properties of a URN? (and thus of a NURN)?
* It is globally unique (no name collisions) * It is persistent (not re-used) * It is an identifier (without meaning)
# What is an identifier?
A label, without meaning, to uniquely identify something. It should not be confused with an address (which tells you where to find this thing) or a route (which tells you how to get there).
# Why can't an identifier have a meaning?
A resource has properties. If these properties are encoded in an identifier, the identifier is no longer persistent if these properties change. For example, the port number are properties that may change if you buy a new switch, and should in general not be part of an STP identifier. (You don't want to change STP just because you do some internal changes in the network that are irrelevant to your network peers).
# Why is the local part OPAQUE?
To prevent users from adding volatile properties to the identifier, or worse, parse the identifier to extract these properties, only to find out that the identifier object no longer holds these properties.
# How is a NURN globally unique?
To avoid global naming collisions, each entity that assigns URNs gets it's own prefix, the ORGID. Each entity (the assigning organisation) is responsible to avoid local naming collisions.
# Who assigns ORGID prefixes?
It is not assigned, it can be generated.
Usually, a naming authority is established. For example, IANA is responsible for the "urn:" namespace, and OGF is responsible for the "urn:ogf:" delegated namespace. For "urn:ogf:network:", we didn't want to devise a new formal organisation within the OGF, which at the time was already in decline. So we decided to simply re-use an existing naming authority: DNS.
# Why does ORGID contain a FQDN?
We originally thought we could use this as a topology exchange system: given a NURN, find the FQDN, do a DNS lookup for the SRV record for the appropriate service, and fetch it from the returned URL.
# Why does ORGID contain a DATE?
We quickly got feedback for the IETF URN community that a DNS name is globally unique, but not persistent. It may change over time. To compensate, we simply added a DATE: the owner of a FQDN is unique for a given moment in time. This way we avoid naming conflicts, even if a DNS zone is transferred to a different owner.
# What happened to the idea of the topology exchange using the FQDN?
It became moot with the addition of the DATE, as the FQDN would no longer have to be unique.
At the time, we thought this was good idea, as we liked the idea of an identifier with less meaning. See the question on "Why can't an identifier have a meaning" above.
In retrospect, this should have been the time to look at other identifiers schemas which contain both properties: no meaning, and yet a lookup service (e.g. ARK or Handle).
# But what's the meaning of the ORGID?
Nothing. It has no meaning (anymore). It is just a unique prefix. It could have been randomly chosen. In retrospect, perhaps we should have used the SHA-2 of FQDN + DATE.
In the above proposal, it would regain a meaning: that of the network identifier.
# Why does the NURN currently not contain a Network ID?
Because of flexibility requirements. At the time this was drafted, there was a need for subtopologies, merging of topologies, splitting of topologies, and the option of migrating STPs from one Topology to another (e.g. from the testbed to production). This is non-trivial with the current proposals (although I can think of some ways to add this functionality).
# What's the disadvantage of the no-meaning doctrine?
Well, since identifier have no meaning, any attributes and relations need to be made explicit.
# Why not a hierarchical schema?
We thought of a schema along the line of network_ID:node_ID:port_ID:link_ID, but decided against it, particular to avoid meaning in the URN. Such schema would disallow a multi-homed setup. Instead, we thought that a lookup system and explicit relation would be better.
# Without a hierarchy, how to I know if two identifers are related?
You don't. So it is fully possible in NML to create a two VLAN on a link and use two wildly different identifiers for the two VLANs. This is ugly indeed, but we though this disadvantage would be outweighed by the advantage of flexibility.
# How to group two or more VLANs?
Use a PortGroup or LinkGroup in NML.
# How to select a VLAN in a group?
Originally, this was very bad in NML. It entailled looking up the different Ports in a PortGroup, and checking the Label of each Port. This did not scale, as each identifier may be wildly different, so each network would have to publish a large Topology file.
Instead, we used a trick: the query component. Just take the URN of the PortGroup, add a query component somehow selecting a specific Port within that group (e.g. by its label), and you have the right Port.
# Is the query component part of a URN?
Yes and No. No, it is not part of the PortGroup URN. Yes, it is part of the URN that 'selects' the Port URN from the PortGroup URN + Query component. It is not part of the Port URN. E.g. urn.ogf.network:example.net:2011:portgroup:312?vlan=42 may return urn.ogf.network:example.net:2011:port:312_42
# Are query coponents allowed in a URN?
First of all, it can be argued that the query component is not formally part of the PortGroup URN,
Not yet, but we expect it will be published shortly. https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn#section-4.3
# Why is there a vlan in the query component, not the label?
This was not really thought-through. Pick your answer: - to allow for PortGroups with multiple labels (e.g. create a PortGroup with all VLANs in multiple WDM wavelength. You can now select the Port by VLAN + wavelength.) - this was a mistake, it should have been <portgroup ID>?label=<label> instead of <portgroup ID>?vlan=<label>.
# What kind of lookup systems do exist?
For URN, I'm only aware of Dynamic Delegation Discovery System (DDDS) (RFC 3402), but I haven't come accross any implementation.
Handle has a lookup service. E.g. resolve 10.5240/5868-409E-7BFB-536A-6067-E (movie record), 10.1016/j.future.2006.03.007 (publication) or 11230/f461a01a-9254-11e3-ba1c-d89d6771dd88 (scientific data) at any of the existing lookup services. E.g. hdl.handle.net or dx.doi.org.
I'm not familiar enough with ARK to know those lookup services.
# Why a URN instead of Handle system?
Because we made a mistake.
# Why not the handle system after all?
Every proposal in the NSI faces Much Discussion. I lost the energy. We're good at re-inventing the wheel. Let's continue doing that.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On 21-10-2014 17:32, John MacAuley wrote:
In the NSI extensions to NML we are specifying a relaxation of the opaque rule of GFD.202. We are not writing a new OGF URN specification to handle this. My feeling is this is okay for our solution since we are still a valid character subset of GFD.202, we just relax the GFD.202 specific opaque rule for the local part. People reading the NSI specification will get enough information to implement the solution and create the correct URNs.
I think Hans is referring to the problem what a NSI client should do if it encounters a perfectly valid NURN, which is not a valid NSI URN. E.g. right now, SURFnet has a STP called "urn:ogf:network:surfnet.nl:1990:port:surfnet6:production:5614". This is an isAlias of "urn:ogf:network:surfsara.nl:2013:port:surfnet-lp-eyr3-lsg", which is published by SURFsara. What is the correct behaviour of the SURFnet NSA if it receives this NURN "urn:ogf:network:surfsara.nl:2013:port:surfnet-lp-eyr3-lsg"? This broken backward compatibility can either be handled by writing a new URN spec, or by clearly defining the behaviour in these cases in one of the NSI specs. Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Wed | Thu |
If an NSA receives the STP "urn:ogf:network:surfsara.nl:2013:port:surfnet-lp-eyr3-lsg" it would follow the new rules and determine that the network identifier for this STP is "urn:ogf:network:surfsara.nl:2013:port". The NSA would look up the network and find that one does not exist, rejecting the reservation request with either an invalid network or invalid STP error. We do not need to worry about backwards compatibility in this case as we will be doing a cut over on the network to the new identifiers. John On 2014-10-21, at 11:50 AM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
urn:ogf:network:surfsara.nl:2013:port:surfnet-lp-eyr3-lsg
participants (4)
-
Freek Dijkstra -
Hans Trompert -
John MacAuley -
John MacAuley