[Nml-wg] Multiple namespaces

[Jason Zurawski]

Hi Freek;

Comments inline:

On 8/22/11 6:24 PM, thus spake Freek Dijkstra:
> Last week's mail conversation drifted from XML syntax for NML relations
> to the use of namespaces in NML messages.
>
> An important difference in view was identified.
> Jason assumed that a single NML messages would only contain one namespace.

I never said nor implied this in any way - in last weeks email exchange 
or in prior conversations; please do not try to summarize my opinions 
for me.

A web service message contains lots of elements with potentially 
different namespaces - this is how it is in perfSONAR today and how I 
would envision a set of topology to be encoded in NML.  See examples 
from services in action: 
https://svn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-SNMPMA/etc/requests

A rich vocabulary of elements from these namespaces is the only way to 
foster extension and handle future use cases for this work.  I envision 
that some network (and by extension, some exchange that would be 
witnessed by an NML capable service) may have different layers 
represented, and thus different namepsaces in use to describe links, 
ports, and other entities using the network abstractions at these layers.

> I assumed that a single NML messages would only contain multiple namespaces.
>
> While a few example crossed the list, those were very probably not very
> relevant nor convincing. So I'll explain a bit better how I envision the
> different namespaces:
> - core topology concepts (link, node, port, adaptation, ...)

Correct, living in a namespace similar to this:

   http://ogf.org/schema/network/topology/base/20070828/

Note this is something we used today, I expect the name will change.

> - Ethernet-specific topology concepts (VLANs, segment size, ...)

e.g. http://ogf.org/schema/network/topology/l2/20070828/

> - IP-specific topology concepts (IPv4/IPv6 address, routing table, ...)

e.g. http://ogf.org/schema/network/topology/l3/20070828/

> - geography enhancement (geo location)

I am not sure why this would be viewed as a different topology extension 
akin to the network layers.  Presumably this enhancement would make more 
sense as being being built into a base since most 'physical' things 
(e.g. a node, port) would need it.

> and I potentially see a mix&  match with other applications:
> - path finding, topology aggregation, domain control (NSI, provisioning)
> - monitoring, performance (NMC)
>
> I expected and still expect each of the above to go in a different
> namespace.
>
> The above leads to three scenario's in mind where it may be prudent to
> mix namespaces in a single message:
> - core topology with technology specific (Ethernet, IP, ..) namespaces.
> This is probably the weakest use case, as it is possible to add the core
> topology concepts to each technology specific namespace (e.g. using
> chameleon namespaces)
> - topology namespace with geo namespace
> - topology namespace with an application-specific namespaces (eg.
> topology + NSI for path finding, or topology + NMC for monitoring).

You describe all of the things that I (and others in SLC) were arguing 
for all along - the ability to extend the base ideas concepts into new 
use cases through the use of namespace extensions.  I will make one 
quibble on the above - I would argue its important to make the 'base' 
set minimal, e.g. 'ethernet', 'ip', etc. are not *in* the base, these 
are extensions *of* the base.  I am still not sure of your GEO use case, 
so perhaps you should clarify this and the others with some examples.

The base NML concepts will most likely not be enough for some use cases 
(e.g. monitoring or circuit creation).  It is important for these 
concepts to have the mechanisms available to extend the base concepts, 
yet still have some way to convert (downcast, etc.) to something that 
can be understood by other implementations.  The prior art that is in 
use for the Control Plane schemas and even some perfSONAR topology 
representations is a good example of all of this.

Thanks;

-jason