[Nsi-wg] Determining the Network of an STP

[Jerry Sobieski]

Hi Freek- you are essentially correct.  But there is some added comments 
inline.

On 6/27/12 6:00 PM, Freek Dijkstra wrote:
> During today's call, Jerry brought up the following issue:
> (Jerry, please correct me if I'm wrong, and sorry if I mixed up the NSI
> with the NML terminology).
>
> A path computation engine needs to know in which domain a STP lies.
Bingo.  At least for the inter-domain environment in which NSI operates.
>
> There are solutions to this:
> 1. The domain can be inferred by parsing the URN identifier of the STP.
> 2. Each domain announces a full list of it's STPs, and the path
>    computation engine keeps a table of all STP-Domain relations
> 3. Each connection request must not only list the URN of the STP,
>    but the URN of the domain as well.
>
> The current solution is (1), but that conflicts with the choice in NML
> that a URN may not contain the domain identifier and should not be
> interpreted/parsed. Solution (2) or (3) do not have this drawback.
> Solution (2) seems less scalable compared to solution (3).
#1 was adopted by NSI WG in SLC last summer as an interim approach for 
v1 topology.  A lot of issues were still unclear, so we took the interim 
step to use the simple DToX model (and we even needed to modify it a bit 
too.)   Part of this decision included munging the 2-tuple STP name into 
a single URN string (this was not a unanimous approach - but it got us 
off the mark.)   This #1 approach does require that NSA aggregators need 
to parse the STP URN to determine the home network - I am not strictly 
opposed to parsing an *NSI* STP name to decompose it into some 
structural components, but I do agree that parsing a *URN* specifically 
is counter to the purpose of a URN.  And mapping any content or 
structure onto a URN besides administrative scoping is almost always a 
bad idea.  (I think some v1.x implementations cheated with this approach 
and used the RDF topology as a directory to look up STP URNs to get 
name-domain mappings...while this avoided parsing the URN, it is not 
strictly conformant to the NSI framework and breaks if the STPs are not 
all defined in the topology.  The NSI framework will work as long as the 
STP 2-tuples are used for STP references. )

#2 is essentially a directory service - whether your distribute STPs as 
part of the topology or as a separate phonebook, you have the same 
problem: All STPs must be defined and announced in this global directory 
before they can be used in a Reservation Request.    This 
phonebook/directory service is computationally tractable, but it 
nonetheless has scalability issues for a global inter-domain service 
like NSI.  It is centralized (bad), or it is distributed (requiring 
complex protocol to keep it coherent and convergent.)   And frankly, for 
simple end system STPs it is unnecessary as long as the STP reference 
includes the network id innately - which it currently does.   Unless we 
want a flat name space without hierarchical structure, then our 2-tuple 
model provides a basic hierarchical interdomain mapping that precludes 
the need for a global STP directory service.

I would phrase #3 a bit differently:  The STP name is already and *by 
definition* a 2-tuple consisting of the network (domain) identifier and 
a local identifier.   These two elements together comprise the STP 
name.   I would suggest that an STP reference might be a compound object 
ala:
<stp_ref>
<net_id>nordu.net</net_id>
<loc_id>svr1-1-204</loc_id>
</stp_ref>

This #3 is (IMO) the best solution.  It explicitly delineates the 
<networkid> component from the <localid> component - which means parsing 
a single string or URN is not required, and the name-domain mapping is 
explicit in the reference precluding the need for a directory.   With 
the compound reference, as long as the network can be found in the 
topology, the NSI PF does not need to know specifically how to route to 
the local end point.  the local NSA will resolve that internally.

I would surmise that this compound STP object could still be given a 
URN, which would make it useable within the current RDF/OWL topology.   
But this then would re-introduce the need for directories.

The aspect that I like about #3 using the compound reference is that it 
allows us to separate the naming of objects internal to the NSI code 
implementations from the names that users and engineers may wish to use 
to identify their networks and end points more generally and which users 
will wish to use when specifiying their requests.  The URNs for user 
interfacing are horrid.

One last observation:  By referencing STPs as compound objects we 
obviate the need for global directories.  We also do not need to define 
STPs globaly if/when they only have local significance.  (An STP is 
"only locally significant" if it does not share an SDP with another 
network.)    Thus we don't need to advertise these local only end point 
names in topology as the path finders get what they need from the STP 
reference itself.    However, this *does not* preclude the need to 
advertise STPs that *are* part of an NSI SDP adjacency(!!).   These 
adjacencies must still be advertised as part of the topology - indeed, 
these SDPs define the topology, the inter-connectivity among networks.

Hope this helps!
Have a nice weekend!
Jerry
>
> Regards,
> Freek
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg