[Nsi-wg] NURN proposal

Wed Oct 15 07:14:52 EDT 2014

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 at surfsara.nl | www.surfsara.nl |

Available on Mon | Tue | Wed | Thu |