[Nml-wg] NSI issues - section 6 - naming

[Freek Dijkstra]

I mail this to the NSI and NML-WG.
To keep cross-posting to a minimum, is it OK to discuss the formalities
 on the NSI list and schema details on the NML list? Jeroen and I will
summarize the outcomes on the other list.

Background: The NSI is drafting an "Issues" document. About two weeks
ago John Vollbrecht wrote:

> I.	Naming of Endpoints and Connections
> Naming will be joint with NML wg at OGF.   Definition of elements that need names in NSI.  My suggestion is that we include names of network edgepoints, names of trunks connecting NSs to each other and to other devices,  It should also include names for dynamic coneections, the concatenated connection segments from many NSs.
> 
> There are existing naming conventions that should be reconciled as much as possible.
> 
> I think it would be good to form an “official” liason with the NML group – what do others think?


As agreed during last week's NSI conference call, Jeroen van der Ham and
me (Freek Dijkstra) drafted a short naming section for the NSI issues
document.

I'll attach it right away, including John's comments in bold
(unfortunately due to illness and holiday we didn't have time to redraft
it yet).

In my view, this section should provide usage requirements to the
NML-WG. Currently it is still drafted the other way around: very short
explanation of the NML base classes.



Perhaps we can discuss some of these in today's NSI conference call.
Unfortunately, I can only call in for a limited time (30-45 mins).

John, a few of your remarks are not clear to me yet:

> •	Port is associated with a Node to connect it to the network. A Node can have multiple ports.
> [In NSI  terminology as of now this would be a network termination point]

Are you sure this is the same? A NML Port does not need to be a
termination point, but can also be a forwarding point.

> •	Path is an ordered list of Network Elements, describing a path through the network. This need not be a completely detailed description of the whole route through the network.
> [In NSI current terminology this is almost a connection.  However it doesn’t seem to have resources associated with it.  It also doesn’t seem to have time duration associated with it]
> [Also, it does not have a concept of path (or connection) segments which are concatenated to create an ete path]

What is "it" here? An NSI connection or NML Path?
If you say "it doesn’t seem to have resources associated with it", what
resources are you talking about? segments of the path?

NML Paths will have an association with its' segments: other link
objects and path objects.

Be aware that I expect the Path concept to change in the NML-WG when it
is discussed in more detail there. For example, it is not clear if a
protected lightpath is described as one or two Path objects.

Currently, the NML has not defined time information, but I expect that
we will copy the time concept that is currently defined in cNIS.


> •	Topology is a set of connected Network Elements describing a network topology, for example the description of Netherlight is a topology.
> •	Domain is a group of Network Elements. The Domain can be of different types, describing its role in the provisioning process. This is based on the terminology of the Stitching Framework [1].
> [A domain seems close to a Network Service in NSI. question – how does the NSI concept of Network Service Agent fit – does each NS domain have an agent?]

We discussed the distinction between Topology and Domain at the interim
NML meeting in Berlin about half a year ago. I'm not sure of the outcome
(I can't find it), so I'll just give my *personal* opinion:

- a topology is a physical thing -- a collection of network elements
that "behaves as one"
- a domain is an organisation thing -- a collection of people
responsible for managing resource, including network resources (but
perhaps also including computing resources).

I am extremely interested in the opinion on NSI folks -- should a
Network Service be part of a topology or part of a domain?
I haven't made up my mind yet...


> o	User Domain A terminating domain where the users system resides
> [is there a concept of an end-user that has no domain (or agent)?
> o	Linking Domain A domain that is part of the path
> [provides a segment]
> o	Source Domain The first domain that realizes the provisioning request
> [I would think this should be one end device of a connection/path]
> o	Destination Domain The last domain that realizes the provsioning request.

These domain concepts are taken from the Stitching Framework. I'll
forward your questions to Victor Reijs. Perhaps he can answer them.

> Meanwhile, the GLIF community will soon start to use lightpath identifiers [2]. The Source Domain creates a lightpath identifier. It contains a DNS-like name of the Source Domain, followed by a local-identifier part, for example: 
> [I would think that the name could be created by any agent that has a unique identifer.  Using source domain may be difficult if the source domain is different than the requestor for the circuit.]

Could point. I'll forward this question to both the GLIF community
Lightpath identifier task force, and use it as input for the NML-WG.

Regards,
Freek Dijkstra

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NSIArchIssues.sec6.naming.0218.doc
Type: application/msword
Size: 55808 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20090218/5b475629/attachment-0001.doc