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/req... 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