[Nml-wg] Serial compound relations

[Freek Dijkstra]

This post by Jason was blocked by the list. My apologies for not
handling this correctly.

-------- Original Message --------
From: Jason Zurawski <zurawski at internet2.edu>
Subject: Re: Serial compound relations
Date: Mon, 13 Dec 2010 16:59:48 +0100
To: Network Markup Language Working Group <nml-wg at ogf.org>
CC: Freek Dijkstra <Freek.Dijkstra at sara.nl>, Roman Łapacz
<romradz at man.poznan.pl>, Aaron Brown <aaron at internet2.edu>, Brian
Tierney <bltierney at es.net>, "Jeff W. Boote" <boote at internet2.edu>, Mark
Yampolskiy <myy at dfn.de>, Wolfgang Fritz <Wolfgang.Fritz at lrz.de>, Sandor
Rozsa <sandor.gyula.rozsa at cern.ch>, Ramiro Voicu <Ramiro.Voicu at cern.ch>,
Joe Metzger <metzger at es.net>, Michael Bischoff
<michael.bischoff at controplex.com>, Szymon Trocha
<szymon.trocha at man.poznan.pl>, Martin Swany <swany at UDel.Edu>, Guilherme
Fernandes <fernande at cis.udel.edu>, Jeroen van der Ham <vdham at 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>