[Nsi-wg] NSI naming

[John Vollbrecht]

This is good discussion.  It would be good to have some goals for the  
two groups so that we can have  standards that are in sync.  I try to  
list a few inline below --

On May 11, 2009, at 2:30 PM, Martin Swany wrote:

> Hi John,
>
> For, reference, we have updated the terminology
> spreadsheet here:
>
> http://forge.gridforum.org/sf/go/doc15512?nav=1
>
> I left out the cases that were OK.
>
>>  This is a link at a level.  This seems a fine name.    For NSI the  
>> question is if the link can carry links at a different level.  I  
>> think so - I think there is a relation which says a link at one  
>> layer can support multiple links at a different layer.  Examples  
>> would be multiple VLANS over ethernet or multiple VCGs over SONET,  
>> or multiple waves over a fiber.
>
> This is definitely part of the model.
As noted in later notes the concept of layer and level are close.  I  
think for NSI we need a definition of what links over other links are  
called.  Does the over refer to level or layer?  What exactly is a  
level or layer.  Some discussion of this has gone on informally that I  
know of, but noting written down.  This may be the major concept to  
hopefully be define between us at Chapel Hill.

>
>
>> <pastedGraphic.pdf>   logical port (per layer) - G.805 calls this a  
>> connection point, NML and NMwg call it a port.  In NSI we started  
>> discussion calling it a Port but switched to edge point to avoid  
>> the physical connotations of port.  The groups should agree on this  
>> name or include an alias for different names if we can't agree.
>
> I think that the NML has agreed to call this a port.  Our
> naming was changed a while ago (due to ITU naming!)
> in perfSONAR and I believe the NDL group has agreed.
> Certainly any term carries connotations, but the pervasive
> opinion is that they are more similar than they are different
> and it is useful (for pathfinding) to use the same underlying
> term, but specialize it for different purposes.
I personally have no concern about what it is called as long as  
everyone agrees.  However it is a group decision, so both groups need  
to agree.  In my opinion since the G.805 doc calls it a point - I  
personally like having point rather than port in the name.  This is a  
discussion also for Chapel Hill, but lower priority than the above.
>
>
>> <pastedGraphic.pdf> concatenated series of links - Path in NML and  
>> NMwg, concatenated series of links in G.805.  It seems to me that  
>> this should be a link not a path.  I am not sure when some thing is  
>> a path rather than a link.  I also think a concated series of links  
>> is a link (maybe it needs a name to become a link?)
>
> In my mind, there is often a one-to-one relationship
> between paths and links and the only question as to
> which you use is whether you need to see the internals
> or not.  I think this addresses and issue below as well.
This is confusing to me.  What internals does a path see or not see vs  
a link?  Is a path resourceless?
>
>
>> <pastedGraphic.pdf> Network Layer (topology on a single layer) -  
>> This seems an important concept - topology on a layer.  A couple  
>> parts of this that I think may need definition: 1) how to tie  
>> together administrative domains with topology - for example one  
>> administrative domain may know about a subset of what another  
>> administrative domain knows; and 2) How do layers interact - is one  
>> layer carried by or used by another?
>>
>> <pastedGraphic.pdf> aggregated device -- called topology in NML.   
>> this might be a network in NSI, but I am not sure that fits well.
>
> I don't know that there's agreement that an aggregated
> device is a topology, but it sounds like this isn't an issue
I don't think this is an issue unless someone wants to use it instead  
of topology
>
>
>> <pastedGraphic.pdf> domain -  this seems like a network in NSI  
>> terms.  Certainly it has a lot of the same characteristics.   But  
>> it does not have all the characteristics - see discussion on "what  
>> is missing" below
>
> The easiest answer is that we can add characteristics and
> plan to do just that as the base elements are "subclassed"
> into specific uses.
>
> But I do understand that there is a little gray-ness between
> Networks and Domains.  My own take is basically this:
> Networks are addressing scoped, and Domains are
> administratively scoped.  I take that largely from
> Internet terminology and I know there are counter-
> examples.   So, the more complicated answer is that
> there are a number of different kinds of groups and
> we need to see which ones fit.
>
I think this is the other very high priority thing to agree on at  
Chapel Hill.  NSI has the concept of a network which can be controlled  
by an NS agent.  This network has a topology which to the outside  
world looks like a set of edgepoints (or ports).  I am not sure what  
corresponds to in NML.  Also, NSI has the concept of a link which has  
resource which may be an independent administrative domain from  
networks to which it connects.  I am not sure how these all fit the  
definitions.

>> What seems missing --
>>
>> 1) The description of adapatation in general:  for example in a  
>> concatenated series of links, each concatenated link may be carried  
>> on a different sort of higer layer link.  A VLAN might be carried  
>> on an Ethernet link (as a VLAN), on a SONET link as GFP encoded  
>> VLAN.   In this case the underlying link with its coding is carried  
>> over different higher layer links with their coding.
>
> I believe that this is a good example of where the Link/
> Path dichotomy helps.  If we need to know that details of
> of the different sorts of constituents, we need to access
> the path object, otherwise it's just a link.  Also note that
> I don't really think we have any fixed notion of "higher"
> and "lower" layers now.  I know that we did in perfSONAR
> but there were so many special cases of relationships
> (L2TP, q in q, ip in ip) that we pretty much gave up.  So,
> I don't think there are any problems with representing
> what you're talking about above, so maybe we should
> try to look at specific examples?
>
I think we should look at examples.  One such example is the one  
described briefly above.  It might be interesting to include perfSONAR  
examples.

>
>> 2) The concept of connection oriented network:  A NSI network is  
>> something that can create segments (aka links a lower layer)  
>> between edge points (aka ports).  A network participates with other  
>> networks in a topology where the elements are networks that  
>> connected with links.  In graph theory network would be node, and  
>> link an edge.
>
> I think that a Link represents a network connection
> pretty well.  Maybe the Path/Link discussion is
> convincing, but I should say that's more of the perfSONAR/DCN
> perspective and not that of NDL (necessarily -- I think
> it's close, but I won't speak for them.)

I am not sure what the Path/Link discussion is ---
>
>
>> 3) Names for the elements within a layer that are concatenated.   
>> NSI calls these segments for now.  The NSI topology elements are  
>> links and networks.  Each of these elements can provide segments  
>> and the segments can be concatenated to create a ete segment.  I  
>> believe that segments and links at a level are identical concepts,  
>> so  perhaps we can come up with an alias for how to describe NSI  
>> segments and ete concatenated segments.
>
> Again, hopefully, the Path/Link concept describes this
> for the complicated case.  (And a simple relation works
> when 4K VLAN links are carried over the same Link....)
I think examples and then a specific agreement on naming - perhaps  
aliasing - is needed
>
>
>> I suggest that we might want to have a call to start discussions on  
>> this before OGF and to try to resolve issues at OGF.   There is a  
>> NSI call every Wed at 9ET - we could have a joint call on Wed May  
>> 20 if that seems reasonable.
>
> I can't make this slot (or would have to join late at the
> very least.)
>
> best,
> martin

John Vollbrecht
Senior Network Engineer, Internet2
office 734 352 4960 cell 734 395 7890