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