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@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |