[Nsi-wg] Identifiers

[Jerry Sobieski]

Hi Jeroen et al-

First a minor nit:  the current NSI form is 
"urn:ogf:network:stp:<networkname>:<local part>" .  I.e. there is no 
"opaque" multilevel subspace under the <networkname> component in STPs.

More importantly, Our desire is to develop a naming convention that is 
compatible with both NML *and* NSI - so it may be that we need to modify 
the NML naming convention instead (or also)... we need to look at both.  
so keep an open mind how this is best reconciled.

Step 1.) It seems to me the preliminary issue to be resolved is the 
actual object mappings.   We have had some preliminary discussion on 
this that I think poses a good starting point...

Step 2) Then we need to develop some NML topology examples that 
replicate the current NSI topologies.  This will provide concrete 
examples of how the existing [working] topology constructs will be 
represented in NML.

Step 3) Then we need to analyze how NSI would work processing these new 
NML examples, and where it breaks.   And we resolve those issues by 
changing the NML construct, or by changing the NSI functionality - or a 
combination of both.

A basic question occurs to me:  Why do names need to be consistent 
within NSI and NML?   What breaks if NSI maintains its current naming 
scheme?

The NSI protocol needs to be able to map an STP to its home NSI 
network.  The current NSI CS 1.1 specification describes the two-tuple 
<networkid>:<localid> STP name implemented as a URN.   It stipulates 
that the home network is identified by the network name portion found in 
the STP reference.

Due to the current dtox topology that is informaly being used by the NSI 
implementations, the network associated with an STP can also be found by 
looking up the STP in the topology DB and linking to the NSI Network 
object.   THis works fine, but to be clear - it is an artifact of the 
dtox topology, not NSI standard.   Thus the lookup mechanism may not be 
used or even work in all NSI implementations.  Thus we need to maintain 
the two-tuple NSI STP.   ...but this could be encoded in a URN an other 
ways...

My concern with the lookup mechanism is that it requires STPs be present 
in the topology db in order to determine which network they belong to.   
Implicitly, this requires all STPs to be advertised in the global 
topology.  Indeed, this means *_/all/_* STPs- including simple end 
system STPs that are not members of any SDP.   However,  NSI CS does not 
require any topological knowledge of simple STPs - NSI only needs to 
know in which network an STP resides and any adjacencies to that network 
to choose the egress point.    This is sufficient to segment the request 
and to perform path finding.    Thus there is no current requirement for 
ALL STPs to be announced - only those that are part of an SDP (the 
adjacencies.)

One can imagine that the simple end system STPs will out number SDPs in 
most networks - probably by orders of magnitude (consider how a 
campus/data center might fanout one or two WAN links to hundreds or 
thousands of possible end systems.)  Given the number of virtual 
endpoints we will have globally - even with a compact syntactic 
enumeration of STPs - this amounts to a significant(!) amount of 
topology data that is not strictly necessary and will only rarely be 
referenced.

A more efficient system would simply announce NSI Networks and their 
adjacencies (SDPs).   All STP references would implicitly resolve to the 
network contained in their name.    Thus a user could specify a STP that 
he knows is available locally, but which had not been announced to the 
world, and the NSAs will successfully segment and reserve the connection.

I believe the NSI hierarchical two-tuple <networkid>:<localid> must be 
maintained as we reconcile the NML form to NSI.   I think this will 
prove high useful in both path finding and topology distribution.

It seems to me the <DNS> requirement for the NML name could be relaxed 
slightly to be a bit more flexible for NSI network name requirements 
without undue harm to NML.

I suggest that there is no need to name STPs with a year component - 
this should be removed.   (Why is it even required for NML?)

I actually think I like the possbly multi-level <opaque part> in the NML 
spec if we make some stipulations about its construction for STP names.

I pose for discussion the prospect of a subspace - either 
...:ogf:network:nsi: , or a sibling ...:ogf:nsi:  that we could use to 
identify specific NSI names.   Could these maybe be used to reference 
NML objects directly or indirectly?  THus allowing NSI to maintain its 
current naming structure under a different subspace....?

As a related issue, we also need to decide what that distribution 
process ought to be.

Thoughts?
Jerry





On 6/12/12 9:05 AM, Jeroen van der Ham wrote:
> Hi,
>
> We need to take a decision regarding the identifiers used for STPs and other elements.
>
> The NML-WG has taken upon itself to register the urn:ogf:network subnamespace, and to make it available for the identification of network resources. The group is currently writing a document describing how that should be used. The current accepted proposal is the following form:
>
> urn:ogf:network:example.com:2012:opaque:part
>
> So after the urn:ogf:network part comes the DNS name of the organisation defining the identifier, followed by the four digit year in which the identifier was created, followed by a local part.
>
> The current Automated GOLE uses identifiers of the form below, which is not compatible:
>
> urn:ogf:network:stp:example.ets:opaque:part
>
>
> We have a couple of options going forward:
>
> - use identifiers following NML-WG standard
> 	a) allow domain owners free form in the opaque part
> 	b) define that opaque part should begin with "stp:"
> - try to register a different urng:ogf subnamespace
>
> Note that the last option is not that simple. We have to propose a scheme that will ensure indefinite uniqueness, which would probably be something very closely resembling the NML-WG scheme.
>
> Jeroen.
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120613/d39cc8a7/attachment.html>