December 2010 - nml-wg - lists.ogf.org

NML Examples repository
by Jeroen van der Ham 06 Jan '11

06 Jan '11

Hello, A new SVN repository has been created to work on NML examples: http://forge.ogf.org/svn/repos/nml-examples/ Jeroen.

2 2

Conf Call Today
by Jeroen van der Ham 16 Dec '10

16 Dec '10

Hi, Apologies for the late announcement, but we have another NML conference call today. Starting Time: Dec 2, 2010 at 11:00 AM, US/Eastern UTC 16:00 = EST 11:00 = 8:00 PDT = 17:00 CET To join both the web and audio conference (recommended), click here: https://edial.internet2.edu/call/0186145 If you only want to participate in the audio conference, you may dial in with the following numbers: Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0186145 Agenda: - Status of urn:ogf - Status of Informational Doc - List respresentation - Examples repository Copy of last action Items list: Action Items (Revised 2010-12-02) ================================= * Revise definition of multiplexing: Freek, Jeroen * Setup a teleconference: Jeroen * Specs for delegation of urn:ogf namespace: Freek, Richard, Joel Replogle * Specs for urn:ogf:network identifiers: Freek * Propose description of multicast and broadcast links: Richard, Freek, <need extra volunteer> * Create example of adaptation on Port/Link, and add to subversion: Jeroen, Jason * Given example of serial compound links with and without cross connect: Freek * How to specify properties of relations: <question postponed> * Give examples (with numbers and next) how to specify the order of XML elements: Aaron * Request NSI requirements/solutions for channels and labels: Freek * Jason will reserve the whiteboard facility at http://internet2.na6.acrobat.com/venus during NML calls

2 2

Re: [Nml-wg] Serial compound relations
by Freek Dijkstra 14 Dec '10

14 Dec '10

>> I choose some arbitrary names for some attributes; I'm happy to discuss >> that in another thread. I guess I should rename this thread to "other" ;) Jason Zurawski wrote: >> <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. I meant both to be a "nml:link" instance. My example is indeed confusing, and comes from my background in using RDF/XML. A better syntax proposal is indeed (note that nml:segment is replaced by nml:link, and nm:idRef is replaces by nm:id): <nml:link type="link" nm:id="urn:ogf:network:example.net:pathAC"> <nml:relation type="serialcompound" cl:type="partial"> <nml:link nm:id="urn:ogf:network:example.net:segmentAB"/> </nml:relation> </nml:link> In case you are curious why I created such a convoluted example, read on. (it's off-topic for the NML-WG though, and you may want to skip it) +------------------------------------------------+ | Link | +------------------------------------------------+ | id = urn:ogf:network:example.net:pathAC | | type = "link" | | ... | +------------------------------------------------+ | | | +------------------------------+ | | Relation | | +------------------------------+ |--| type = "serialcompound" | | | cl:type = "partial" | | | ... | | +------------------------------+ | | +------------------------------------------------+ | Link | +------------------------------------------------+ | id = urn:ogf:network:example.net:segmentAB | | ... | +------------------------------------------------+ In RDF, only objects can have properties. properties can not. So if I want to describe the above, I need to make both Links and Relations an object. The relation between two objects is always with a named attribute, so for RDF, one needs to create for the relation between a Link and a Relation object, and between a Relation and Link object, as in: <nml:Link rdf:about="urn:ogf:network:example.net:pathAC"> <nml:linktype>link</nml:linktype> <nml:hasrelation>  <nml:Relation> <nml:relationtype>serialcompound</nml:relationtype> <cl:type>partial</cl:type> <nml:segment rdf:resource="urn:ogf:network:example.net:segmentAB"/> </nml:Relation> </nml:hasrelation> </nml:Link> (observe that rdf:about is the same as nm:id, and rdf:resource is the same as nm:idRef) In XML, this can be a lot shorter, so I picked XML for brevity, but indeed forget to use the object name (nml:Link) instead of the made-up attributed name (nml:segemnt). Sorry for the confusion, Freek

6 11

Re: [Nml-wg] Serial compound relations
by Roman Łapacz 14 Dec '10

14 Dec '10

W dniu 2010-12-13 16:59, Jason Zurawski pisze: > > > 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 see the reason of different namespace if we would like to have extra attribute for ordering. But for 'id' and 'idRef' attributes I don't seee the need for different namespace. > 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. The type 'link' could be default one so it wouldn't be necessary to have it explicitly. Cheers, Roman

