NORDUnet topology changes
Would love to see this as a formal contribution instead of seeing it in slides, but I know how busy everyone is implementing. I will reserve a full out rant for a later point in time ;-) These points on topology were part of a presentation by Lars Fisher today at Caltech. I can see why the discussion today was not constructive. Can we assume a formal contribution from the r107 consortium at some point? I really would like to avoid putting any more effort into this myself if any decisions are going to be ignored. Changes to the NSI-NML extension • Restrict topology ids and port ids, such that topology ids are always a prefix of the port name • Add topology reachability and cost elements. • (NSA peering entry becomes redundant and can be removed) Further suggestions • Limit prefix matching to one level. • Restrict URI naming • Remove the year/date constraint in ORGID for URNs. Still a few outstanding issues John
While it seems that there is consensus on the NML structure, there is a lot of discussion about the identifiers used by NML. 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. So I'm going to take a step back and suggest a couple of alternatives how to proceed. 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 This is very flexible, but does not scale. 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. 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). 2. Move towards a hierarchical naming scheme, where the first part of each STP identifier is the Network identifier. 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 (coming from an organisation that has just split its network, I can assure you this is a big issue) 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. 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. When we started working on NML, we feared the rigidness of solution 2, and made sure to make it more flexible. I thought that a lookup service could easily be implemented, and would naturally emerge when it was needed. So far, there was no dire need, and problems where encountered we picked a work-around, the tuple-as-an-identifier. 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. 2. Always accompany a STP identifier with a Topology identifier, in whatever format (tuple, concatenated string, ...) 3. Abandon the current naming scheme and move towards a completely new, but hierarchical based naming scheme, loosing flexibility. 4. Implement a URN-based lookup service 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 ;) ). Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |
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
Hi Henrik,
Compatible was not a goal here.
You get bonus points for sending this statement to a standardization mailing list. It should not come to a surprise that I vehemently disagree.
Having a topology model we thought could work was the issue at hand. Nothing else.
I fully agree that's even more important, but I don't think the two rule each other out. I don't think any more statements I'll make about the above will lead to a fruitful discussion, so I leave it at that. It's arguably more constructive to focus on the problems, and solution. Either I disagree with a few of your statements, or I simply don't understand them. Let's hope it's the later. :) If you have some time, I certainly appreciate it if you can explain your criticism a bit more. What works best for you? Email, phone call, or in person at OGF 40?
[...] 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
Yes. Is that good or bad according to you? I don't see what this has to do with the identifiers used by NML.
* No abstraction mechanism for topology
Most certainly there are! Topologies are in fact abstractions of a network (they give a function description of a network, and it's services). It allows description of hierachical topologies, each subtopology containing less abstraction and more detail (section 5.3.2 of NML base). This is unlike the Node concept in NML which is used to describe devices and the non-abstracted topology. I have the idea I use the word 'abstraction' in a different way than you do. What do you mean with 'abstraction mechanism'?
* Ignore security (arguably this is insanely difficult)
Agree. I think a lookup service could actually solve of the security issues, but even then it is very difficult.
* Ignore usuability (everything with topology went smooth in the autogole demos, right?)
Sorry, I do not understand.
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).
What are more serious problems in your opinion? I leave my remarks about the remainder of your email for another time. For now, I like to understand the above. Regards, Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |
On Fri, 6 Dec 2013, Freek Dijkstra wrote:
Compatible was not a goal here.
You get bonus points for sending this statement to a standardization mailing list.
John asked if he could see it. I send it.
It should not come to a surprise that I vehemently disagree.
Sorry to sound like an ass, but having you like it was not the goal either.
Having a topology model we thought could work was the issue at hand. Nothing else.
I fully agree that's even more important, but I don't think the two rule each other out.
Certainly not. But now is better than never. And for NORDUnet those were pretty much the options. We could not wait anymore for the NSI/NML process to finish. I'd like to think that I have been trying to raise awareness about this in the NSI group. People won't sit on their hands and smile while they wait for the NSI spec to come out.
It's arguably more constructive to focus on the problems, and solution. Either I disagree with a few of your statements, or I simply don't understand them. Let's hope it's the later. :)
If you have some time, I certainly appreciate it if you can explain your criticism a bit more. What works best for you? Email, phone call, or in person at OGF 40?
VC or phone call is good (I broke my collarbone a few weeks ago, and I'm stil on partial sick leave, and have limited keyboard time a day). I suspect that I will also be OGF40.
Actually there are some deeper assumptions hidden here:
* The model is relational
Yes. Is that good or bad according to you?
So a relational model is not inherently good or bad. However, in this case, it has made very difficult (I'd argue impossible) to create any sensible abstraction mechanism in NML. I.e., a case where an NSA doesn't have to know the full topology model including ports of a system in order to make a path-finding decision. That is what I mean with an abstraction mechanism.
From a distributed systems point-of-view, I dislike the idea of keeping a large chunk of distributed state kept up-to-date across the system. Not because it cannot scale/perform, but because it is brittle way of building a system.
I don't see what this has to do with the identifiers used by NML.
The identifiers is just how the problem manifests itself. It is the model of non-scoping ports within a topology that becomes problematic.
* No abstraction mechanism for topology
Most certainly there are! Topologies are in fact abstractions of a network (they give a function description of a network, and it's services). It allows description of hierachical topologies, each subtopology containing less abstraction and more detail (section 5.3.2 of NML base). This is unlike the Node concept in NML which is used to describe devices and the non-abstracted topology.
I have the idea I use the word 'abstraction' in a different way than you do. What do you mean with 'abstraction mechanism'?
See above. A mechanism that allows an NSA to make path-finding decisions without knowing the entire system topology.
* Ignore security (arguably this is insanely difficult)
Agree. I think a lookup service could actually solve of the security issues, but even then it is very difficult.
Again, a lookup service doesn't solve the problem (however it works). It just encapsulates the problem (which can be a perfectly dandy thing to do).
* Ignore usuability (everything with topology went smooth in the autogole demos, right?)
Sorry, I do not understand.
I have four other users of OpenNSA. Getting them to understand the NSI and NML model is quite tricky. The fact the a port in their system is not scoped to their system is actually a very weird concept to get across. However this manifest itselfs mostly when specifying endpoints, where you have to know something like this: urn:ogf:network:aruba.net:2013:topology urn:ogf:network:aruba.net:2013:ps http://schemas.ogf.org/nml/2012/10/ethernet#vlan 1780 And that is just one endpoint. Arguably NSI is also at fault here. Explaining the URNs, years, the non-scoped identifiers, namespaces, etc. is a lot for someone that has not been following the NSI and NML tracks. I can boil it down to this in the onsa tool: aruba.net:2013:ps#1781 But it only works when topology id and port id follow a certain form. Otherwise they have to specify both.
Scaling is the least of its problems (but scaling is a problem people like to think about).
What are more serious problems in your opinion?
We may have different ideas about scaling. For me it is how a certain performance charistica of a systems changes as you add more resources to it. This is a classical distributed systems definition, but it tends to be a bit more narrow than most peoples. It is not that I don't think the system cannot service a high number of requests in resonably large setting, but that it gets brittle, less flexible, and provides a bad user experience. Consider the following use case: You use some API to spawn a VM at some cloud provider. In the information you get back (hostname, ip, etc), there is also an STP or port id. You then make a request to your local NSA to seutp a circuit from a local machine/switch to the newly spawned VM. However since the port id, is brand new it has no idea at which NSA it terminates. It has the following options: 1. Reject the request as it doesn't know the port. 2. Go out and fetch all topologies to discover if the port is in any of the topologies, before it decides to try and setup the circuit or reject the request. It is not that I dont' think the second scenario cannot scale. Computers and networks are pretty fast. I just think this is a bad idea way to build a system. When locking the port and topology ids to match, it becomes possible to start the circuit setup immidieately as the NSA knows how to get to the topology id. This is somewhat similar to IP prefix matching. When I setup a new machine, i give it an IP from a range for the LAN and it juts works. I don't need to go out and update anything on a router, because it knows where to route the request too. Of course routing information changes frequently, but one doesn't build routing tables per-ip. OK, that became longer than intended. Hope it makes sense. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi all, What I have trouble understanding is why you have chosen to change a working standardized system. As far as I know we have had two successful demonstrations at GLIF and SC this year, including distributed topology resources. The only thing missing still is a lookup service, and/or distribution service. I have not seen any compelling arguments why you would fly completely into the face of a working system. I may have missed something, but I have also not seen any constructive discussion either in NSI or in NML on how to fix the NML-NSI topology definition so that we can meet the requirements you defined. Jeroen.
Hi Jeroen The reason for changing the topology was a result of how we wanted the overall system to work, and then having the topology support that. Taking a step back, NSI is an extremely generic, policy-free protocol, that comes with little instructions for how things should work, i.e., how are requests broken up. It is essentially free-form wrt. control plane and data plane, tree or chain, breakup, no standard policy for what is allowed and not. This makes developing an NSA more complicated and makes a system significantly more complicated to reason about and debug. What we did was to restrict the behavior of the NSI agent in several ways, and specify a specific way the request breakout should work. This ties strongly into what we think is a reasonable service to provide to our customers and peers, along with what we are capable of operating. Unfortunately, these decisions are extremely difficult, if not impossible, to take in the NSI group. The changes we made to the topology was a result of how we wanted the overall system to work. We did not change topology, just because we didn't like it. /Henrik On Sat, 7 Dec 2013, Jeroen van der Ham wrote:
What I have trouble understanding is why you have chosen to change a working standardized system. As far as I know we have had two successful demonstrations at GLIF and SC this year, including distributed topology resources.
The only thing missing still is a lookup service, and/or distribution service.
I have not seen any compelling arguments why you would fly completely into the face of a working system.
I may have missed something, but I have also not seen any constructive discussion either in NSI or in NML on how to fix the NML-NSI topology definition so that we can meet the requirements you defined.
Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 10 Dec 2013, at 11:33, Henrik Thostrup Jensen <htj@nordu.net> wrote:
What we did was to restrict the behavior of the NSI agent in several ways, and specify a specific way the request breakout should work. This ties strongly into what we think is a reasonable service to provide to our customers and peers, along with what we are capable of operating. Unfortunately, these decisions are extremely difficult, if not impossible, to take in the NSI group. The changes we made to the topology was a result of how we wanted the overall system to work. We did not change topology, just because we didn't like it.
Given the speed of the decision making process in the NSI group, and having it in a “ready in 3 months” state for about 18 months already, I can understand that. A problem however is with the way you plan to use the urn:ogf:network identifiers. The use of these identifiers has been defined and standardised, according to the IETF and IANA guidelines. The reason for these restrictions and standardisation are to have persistent, globally unique identifiers, without having to have a central registry of our own. Changing these identifiers to leave out certain parts because this is more convenient is simply not an option, as it breaks current and future compatibility. You will have to use a different namespace or identification scheme for this. Jeroen.
On Tue, 10 Dec 2013, Jeroen van der Ham wrote:
A problem however is with the way you plan to use the urn:ogf:network identifiers. The use of these identifiers has been defined and standardised, according to the IETF and IANA guidelines. The reason for these restrictions and standardisation are to have persistent, globally unique identifiers, without having to have a central registry of our own.
AFAICT the way we generate the URNs is perfectly valid. If not, please be specific. In fact, the topology that we will generate should be consumable by any "normal" NML consumer.
Changing these identifiers to leave out certain parts because this is more convenient is simply not an option, as it breaks current and future compatibility. You will have to use a different namespace or identification scheme for this.
Is this just referring to the date part or something else? I still have problems wrapping my head around the rationale for these URNs: We put severe restrictions on how to generate them, but they are in no way enforcable. We put a lot of information into the URNs when generating them, but you are not allowed to interpret them. Seriously? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 11 Dec 2013, at 11:33, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Tue, 10 Dec 2013, Jeroen van der Ham wrote:
A problem however is with the way you plan to use the urn:ogf:network identifiers. The use of these identifiers has been defined and standardised, according to the IETF and IANA guidelines. The reason for these restrictions and standardisation are to have persistent, globally unique identifiers, without having to have a central registry of our own.
AFAICT the way we generate the URNs is perfectly valid. If not, please be specific. In fact, the topology that we will generate should be consumable by any "normal" NML consumer.
Changing these identifiers to leave out certain parts because this is more convenient is simply not an option, as it breaks current and future compatibility. You will have to use a different namespace or identification scheme for this.
Is this just referring to the date part or something else?
Yes, quoting GFD:
NURN = "urn:ogf:network:" ORGID ":" OPAQUE-PART *1QUERY *1FRAGMENT ORGID = FQDN ":" DATE ; ID of assigning organisation DATE = YEAR *1(MONTH *1DAY) ; Date of creation of ORGID
I still have problems wrapping my head around the rationale for these URNs: We put severe restrictions on how to generate them, but they are in no way enforcable. We put a lot of information into the URNs when generating them, but you are not allowed to interpret them. Seriously?
The restrictions have been put in place to make a way of generating them such that they are globally unique without needing an (extra) central registry. I follow the philosophy of the Semantic Web where identifiers are just that, identifiers. They do not have any intrinsic semantic value. Any semantic value on identifiers should be defined explicitly. Again, this provides an extremely flexible model, where for example you dodge the big problem like the locator / identifier split we have in IP networks (meaning sessions break as you move). This has an adoption cost, but allows for much greater flexibility in the long run. John has dug up references of use of URNs where it is allowed to analyze the structure of the identifiers and to interpret that. So it seems that I was mistaken. Jeroen.
Henrik, As for the adding hierarchy to URNs, I suggest we discuss this at OGF 40. I think it is a bad idea to add a network hierarchy to an identifier, but do not necessarily object to all sorts of hierarchies. In fact, the URN:OGF:NETWORK specification already requires that the first part of a URN starts with an identifier of the assigning organization (which is somewhat akin to the NSA, but not necessarily the same as the Topology). As for dropping the date part in the URN, please read GFD 202, section 5. http://www.ogf.org/documents/GFD.202.pdf The date is there for a reason: ensuring persistent uniqueness, without creating a registry. Adding 5 bytes seems like a cheap cost compared to any alternatives. On 11-12-2013 13:56, Jeroen van der Ham wrote:
John has dug up references of use of URNs where it is allowed to analyze the structure of the identifiers and to interpret that.
It's allowed by URN specs, but quite strongly discouraged by the URN community. Subdelegations of the URN specs may add further restrictions (such as the requirement that an identifier is context-free, and may only be interpreted by the assigning organisation), and that is what GFD 202 did. The eye-opener for me was the following email: http://www.ietf.org/mail-archive/web/urn/current/msg01564.html I'll quote verbatim:
if you allow people to assign URNs as they prefer, they always tend to "invent" some semantic rules.
At the end you have your database full of Identifiers like:
[institution-name]-[division-name]-[collection-name]-[date]-[item-number]
This goes fine many years.
Till the day the collections are renamed or two divisions fusion under another name or renaming of the institution or ...
Experiences like those are the reason why many colleagues with Long Term Archiving background propagate Identifiers without semantics --meaningless strings just for machines.
I was Brainwashed too, and I now also propagate identifiers without semantics. :) Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |
Hi Freek On Wed, 11 Dec 2013, Freek Dijkstra wrote:
As for the adding hierarchy to URNs, I suggest we discuss this at OGF 40. I think it is a bad idea to add a network hierarchy to an identifier, but do not necessarily object to all sorts of hierarchies. In fact, the URN:OGF:NETWORK specification already requires that the first part of a URN starts with an identifier of the assigning organization (which is somewhat akin to the NSA, but not necessarily the same as the Topology).
The reason we made identifiers hierarchial is because we wanted a hierarchial model, including the identifiers. 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" Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
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. 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 are saying "we made identifiers hierarchical", which identifiers do you mean? Do you plan to create a new document describing a different type of identifiers, possibly using a different prefix?
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.) 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. I may not be convinced, but at least that approach would not lead to incompatible software. Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |
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
Hi, On 18 Dec 2013, at 14:04, Henrik Thostrup Jensen <htj@nordu.net> wrote:
The way we generate the identifiers is perfectly valid NML. The "problem" arise when we interpret them :-).
NML != ‘urn:ogf:network' identifiers. There are two different documents describing them, and they are from the same authors, but they have very different goals, and different restrictions. You can do NML with any URI as identifiers. They do not specifically have to be urn:ogf:network identifiers.
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.
We defined the “urn:ogf:network” namespace to follow guidelines that were set by IANA and IETF. We did not just pull these out of our sleeves to come up with some restrictions to be particularly annoying to programmers. If you look at other urn namespaces I think you will find similar kinds of restrictions. If you do not agree with those restrictions, then don’t use that namespace. If you do use that namespace, and don’t follow the restrictions, then don’t be surprised if at some point implementations will throw validation errors back at you. Jeroen.
On Wed, 4 Dec 2013, John MacAuley wrote:
Would love to see this as a formal contribution instead of seeing it in slides,
Here you go.
Can we assume a formal contribution from the r107 consortium at some point? I really would like to avoid putting any more effort into this myself if any decisions are going to be ignored.
As I said yesterday, this is a solution that we came up with to get the service off the ground. When (if) NSI2 comes out and if it has a topology model we think is usable, we can switch to that. We are not tied into this model forever. Do you remember the meeting in Oxford. At that point we were pretty sure that the the NSI2 spec was 1-3 months away. It has been like that since, and that is 1½ year ago. NSI is essentially evolved into a multi-domain R&D project (which is not an efficient thing) these days. From a NORDUnet perspective the overall idea was that we had gone long enough without developing this into something our users could use. It was either this, or pulling out from the project. There are an awful lot of emails right now that need answering, but I have to prepare for another meeting later today, but I will try and answer them tomorrow. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 05/12/13 10:30, Henrik Thostrup Jensen wrote:
On Wed, 4 Dec 2013, John MacAuley wrote:
Would love to see this as a formal contribution instead of seeing it in slides,
Next week I will send a short document as well that describes the authentication/authorization model we intend to implement. HansT.
Here you go.
Can we assume a formal contribution from the r107 consortium at some point? I really would like to avoid putting any more effort into this myself if any decisions are going to be ignored.
As I said yesterday, this is a solution that we came up with to get the service off the ground. When (if) NSI2 comes out and if it has a topology model we think is usable, we can switch to that. We are not tied into this model forever.
Do you remember the meeting in Oxford. At that point we were pretty sure that the the NSI2 spec was 1-3 months away. It has been like that since, and that is 1½ year ago. NSI is essentially evolved into a multi-domain R&D project (which is not an efficient thing) these days. From a NORDUnet perspective the overall idea was that we had gone long enough without developing this into something our users could use. It was either this, or pulling out from the project.
There are an awful lot of emails right now that need answering, but I have to prepare for another meeting later today, but I will try and answer them tomorrow.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Thanks Henrik. I have some comments below.
* Peering
Path finding must - for obvious reasons - go along the data plane. Trust goes along the control plane - again for obvious reasons. The model presented here, asserts that data and control plane peering goes hand in hand. While two networks, that are not adjacent could trust each other, there is no need for it in the model presented. The model does not expose peerings through topology, but instead advertises reachability of topology. The core idea being that reachability of ports and topology is what matters, and not specific control plane peelings.
There was a long conversation on this where I presented many options and specifically asked for the requirement that the control plane connectivity minimally follows the data plane to simplify signalling. The answer agreed upon in the meeting was NO, we cannot assume the control plane connectivity follows the data plane. This was the reason for the control plane topology "peersWith" relationship, without which, you cannot determine the correct path for delivery of NSI CS message. This effectively decouples the signalling plane from the data plane. Good or bad this was the agreement.
* Ports & Aggregation
Prefix matching is limited to one level.
Can you expand on what this specifically means? From the examples are you suggesting something like: urn:ogf:network:<provider id>:<network Id>:<local Id> Allowing an NSA to manage a Provider (I avoided using Domain Name for clarity) with multiple Networks, and enumerated local identifiers.
Reachability & Cost * Path Finding Example
From reading these two sections it looks like you are proposing a summary routes mechanism with related domain level costs then implementing a chain model for signalling. True? Thank you for the e-mail, John
On Thu, 5 Dec 2013, John MacAuley wrote:
There was a long conversation on this where I presented many options and specifically asked for the requirement that the control plane connectivity minimally follows the data plane to simplify signalling. The answer agreed upon in the meeting was NO, we cannot assume the control plane connectivity follows the data plane. This was the reason for the control plane topology "peersWith" relationship, without which, you cannot determine the correct path for delivery of NSI CS message. This effectively decouples the signalling plane from the data plane. Good or bad this was the agreement.
Yeah. Unfortunately this is/was very much a vacuum decision. When one start to mix in thrust/security and how things actually have work, it gets very odd to not have control and data plane go hand in hand IMHO. We have been very cautius about making firm decisions on how the system should act as a whole, and have been making a lot of low-level decisions instead, but this makes it very difficult to see how the system should actually work.
Prefix matching is limited to one level.
Can you expand on what this specifically means?
Basically when advertising the topology ids, you are not allowed to have stuff like this: nordu.net:topology: nordu.net:topology:whatever But this can also be inferred from the port id -> topology id inferring rule.
Allowing an NSA to manage a Provider (I avoided using Domain Name for clarity) with multiple Networks, and enumerated local identifiers.
Not sure if this is related to the previous question or not.
From reading these two sections it looks like you are proposing a summary routes mechanism with related domain level costs then implementing a chain model for signalling. True?
Sounds right. Not sure what you mean with "summary routes mechanism with related domain level costs". I like to think that the scheme is somewhat similar to OSPF. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (6)
-
Freek Dijkstra -
Hans Trompert -
Henrik Thostrup Jensen -
Jeroen van der Ham -
John MacAuley -
John MacAuley