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