[Nml-wg] [Nsi-wg] NML Topology identifiers
Henrik Thostrup Jensen
htj at nordu.net
Wed Dec 18 08:04:26 EST 2013
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
More information about the nml-wg
mailing list