[Nml-wg] NML Topology identifiers

[Freek Dijkstra]

While it seems that there is consensus on the NML structure, there is a
lot of discussion about the identifiers used by NML.

Today, John suggested a few changes in the NORDUnet implementation on
the NSI list, including:

> • Restrict topology ids and port ids, such that topology ids are
>   always a prefix of the port name

This is a pretty radical change. While I understand where this is coming
from, I do fear implementation incompatibilities if you are moving away
from base assumptions.

So I'm going to take a step back and suggest a couple of alternatives
how to proceed.


First of all, let me acknowledge that the identification of STP in NSI
is not ideal. The NML starting points are:
* all identifiers are opaque
* all relations need to made explicit
This is very flexible, but does not scale. Henrik pointed out that the
isAlias currently only points to a STP identifier, and the only way to
derive the Topology (and NSA) identifier from that is to have a full
list of STP identifiers - Topology identifiers.

As far as I know there are three solutions to this problem.

1. Always accompany a STP identifier with a Topology identifier. This is
the solution that is currently applied using tuples (or as John calls
it, STP identifier structures). Concatenating the Topology and STP
identifier into a single string is just a variant of this solution (the
only difference is the syntax).

2. Move towards a hierarchical naming scheme, where the first part of
each STP identifier is the Network identifier. This is a common solution
in most naming schemes. Unfortunately it breaks two features of NML:
* all identifiers are opaque
* the relationship between STP and Topology becomes rigid; it is no
longer possible to describe subtopologies, or network splits or network
mergers for that matter (coming from an organisation that has just split
its network, I can assure you this is a big issue)
A further risk is that this often leads to the introduction of new
attributes in the identifiers, which further makes more rigid relations,
and is a problem is these attributes change.

3. Define a lookup service to get attributes for identifiers. This is
actually a fairly common feature for most naming schemes: DNS and the
Handle system deploy it at large scale. For example, looking up the
identifier "10.5240/5868-409E-7BFB-536A-6067-E" at hdl.handle.net first
points to the lookup service at dx.doi.org (DOI has registered the '10',
well know for journal identifiers), which in turn leads to
resolve.eidr.org, who owns the '10.5240' subregistry, and you'll find
that it is an Entertainment Industry identifier identifying a particular
Star Wars movie. Now, for URNs a registry system was defined as well
(RFC3401-RFC3405 if I'm not mistaken), but never seem to be widely used.


When we started working on NML, we feared the rigidness of solution 2,
and made sure to make it more flexible. I thought that a lookup service
could easily be implemented, and would naturally emerge when it was
needed. So far, there was no dire need, and problems where encountered
we picked a work-around, the tuple-as-an-identifier.


Given the lengthy discussion, it became clear to me that this may not be
the best solution out there. So I'm going to ask the NML and NSI
community: how should we proceed forward?

1. Just close our eyes, build big lookup tables, and pretend there is no
scalability problem.
2. Always accompany a STP identifier with a Topology identifier, in
whatever format (tuple, concatenated string, ...)
3. Abandon the current naming scheme and move towards a completely new,
but hierarchical based naming scheme, loosing flexibility.
4. Implement a URN-based lookup service
5. Replace the URN-naming scheme with a similar opaque naming scheme
that already has a solid attribute lookup service in place, like the
handle system (or use the DNS system, if you fancy that sort of
technology abuse ;) ).


Freek

-- 
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 | Thu | Fri |