[Nsi-wg] NURN proposal

Tue Oct 21 11:11:27 EDT 2014

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

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