1 0

Re: [Nml-wg] Serial compound relations
by Freek Dijkstra 13 Dec '10

13 Dec '10

This post by Jason was blocked by the list. My apologies for not handling this correctly. -------- Original Message -------- From: Jason Zurawski <zurawski(a)internet2.edu> Subject: Re: Serial compound relations Date: Mon, 13 Dec 2010 16:59:48 +0100 To: Network Markup Language Working Group <nml-wg(a)ogf.org> CC: Freek Dijkstra <Freek.Dijkstra(a)sara.nl>, Roman Łapacz <romradz(a)man.poznan.pl>, Aaron Brown <aaron(a)internet2.edu>, Brian Tierney <bltierney(a)es.net>, "Jeff W. Boote" <boote(a)internet2.edu>, Mark Yampolskiy <myy(a)dfn.de>, Wolfgang Fritz <Wolfgang.Fritz(a)lrz.de>, Sandor Rozsa <sandor.gyula.rozsa(a)cern.ch>, Ramiro Voicu <Ramiro.Voicu(a)cern.ch>, Joe Metzger <metzger(a)es.net>, Michael Bischoff <michael.bischoff(a)controplex.com>, Szymon Trocha <szymon.trocha(a)man.poznan.pl>, Martin Swany <swany(a)UDel.Edu>, Guilherme Fernandes <fernande(a)cis.udel.edu>, Jeroen van der Ham <vdham(a)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">  <relation type="serialcompound">  <link id="_ab" idRef="ab">  <relation type="nextHop"> <link idRef="_bc"> </relation> </link> <link id="_bc" idRef="bc"> <relation type="nextHop"> <link idRef="_cd"> </relation> </link>  <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. >  >  > > | > 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/"> > >  > > <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>

1 0

Serial compound relations
by Freek Dijkstra 10 Dec '10

10 Dec '10

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> 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. Regards, Freek

1 0

xml list examples
by Aaron Brown 09 Dec '10

09 Dec '10

On the call, I was asked to send some examples of how we've done ordered lists in XML before. Looking through various xml bits, I found a few different ways that we've sorted lists. 1) a numerical 'id' element: <nmwg-cp:hop id=”0”> .... </nmwg-cp:hop> <nmwg-cp:hop id=”1”> .... </nmwg-cp:hop> <nmwg-cp:hop id=”2”> .... </nmwg-cp:hop> <nmwg-cp:hop id=”3”> .... </nmwg-cp:hop> 2) explicit 'next' pointers: <path> <hop id="internet2-1"> .... <nextHop>esnet-1</nextHop> </hop> <hop id="esnet-1"> .... <nextHop>bnl-1</nextHop> </hop> <hop id="bnl-1"> .... </hop> </path> 3) implicit document ordering (this data corresponds to a traceroute. there would be more 'datum' elements in a real traceroute instance each of which corresponds to a single traceroute probe sent. This was cleaned up to make it easier to read): <nmwg:data id="data.AAAFFF.0" metadataIdRef="meta.AAAFFF" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"> <traceroute:datum hop="198.129.254.29" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="1" value="0.135" valueUnits="ms"/> <traceroute:datum hop="134.55.219.10" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="2" value="1.14" valueUnits="ms"/> <traceroute:datum hop="134.55.217.2" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="3" value="37.212" valueUnits="ms"/> <traceroute:datum hop="134.55.209.98" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="4" value="1.616" valueUnits="ms"/> <traceroute:datum hop="134.55.220.49" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="5" value="28.643" valueUnits="ms"/> <traceroute:datum hop="134.55.209.46" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="6" value="41.773" valueUnits="ms"/> <traceroute:datum hop="134.55.221.58" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="7" value="52.36" valueUnits="ms"/> <traceroute:datum hop="134.55.218.101" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="8" value="52.373" valueUnits="ms"/> <traceroute:datum hop="198.124.252.141" numBytes="64" queryNum="1" timeType="unix" timeValue="1282079154" ttl="9" value="52.311" valueUnits="ms"/> </nmwg:data> Cheers, Aaron

7 13

Path vs Link
by Roman Łapacz 04 Dec '10

04 Dec '10

