[Nsi-wg] NURN proposal

Tue Oct 21 10:04:10 EDT 2014

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.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20141021/907bd760/attachment.html>