[Nsi-wg] Topology version 1.1c

[Jerry Sobieski]

Hi all-

Last week someone noticed that the names of the networks and STPs in the 
RDF/OWL files did not conform to the URNs described in the NSI CS 
spec.   So in exploring this issue, I believe we have a conflict in the 
URNs.   And since I do not want to distract any further from the 
development, I am specifying a Rio topology database that avoids the 
issue completely.   We can discuss it in Rio after the demo:-)

So to avoid a long discussion prior to Rio,  I am circulating a new 
topology file.   This file describes the Rio Ring as before but with the 
following changes:
1. The "http://glif.is/.../detox#" prefix has been removed from the all 
Resource names and references.
2. The names are NOT the URN form; they are just the simple strings that 
identify the object.


The issues I found confusing are:
- First, the NSI spec defines an STP to have a network identifier and an 
endpoint identifier  of the form:
     urn:ogf:network:STP:<networkname>:<endpointname>
...an attempt to capture the NSI tuple notion we've been using for NSI.
A similar URN exists to specify network names:  
urn:ogf:network:NSnetwork:<networkname>
If we substitute the network URN as the <networkname> in the STP URN we 
get a rather unusual URN result:
    Example:      urn:ogf:network:STP:urn:ogf:network;NSnetwork:Aruba:Aiden
This funky URN is at least one interpretation of the spec.   I don't 
think this is what was intended.   The confusion comes from the 
<networkname> portion of the STP URN - is this *really* a "network" 
name? ...Or just another namespace qualifier that insures the unique 
scoping for the <endpointname> component?   If it really is a network 
name, then you get the funky URN.   If it is just meant to add additonal 
namespace scoping, then *any* tag could be used in  the <networkname> 
component - i.e. it does not have to be a network name at all.  Which is 
fine...except that the STP URN would no longer uniquely identify an STP, 
it would just be a unique endpointname that could belong to *any* 
network.   I believe there is the assumption that the STP URN contains a 
valid network name that can be used to locate the NSA associated with 
that STP.   IMO, this is a problem in the spec and is pretty fundamental 
to the protocol.

- Second, the NSI CS spec governs what should be in the CS protocol 
messages, not what should be in a topology database.   So we don't 
strictly need to have the URNs in the topologyDB as there is no topology 
model or standardized database structure that requires it.   Therefore, 
as long as we know how to map a NSI-CS URN to the name of the desired 
object in the topoDB, or vice versa- construct a URL from the object 
name in the topoDB, we should be fine - at least for Rio.

  - Third, what is "best" for the topologyDB depends a lot on how the 
various NSAs intend to use or represent that topology.   And its not 
clear to me how the various NSAs are using the STP and NSobject URNs.


Example:  the endpoint "A1" in network "Aruba".   The namedindividual 
object for the STP A1 is now called just "A1"...not 
"http://glif.is/working-groups/tech/detox#A1", nor is it called  
"urn:ogf:network:STP:Aruba:A1"   Likewise, the NSnetwork topo object is 
called "Aruba", not "http://glif.is/working-groups/tech/detox#Aruba", 
nor is it called  "urn:ogf:network:NSnetwork:Aruba"

Note: the resource /types/ were not modified.  These still use the 
glif.is/...dtox prefix. (I wasn't sure if changing these would break the 
RDF)

For Rio, I have insured that all objects will have unique short names 
ala A1, B2, M3, etc. across the global topology.  Therefore, you can 
locate the STPs associated with a Network by: "Aruba hasSTP ?" and vice 
versa find the NSnetwork associated with an STP by  "? hasSTP A1"    
Again, this is an expediency for Rio and will be an issue we need to 
discuss for future topo database.

I know some will object to this (someone *always* objects)...but this is 
sufficient for Rio and will allow us to put the focus back on NSI - not 
the cobbled together hacked up topology database.  As always, what we do 
in the name of Rio should not be considered anything but a 
temporary/interim approach to be reviewed afterward and done better.

Questions?   Let me know.
Thanks
Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110906/38ad127a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Rio-Inter-Domain-Topo-Ring-v1.1c.owl
Type: text/xml
Size: 19863 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110906/38ad127a/attachment-0001.xml