Hi, apologize if you already discussed it or it's a silly question. I'm analysing the UML diagram in nml-base pdf doc and comparing Link and Path elements. If I'm not wrong it was said that the set of existing elements should be minimal as much as possible (reusable elements). Following this general rule I'm thinking that Link could be used instead of Path. Now I'm thinking about the case of circuit. Example: there may be 3 domains so we have 3 types of view: high (a path/circuit), medium (a link representing aggregated connection in a domain), low (links inside a domain). Can path be just a link with end nodes representing ends of circuits? regards, Roman

3 3

Meeting notes conf call 2010-12-02
by Freek Dijkstra 02 Dec '10

02 Dec '10

Conference call Thu December 2, 2010 Participants: ============= Aaron Brown - I2 Freek Dijkstra - SARA Chin Guok - ESnet Jeroen vd Ham - U Amsterdam Marcos Portnoi - U Delaware Guy Roberts - DANTE Jason Zurawski - I2 Inder Monga - ESnet Agenda: ======= - Tasklist as decided on OGF30 - Announcements on Geant3 (Freek) - Status of urn:ogf - VLAN description volunteers? - Go through the 5 questions on identifiers - Test some whiteboard software Action Items (Revised 2010-12-02) ================================= * Revise definition of multiplexing: Freek, Jeroen * Setup a teleconference: Jeroen * Specs for delegation of urn:ogf namespace: Freek, Richard, Joel Replogle * Specs for urn:ogf:network identifiers: Freek * Propose description of multicast and broadcast links: Richard, Freek, <need extra volunteer> * Create example of adaptation on Port/Link, and add to subversion: Jeroen, Jason * Given example of serial compound links with and without cross connect: Freek * How to specify properties of relations: <question postponed> * Give examples (with numbers and next) how to specify the order of XML elements: Aaron * Request NSI requirements/solutions for channels and labels: Freek * Jason will reserve the whiteboard facility at http://internet2.na6.acrobat.com/venus during NML calls Notes ===== VLANs: Freek has some ideas how to describe VLANs, but needs volunteers to help think about it (hard is to define the logic and scalability.) Guy: NSI is only point-to-point VLANs needed for AutoBAHN cNIS interpretation: does not touch on multi-point to multipoint Adaptation on Port/Link: Jason and Jeroen created examples. Jeroen needs some more iterations Jason: we will add the examples to the nml-base repository, for new example document. GFD publication process: Jeroen - frustrated with information document publication process. took long for public comments, no public comments, period ended but no action. Guy has the same experience Guy advises to apply pressure to Joel and Greg, with him and Richard Hughes-Jones on the cc. Joel Replogle is administrative responsible (assigning GFD numbers, website, etc.) Greg Newby is responsible for reviews and document contents. Subversion: A commit message to the mailing list is considered useful Ordering in XML/RDF: Three options: - use document order (not in XML spec, so not always reliable) - add order number to elements - refer to "next" element Channels: The question is how to use describe multiple labels to make NML more scalable. Eg. how to describe 4000 VLANs between two domain, without actually describing 4000 links and 2*4000 ports. Guy: NSI Distinguishes between capability and configuration. For capability, NSI advertises range of VLANs on a port, labels For configuration, NSI advertises SDP/STP for each VLAN. Concept of capability: format as list or range Concept of circuits: format as SDP. Physical instance can have multiple potential "SDPs" Tomohiro mailed Freek a slide deck of ~20 slides, but this needs to be condensed into clear requirements. Freek will formally mail the NSI list requesting input. GEANT3: GEANT really wants the NML work and expects to provide more input (SA2 and JRA2). Current discussion is who is going to provide this input and how. Richard, Guy and Freek think that it best to make two people active in the NML-WG, rather than making a working group in the GEANT3 project, which will make a requirement document and sent that the NML-WG. According to Freek, that is too late in the process, the scope and requirements are there, we're now fine-tuning the schema, making sure it will be useful. Questions on Identifiers: No more feedback than what was already given by Jeroen and Jason. Adobe whiteboard software: Works pretty good. Can be used for technical discussions. Jason will reserve it for NML calls.

1 0

NMC vs NML Call times
by Jason Zurawski 02 Dec '10

02 Dec '10

NMC is scheduled to meet on Dec 9th, and then probably not again till Jan 6th. NMC will alternate every other week if you use Dec 9th as a starting point. It would be great if NML could use the week in between, this should allow people who would attend one to hopefully start attending the other :) Thanks; -jason

1 0