[Nml-wg] Serial compound relations
Freek Dijkstra
Freek.Dijkstra at sara.nl
Mon Dec 13 10:58:26 CST 2010
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>
More information about the nml-wg
mailing list