[Nsi-wg] Fwd: Describing Topologies

[Jeroen van der Ham]

Hello,


On 26/07/2011 06:19, Jerry Sobieski wrote:
> Hi Radek-
>
> As nice as I think the SNE graphical UI is, the topology it asserts
> does not correspond well to the NSI topology, nor does it separate
> that which is inter-domain and technology agnostic from that which
> is intra-domain and almost entirely a local NRM issue (i.e.
> implementation specific). The SNE model is imposing unnecessary
> requirements on the NSI demo. We are well outside of what the spec
> requires. This is why I recommended a very simple and direct NSI
> topology description for the Rio demos (and *only* for the demos -
> not permanently) that allowed each implementation to define their
> local NRM information independently. IMO, we do not want to impose
> more on the NSI interop demonstrations than has been vetted by the
> NSI group.

No, it is not imposing anything on the NSI demo. If we simply want to do
a repeat of last year then that's fine with me. If we want to move
ahead, we have to start exchanging topologies, and add more information
to those topologies.

> I think within the SNE topology model, an NSI Network maps best to a
> SNE "node" object, and an NSI Endpoint maps best to a SNE "port"
> object.

That is correct.

> Including the GOLE object creates additional RDF output and causes
> additonal [unnecessary] processing if it is expected or present in
> the RDF description, and is not critical for NSI protocol interop.

It is indeed unnecessary. Again, if we just want to show the pingerboard
again as the result of this demo, then that's fine.
If we want to enable more impressive visualisations like Google Maps or
Automated Earth, then please add the information.

It takes you a couple of minutes to fill out, and adds about .1%
overhead into the parsing, and from then on it can be ignored. I believe
that's a fair trade-off.


> The Switchmatrix object is likewise not defined within the NSI
> topology model. While such an object may be of some use in the future
> for defining transfer functions of various topological objects, there
> is no defined rules for the switchmatrix object now, nor is it
> currently in the NSI context. So while it is probably harmless, it is
> still overhead, I propose we likewise ignore it for now.

The SwitchMatrix plays a vital part in the pathfinding. It defines
whether the switch can swap labels or not, and what labels are still
available. It is vital if we start using labels.

> There is no semantic validation by SNE or the schema as to what these
> numbers mean

Correct. The editor is a result of scientific programming, and not some 
production code. I apologize. Hopefully, the text file I sent and 
replies I send to the mailinglist can help with the semantics.

In the example I sent, I used bytes per second as unit, because that is 
what GMPLS uses. If we use something else, that's fine also, but it has 
to be clear to everyone.

 > I propose that we explicitly define all NSI
 > Endpoints (SNE "port"s) to be uniform: all Endpoints (SNE "port"
 > objects) for the plugfest will be "untagged" (i.e. no subdividing
 > Ports into virtual connections. I.e. "label" fields="0")

This was part of the solution that we proposed. We are proposing one 
phonebook for topologies, and another one for endpoints, *with* 
associated labels, because that is where the endpoints end up.


> 4. You need to specify the connectsTo relation from each port to the
> corresponding port to indicate bidirectional connectivity. There used
> to be relation links to do this, but they seem to have been removed
> now in the SNE gui.

True. I removed the connection, and changed it to a text field to make 
it easier to define interdomain connections. Otherwise you would have to 
create a 'foreign' Port object and express the relation, and all the 
details of that Port.

> 5. There is no relationship generated in the RDF that links a port
> to its parent node. The hasPort relationship only generates a link
> from the parent node object downward to the child port object. To
> find the parent node associated with a port, one must search for the
> port name in the list of hasPort relations of all the Node objects.

Yes, this is the way that RDF works. For querying RDF the direction of a 
property does not really matter. One can do either:

   ?x dtox:hasPort uva:force10-0-0

or

   uva:force10 dtox:hasPort ?x

See also SPARQL: http://www.w3.org/TR/rdf-sparql-query/

> However, since this is simply an artifact of the SNE RDF, an NSA
> reading the RDF information need not use the RDF directly internally
> - it can translate it into its internal topology and build whatever
> links it needs internally one time as it imports the RDF. However,
> since the RDF is generated by the SNE interpreter, the object names
> must still be globally unique in order to generate all the objects.

There are many many different RDF libraries for all the major 
programming languages. It takes just a little bit effort to learn to use 
one. However, this pays off in parsing, since there is almost no manual 
parsing to be done anymore, and as shown above, querying is incredibly easy.
Also, most RDF libraries allow you to for-loop through objects using 
some simple constraints.

>
> 6. Note also: The SNE constructs/relations seem to be in flux. (the
> connectsTo relation has changed in the last week or so.) So the
> generated RDF/OWL code may change. And there may be implications to
> existing defined topologies being interpreted correctly. So just
> keep an eye open for this.

I changed only the connectedTo statement before sending out the 
instructions. Unless something really breaks, I am not going to change 
anything anymore.

Jeroen.