I was asking the question more from the point of NSI than NML, however, I would love to get your thoughts on an NML schema for Ethernet since this is what we are using in the current NSI service definition. John On 2013-09-09, at 12:39 PM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
John,
I'm currently on holiday with very limited connectivity, hence the delay in response. I'll be back at work on the 23rd but hope to have a look at these discrepencies next week when I have better connectivity.
Some quick notes inline....
Freek
On 9 sep. 2013, at 19:10, "John MacAuley" <john.macauley@surfnet.nl<mailto:john.macauley@surfnet.nl>> wrote:
Peoples,
As I go through the effort of integrating the NML topology files with path finding I am noticing some misalignments based on the different times at which parts of the specification where defined. If other people are finding the same consistency issue please communicate them. I would hope I am not the only one.
In the NSI point-to-point service we have defined a label on an STP to be the following:
<labels> <attribute targetNamespace="http://schemas.ogf.org/nml/2012/10/ethernet#" type="vlan"> <value>1782</value> </attribute> </labels>
However, in NML they have defined a LabelGroupType for label ranges, and a LabelType for specific label specification.
<nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2012/10/ethernet#vlan">1780-1783</nml:LabelGroup>
This seems right. On top of my head, for a specific label one would use:
<nml:Label labeltype="http://schemas.ogf.org/nml/2012/10/ethernet#vlan">1780</nml:Label>
(Sorry for any bad copy/paste formatting)
The NML also creates unique attribute names/types by combining namespace # attribute, whereas in NSI we have kept them separate requiring two fields (targetNamespace and type) to qualify the attribute name. We should probably normalize these two definitions. Comments?
In NML, the labeltype is a URI, there were some issues with combining URIs as < namespace "#" fragment > because of some subtle differences between XML vs RDF, but no show stoppers as far as I can tell. So my current thinking is
As for a formal Ethernet extension document, there is none yet, so my suggestion here is to just create abteivial document that only defines http://schemas.ogf.org/nml/2012/10/ethernet#vlan (for c-vlan or s-vlan?) and if we need more details later (s-vlan, c-vlan, b-vlan, i-sid distinction, etc) we create a revised document. I very much appreciate if you, as expert, gives a suggestion what you would do.
Also, just so we are all on the same page with respect to STPs and their mappings onto NML constructs…
The STP networkId is populated with the Topology element identifier, while the STP localId is populated with either the BidirectionalPort element identifier for bidirectional connections, or the PortGroup Id for unidirectional connections. For example, using the netherlight A-GOLE file we would get:
networkId = urn:ogf:network:netherlight.net:2013:topology localId = urn:ogf:network:netherlight.net:2013:bi-netherlight-geant
Seems right, though I'm always a bit confused by the exact meaning of "localId" in NSI and can't look it up from here.
Thanks, John
I beter keep it short. I took my iPhone for a swim last week (doh) and it seem to have survived remarkaly well following some simple thing (let it dry for 48 hours before trying if it still works) but it is getting hot while I type this....
Freek
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org<mailto:nsi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/nsi-wg