Hi Freek Thank you for actually understanding the issues here. Replies inline. On Wed, 4 Dec 2013, Freek Dijkstra wrote:
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.
Compatible was not a goal here. Having a topology model we thought could work was the issue at hand. Nothing else. However, the topology model we came up with should actually be parsable by something that can parse the standard NSI topology. However the id naming restriction makes it impossible go the other way.
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
Actually there are some deeper assumptions hidden here: * The model is relational * No abstraction mechanism for topology * Ignore security (arguably this is insanely difficult) * Ignore usuability (everything with topology went smooth in the autogole demos, right?)
This is very flexible, but does not scale.
Scaling is the least of its problems (but scaling is a problem people like to think about).
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.
Port IDs, not STP (STPs only exist in the NSI CS protocol).
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).
This doesn't solve the problem. You still have to go out and read all the topologies to figure out how everything is interconnected. There are still issues with dynamical issues, i.e., if a new port gets generated remotely, an NSA cannot serve a user request with this port id, as it doesn't know where the port is. Essentially you cannot turn down a request until you updated your entire topology.
2. Move towards a hierarchical naming scheme, where the first part of each STP identifier is the Network identifier.
Having a hierarchical scheme is also the first step towards supporting some form of topology abstraction.
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
You have to choose your poison here. Having freeform relations between ports and topologies, and no topology abstraction. Or have topology abstraction and throw away freeform relation between ports and topologies. If you look at IP, topology abstraction is clearly the favored here. IPv6 has support for roaming IPs, but it does that by forwarding packets to that IP to another IP. Not by creating routing tables with single IPs that have to be constantly updated. If you look at HTTP, it has a this supported by having a request respond with a 3XX code, and point to another resource. This would not be difficult to add to NSI (it should also solve organisation network split example below). You can solve the issue of roaming in other layers/system than NML. I would also argue that the two solutions above are significantly more sane security wise.
(coming from an organisation that has just split its network, I can assure you this is a big issue)
Was there any NML ids in use there? There is always the option of creating new identifiers.
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.
You can say that about everything.
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.
Probably for a good reason. The lookup service still doesn't solve the problem. It just encapsulates it. You still have to solve it.
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.
I don't think the big lookup tables are a huge problem. Instead I think the concept that an NSA has to have global knowledge and update it regularly in order to do a path finding decicision is the problem. It is simply a bad way to build a distributed system.
2. Always accompany a STP identifier with a Topology identifier, in whatever format (tuple, concatenated string, ...)
Still doesn't solve the problem. You still have to build your global model.
3. Abandon the current naming scheme and move towards a completely new, but hierarchical based naming scheme, loosing flexibility.
That was decision we ended up with. I can convince myself that it can work. Having some form of hierarchy is more or less needed if we want to create some form of abstraction.
4. Implement a URN-based lookup service
Please specify how it should work, instead of just saying that it will solve the problem.
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 ;) ).
DNS can actually do awful lot of cool stuff. However the practical issues of updating DNS for each port, etc. will never fly. We also have to remember that while many things base itself on DNS, networks do not. This is also why security is so painful to do with topology, it does not adhere to the structure of DNS (which X509 certificates is based on). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet