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

[Henrik Thostrup Jensen]

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