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.