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

[Henrik Thostrup Jensen]

On Thu, 12 Dec 2013, Freek Dijkstra wrote:

> On 12-12-2013 12:53, Henrik Thostrup Jensen wrote:
>
>> The reason we made identifiers hierarchial is because we wanted a
>> hierarchial model, including the identifiers.
>
> NML allows a hierarchy (using relations), even though it's identifers
> are non-hierarchical.

Yes, but you have to know about them, i.e., you have to acquire the 
information from somewhere. Currently that means going out and crawling 
all the topologies from different domains and building a big model.

What we are looking for is the ability to make path finding decisions 
without having to acquire a bunch of information repeatedly.

Furthermore NML has no way of exposing economical/political policies of 
network (which are very real), like preferring one link over another. Our 
cost attribute is an attempt of this. It may be overly simplistic, but it 
is a start.

> FYI, an earlier attempt was to also make the identifiers hierarchical as
> "domain -> node -> port -> link" (See section 8.2 of GFD 202). However
> there were some use cases where this didn't apply. For example, NSI
> deviated from this hierarchy, only using "domain -> port", and
> requesting a "domain -> subdomain" hierarchy. For that reason, NML
> clearly chose non-hierarchical identitifiers, and specified that in GFD 202.

If you insist on a static hierarchical model there will always be things 
that doesn't fit into it (but thats okay). CIDR manages a to make a 
hierarchical model, without being to strict in the levels, so making 
hierarchical model without strict levels is certainly possible. I know the 
idea of arbitrary level of domains has been raised in the NSI group 
(though I am not sure I agree with it).

I understand the lure of the extreme flexibility that the relational model 
gives, but this also makes the model extremely difficult to abstract.

> If you are saying "we made identifiers hierarchical", which identifiers
> do you mean?

The id=... attributes in the NML elements.

> Do you plan to create a new document describing a different
> type of identifiers

Not anything more than what have already been send.

> possibly using a different prefix?

No.

>> I don't care about URNs. They add exactly zero value to the system. I
>> have yet to see a good argument for why
>> "urn:ogf:network:nordu.net:2013:ps?vlan=1701" is better than
>> "nordu.net:ps?vlan=1701"
>
> Prefixes are used to ensure globally uniqueness (and thus prevention of
> identifier collisions). It is debatable if that is a real concern or
> not. (My personal opinion is not to show the urn:ogf:network" to users
> in a GUI, but keep it in the protocol, the few bytes of overhead are not
> worth a discussion.)

I don't present the URNs to the OpenNSA users. But this mapping adds 
complexity in the implementation. More than you think. Furthermore when 
something goes wrong the duality of the identifiers confuses users and 
makes bugs in the implementation more likely. Of course, things should not 
go wrong, but something always does.

The prevention of collisions usually happens when someone takes 
identifiers from one system and crams them into another without thinking. 
A reasonably reaction to this is to slap them over the hands, while saying 
no in a strong voice. Anti-collision schemes are at best an academic 
exercise, and adds more layers and standards to the world.

I'm the guy that has to implement things. And I'm sick of people being 
clever and inventing things left and right. It does not produce software 
that is more useful.

> A secondary use is that it allows easier detection of the type of
> identifiers. For example, imagine some like yourself decides that the
> current urn:ogf:network identifier syntax is not good. For example cuse
> you like to add more hierarchy to it. In that case, it is easy to define
> a new prefix (e.g. "urn:ogf:whatever:") and define a better syntax for
> those identifiers, and convince the community to start using those
> identifiers.

The way we generate the identifiers is perfectly valid NML. The "problem" 
arise when we interpret them :-).

Quite frankly, the alternative would be to use something that isn't NML. 
However our goal was to get something we believed was useful with as few 
changes as possible.

If we are going to continue this discussion could we please tone down the 
"We are the knights of the URNs, and you have violated our sacred laws", 
and more about why we think NML isn't useful as a distributed topology 
model.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet