[Nml-wg] About modelisation of the network description

[Evangelos Chaniotakis]

On Mar 27, 2008, at 11:25 AM, Aaron Brown wrote:

> Things had gotten a bit quiet so I figure I should open up a can of
> worms :-) .
>
> Freek Dijkstra wrote:
>> In short: name MUST NOT be context-sensitive. I think it is bad if I
>> can only describe an interface as "eth0 of host3 in network 8". I  
>> much
>> rather say interface "intf639" and only if required tell that it is  
>> in
>> "host3" and that "host3" is in "network8".
>>
>> Of course, this requires that names are globally unique. I prefer to
>> use opaque names (any string, without syntax requirements), as long  
>> as
>> it is unique. URIs come to mind.
>
> If we mandate that *all* naming is completely context independent,  
> then
> when given a random identifier, users are completely at a loss  
> (since no
> context implies no domain information) as to where to get  
> information on
> an element. If the only context it has is "this domain contains  
> [uuid]",
> our schema can work like that except it adds a bit of extra  
> information
> on it so you can type-check a given id. For example, if you didn't  
> want
> any hierarchy below domain, you could just label everything like:
>
> urn:ogf:network:domain=Internet2.edu:node=node1345
> urn:ogf:network:domain=Internet2.edu:port=intf639
> urn:ogf:network:domain=Internet2.edu:link=link23
>

My take on this is that all elements should have a meaningless, globally
unique identifier with no hierarchical information in it at all. We do  
need
human readable information but that can be pushed to other attributes
or be inferred by relationships.

An example interface:

id = "1311477AD25"
"interfaceName" => "TenGigabitEthernet1/1"

How do we know which specific device it belongs to? Well, the device  
is a
group so it'd look like:

id = "98821CA88"
"hostname" => "chic-sdn1.es.net"
interfaces:
	1311477AD25
	....

And the domain is a group too, like:
id = "12198DAC"
"name" => "ESnet"
devices:
	98821CA88
	....


Etc, etc. If our application needs to find out the  
"domain:device:interface" URN
format for that interface, it can easily do that if it has the  
information above - and it
can also easily resolve to the global identifier if it is given a urn- 
style "identifier".

Advantage: if you are looking at just the Interface object you'll only  
be able to
find stuff in the scope of the object itself, you won't get the  
network hierarchy
or anything like that. This would help us have a nice and clean design  
with
well-defined boundaries between objects.

And, as a bonus,  it'll make it easier to anonymize topology data; we  
can
just push out ids and relationships rather than hierarchical names, and
the mapping to the internal stuff would be trivial if we kept the same
object ids.

Disadvantage: It'll be a bit more cumbersome to look things up - users  
won't
be able to just look at an id and immediately know stuff about it. But  
well, we'll
have identifier lookup services and tools for that.