[Nml-wg] [Nsi-wg] NML Topology identifiers

[Henrik Thostrup Jensen]

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