This post by Jason was blocked by the list. My apologies for not handling this correctly. -------- Original Message -------- From: Jason Zurawski <zurawski@internet2.edu> Subject: Re: Serial compound relations Date: Mon, 13 Dec 2010 16:59:48 +0100 To: Network Markup Language Working Group <nml-wg@ogf.org> CC: Freek Dijkstra <Freek.Dijkstra@sara.nl>, Roman Łapacz <romradz@man.poznan.pl>, Aaron Brown <aaron@internet2.edu>, Brian Tierney <bltierney@es.net>, "Jeff W. Boote" <boote@internet2.edu>, Mark Yampolskiy <myy@dfn.de>, Wolfgang Fritz <Wolfgang.Fritz@lrz.de>, Sandor Rozsa <sandor.gyula.rozsa@cern.ch>, Ramiro Voicu <Ramiro.Voicu@cern.ch>, Joe Metzger <metzger@es.net>, Michael Bischoff <michael.bischoff@controplex.com>, Szymon Trocha <szymon.trocha@man.poznan.pl>, Martin Swany <swany@UDel.Edu>, Guilherme Fernandes <fernande@cis.udel.edu>, Jeroen van der Ham <vdham@uva.nl> Hi Freek/All; Comments inline: On 12/10/10 5:18 PM, Freek Dijkstra wrote:
Attached is a proposal how to describe serial compound links, thus how to describe the individual segments in a path.
The example is given as a picture and in XML.
Observe that only the "link" concept is used; "path" is removed from NML (the reason is that a path can be extended and form a link in an even larger path).
The example uses two distinct methods to stitch paths together: - Using ports (if the sink of link A is port X, and the source of link B is also port X, you know that links A and B are connected in series) - Using explicit ordering (order="1", order="2").
This is done on purpose. If all port information is known, the ordering can be determined using the first method. However, not all information may be known. For example, a domain may want to say that a segment is part of a path, without knowing details about the other segments (eg. segment BC may be provided by a different domain):
<nml:link type="link" nm:id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound" cl:type="partial"> <nml:segment nm:idRef="urn:ogf:network:example.net:segmentAB"/> </nml:relation> </nml:link>
Is there a reason you choose to introduce a new element (segment) instead of using link? I think we are all aware of the 'segment vs link' battles of past OGFs that have spanned many different working groups, and I was under the impression that the outcome was to use 'link' for all connections instead of switching between names.
For now, I picked a simple method to specify ordering, using a simply number ("order"), and a total count ("count") so I know the order, and that it is a complete list.
<nml:link type="link" nm:id="..."> <nml:relation type="serialcompound" cl:count="3"> <nml:segment nm:idRef="..." cl:order="1"/> <nml:segment nm:idRef="..." cl:order="2"/> <nml:segment nm:idRef="..." cl:order="3"/> </nml:relation> </nml:link>
I choose some arbitrary names for some attributes; I'm happy to discuss that in another thread.
Aaron had a different proposal that would avoid the use of an attribute added into link (or in your case 'segment') and go with the idea of a linked list. This proposal would also use references and does not require new elements/attributes but would introduce a new relation type (name TBD): <link id="abcd"> <!-- Include any other end to end data here ... --> <relation type="serialcompound"> <!-- N.B. think of these as 'pointers' to the original definition of the link. Therefore we can use them freely in any topology reference, even across domains. --> <link id="_ab" idRef="ab"> <!-- This establishes the 'next' hop, but could probably be used in the opposite direction for a previous hop as well. --> <relation type="nextHop"> <link idRef="_bc"> </relation> </link> <link id="_bc" idRef="bc"> <relation type="nextHop"> <link idRef="_cd"> </relation> </link> <!-- The tail would not need a relation --> <link id="_cd" idRef="cd" /> </relation> </link> This is a lot cleaner in my opinion than a special purpose attribute. It can also be used in both of your cases (explicit and derived) since the addition of a relation and an idRef'ed element add only bits to the transaction.
<!-- Example of serial compound links --> <!-- NML draft proposal 10 dec 2010, Freek Dijkstra -->
<!-- Example topology:
|<------------------------------------------>| pathAC
+----------+ +----------+ +----------+ | Switch A | 3/1 4/1 | Switch B | 5/2 6/2 | Switch C | | |---------------|..........|---------------| | | | segmentAB | | segmentBC | | +----------+ +----------+ +----------+ -->
<nml:topology xmlns:nml="http://schemas.ogf.org/nml/2013/10/base/" xmlns:nm="http://ggf.org/ns/nmwg/base/2.0/" xmlns:cl="http://schemas.ogf.org/collection/1.0/">
<!-- for simplicity, this example only deals with unidirectional links -->
<nml:node nm:id="urn:ogf:network:example.net:switchA"> <nml:hasport nm:idRef="urn:ogf:network:example.net:switchA:port3-1:egress"/> </nml:node>
<nml:node nm:id="urn:ogf:network:example.net:switchB"> <nml:hasport nm:idRef="urn:ogf:network:example.net:switchB:port4-1:ingress"/> <nml:hasport nm:idRef="urn:ogf:network:example.net:switchB:port5-2:egress"/> <nml:hascrossconnect nm:idRef="urn:ogf:network:example.net:switchB:crossconnect4-1_5-2"/> </nml:node>
Again I have a similar question about your use of 'hasport' and 'hascrossconnect', is there a reason you need these? The prior examples we have discussed used the basic constructs of link/service/port/relation. An excerpt from the example I sent last week where we define a service/port then reference with the relation construct:
<nml:port id="urn:nml:internet2.edu:port_switch1_1" />
<nml:service id="urn:nml:internet2.edu:service_switch1_switchingservice" />
<nml:node id="urn:nml:internet2.edu:node_switch1"> <nml:relation type="provides"> <nml:service idRef="urn:nml:internet2.edu:service_switch1_switchingservice" /> </nml:relation> <nml:relation type="contains"> <nml:port idRef="urn:nml:internet2.edu:port_switch1_1" /> </nml:relation> </nml:node>
While I see you are still suggesting different namespaces for the attributes, I have not done this for the reasons I have outlined in other threads, the namespace of the attributes in my examples matches that of the surrounding elements.
<nml:node nm:id="urn:ogf:network:example.net:switchC"> <nml:hasport nm:idRef="urn:ogf:network:example.net:switchC:port6-2:ingress"/> </nml:node>
<nml:link type="link" nm:id="urn:ogf:network:example.net:segmentAB"> <nml:source nm:idRef="urn:ogf:network:example.net:switchA:port3-1:egress"/> <nml:sink nm:idRef="urn:ogf:network:example.net:switchB:port4-1:ingress"/> </nml:link>
I believe 'destination' was the term we have used in the past, but 'sink' is fine for now.
<nml:link type="crossconnect" nm:id="urn:ogf:network:example.net:crossconnect4-1_5-2"> <nml:source nm:idRef="urn:ogf:network:example.net:switchB:port4-1:ingress"/> <nml:sink nm:idRef="urn:ogf:network:example.net:switchB:port5-2:egress"/> </nml:link>
Can you re-explain what makes 'type=crossconnect' and 'type=link' necessary? I understand that this is old news for some, but I am still not sure of the distinction and why this is needed. Thanks; -jason
<nml:link type="link" nm:id="urn:ogf:network:example.net:segmentBC"> <nml:source nm:idRef="urn:ogf:network:example.net:switchB:port5-2:egress"/> <nml:sink nm:idRef="urn:ogf:network:example.net:switchC:port6-2:ingress"/> </nml:link>
<nml:link type="link" nm:id="urn:ogf:network:example.net:pathAC"> <nml:source nm:idRef="urn:ogf:network:example.net:switchA:port3-1:egress"/> <nml:sink nm:idRef="urn:ogf:network:example.net:switchC:port6-2:ingress"/> <nml:relation type="serialcompound" cl:count="3"> <nml:segment nm:idRef="urn:ogf:network:example.net:segmentAB" cl:order="1"/> <nml:segment nm:idRef="urn:ogf:network:example.net:crossconnect4-1_5-2" cl:order="2"/> <nml:segment nm:idRef="urn:ogf:network:example.net:segmentBC" cl:order="3"/> </nml:relation> </nml:link>
</nml:topology>