May 2012 - nml-wg - lists.ogf.org

Relations in NML
by Jeroen van der Ham 21 Jun '12

21 Jun '12

Hi all, I've tried to list all relations that I've seen so far in NML that we've made a decision on and have used. I came to the list below, let's discuss it in the call. Jeroen. <Topology|Node> hasNode <Node> <Topology> hasTopology <Topology> <NE> hasService <Service> <Node> hasInboundPort <Port> <Node< hasOutboundPort <Port> <Port> isSink <Link> <Port> isSource <Link> <Link> isSerialCompound <Group> <Node> locatedAt <Location> <Node> implementedBy <Node> Grouping is done slightly differently in XML and RDF: Grouping in XML: Containment for elements. Ordering: <NE> next <NE> Grouping in RDF: <Group> contains <NE> Ordered group is done using extra ListItem objects: <ListItem> item <NE> <ListItem> next <ListItem> Jeroen.

3 5

Next NML conf call May 31
by Freek Dijkstra 31 May '12

31 May '12

Today is a public holiday in the Netherlands (Ascension Day), and next week is the Terena Networking Conference. We had some good discussions on the list, but I nevertheless propose to hold the next conf call on Thursday May 31. Freek

3 2

Two proposals for Adaptation
by Freek Dijkstra 29 May '12

29 May '12

Here are two proposals how to describe adaptation (encoding of a client layer Port in a server layer Port). Option 1: As adaptation service. (similar to a switching service) ----------------------------------------------------------------- egress server layer Port --(hasService)--> adaptation Service adaptation Service --(providesPort)--> egress client layer Port* ingress server layer Port --(hasService)--> de-adaptation Service de-adaptation Service --(providesPort)--> ingress client layer Port* Option 2: As Adaptation or DeAdaptation object (similar to a Link) ------------------------------------------------------------------ egress client layer Port* --(isSource)--> Adaptation egress server layer Port --(isSink)--> Adaptation ingress server layer Port --(isSource)--> DeAdaptation ingress client layer Port* --(isSink)--> DeAdaptation *Port or PortGroup, if we decide to allow descriptions of multiple Ports -eg. all VLANs- as a group for efficiency purposes. Option 1 is more natural choice for dynamic adaptations, e.g. VLANs in Ethernet. Option 2 is more natural choice for static adaptations, e.g. Ethernet over a wavelength. We can even allow both: option 1 for dynamic adaptations, and option 2 for static adaptations. But I rather just pick one of the two. Please let me know your preference, or alternative proposal. Feedback can also be made at https://forge.ogf.org/sf/go/artf6514 XML examples follows. Sorry for the quoting, otherwise my mail client would have wrapped the lines. If you like the raw XML, you can get it at https://forge.ogf.org/svn/repos/nml-examples/201205-adaptation/adaptation.x… and are copied below. XML example option 1 (as Service) --------------------------------- (example taken from nml-examples/201109-switchservice/2vlans_option2.xml) egress server layer Port --(hasService)--> adaptation Service adaptation Service --(providesPort)--> egress client layer Port ingress server layer Port --(hasService)--> de-adaptation Service de-adaptation Service --(providesPort)--> ingress client layer Port > >  > <nml:Port id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_out"> > <nml:name>ge-6/0/0 out</nml:name> > <nml:capacity units="bps">10000000000</nml:capacity> > <nml:Relation type="hasService"> > <nml:Service idRef="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_out_adaptation" /> > </nml:Relation> > </nml:Port> > >  > <nml:Service type="adaptation" id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_out_adaptation"> > <nml:name>VLAN adaptation service</nml:name> > <nml:adptationFunction>IEEE-802.1q</nml:adptationFunction> > <nml:Relation type="providesPort"> > <nml:Port idRef="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0.42_out" /> > </nml:Relation> > </nml:Service> > >  > <nml:Port id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_in"> > <nml:name>ge-6/0/0 in</nml:name> > <nml:capacity units="bps">10000000000</nml:capacity> > <nml:Relation type="hasService"> > <nml:Service idRef="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_in_deadaptation" /> > </nml:Relation> > </nml:Port> > >  > <nml:Service type="deadaptation" id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_in_deadaptation"> > <nml:name>deadaptation service</nml:name> > <nml:adptationFunction>IEEE-802.1q</nml:adptationFunction> > <nml:Relation type="providesPort"> > <nml:Port idRef="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0.42_in" /> > </nml:Relation> > </nml:Service> XML example option 2 (as Adaptation object) ------------------------------------------- egress client layer Port --(isSource)--> Adaptation egress server layer Port --(isSink)--> Adaptation ingress server layer Port --(isSource)--> DeAdaptation ingress client layer Port --(isSink)--> DeAdaptation >  > <nml:Port id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_out"> > <nml:name>ge-6/0/0 out</nml:name> > <nml:capacity units="bps">10000000000</nml:capacity> > <nml:Relation type="isSink"> > <nml:Service idRef="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_out_adaptation" /> > </nml:Relation> > </nml:Port> > >  > <nml:Port id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0.42_out"> > <nml:Relation type="isSource"> > <nml:Service idRef="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_out_adaptation" /> > </nml:Relation> > </nml:Port> > >  > <nml:Service type="adaptation" id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_out_adaptation"> > <nml:name>VLAN adaptation service</nml:name> > <nml:adptationFunction>IEEE-802.1q</nml:adptationFunction> > </nml:Service> > >  > <nml:Port id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_in"> > <nml:name>ge-6/0/0 in</nml:name> > <nml:capacity units="bps">10000000000</nml:capacity> > <nml:Relation type="isSource"> > <nml:Service idRef="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_in_deadaptation" /> > </nml:Relation> > </nml:Port> > >  > <nml:Port id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0.42_in"> > <nml:Relation type="isSink"> > <nml:Service idRef="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_in_deadaptation" /> > </nml:Relation> > </nml:Port> > >  > <nml:Service type="deadaptation" id="urn:ogf:network:internet2.edu:rtr.atla.net:ge-6-0-0_in_deadaptation"> > <nml:name>deadaptation service</nml:name> > <nml:adptationFunction>IEEE-802.1q</nml:adptationFunction> > </nml:Service>

3 4

OGF 35
by Freek Dijkstra 17 May '12

17 May '12

I invite all NML members to register for OGF 35 in Delft, the Netherlands. Please note the somewhat unusual days: Sunday June 17 to Tuesday June 19, with NML sessions on Sunday. There are two plugfests before the OGF, one for OCCI and one for other OGF protocols, both in Amsterdam. If you have interest in joining these plugfests, please let me know. I have not made specific plans, but would not mind spending a few days making some progress. Regards, Freek

1 0

Labels
by Roman Łapacz 14 May '12

14 May '12

Hi, the final proposal how the labels could look like is as follows (RNC format): Label = element nml:label { element nml:parameter { attribute name { "type" }& text }& ( element nml:parameter { attribute name { text }& text } + ) | anyElement+ } + ### taken from nmc base schema anyElement = element * {anyThing } anyAttribute = attribute * { text } anyThing = ( anyElement | anyAttribute | text )* an example: <nml:label> <nml:parameter name="type">c-vlan</nml:parameter> <nml:parameter name="value>42</nml:parameter> </nml:label> <nml:label> <nml:parameter name="type">wavelength</nml:parameter> <nml:parameter name="unit">nm</nml:parameter> <nml:parameter name="spacing">25GHz</nml:parameter> <nml:parameter name="value">1500</nml:parameter> </nml:label> By default, other nemaspaces than nml basic one are not needed but I would not forbid them. Use of a set of nml:parameter elements (flat structure) seems to be enough flexible to cover almost all possible cases but I can imagine a very rare requirement to have a nested structure inside nml:label, for example: <nml:label> <nml:paremeter name="type">xyz</nml:parameter> <nml-ext:something_1> <nml-ext:something_2> ... </nml-ext:something_2> </nml-ext:something_1> </nml:label> (that is why I've added anyElement in the RNC snippet) If you are 100% sure that such a requirement will not come up I'm fine to remove this extension possibility. Roman

4 5

Adaptation between Links
by Freek Dijkstra 10 May '12

10 May '12

I've just created a new artifact, https://forge.ogf.org/sf/go/artf6507 Here is the full proposal. Adaptation is between Ports, and requires the following objects: * 2 Link instances * 4 Port instances * 2 Adaptation instances * 8 relations between these instances (see https://forge.ogf.org/sf/go/artf6514 for details) While the above is great to describe a topology in detail, it is sometimes useful to describe less detail. I propose a shortcut to define adaptation between Links: Link --(providesLink)--> Link This would only require the following objects: * 2 Link instances * 1 relation between these instances This is similar how isSerialCompoundLink also relates Link objects, bypassing the more tedious Link <--(isSink)-- Port --(isSource)--> Link relations. Of course this is less detailed (e.g. it is not possible to describe the type or adaptation, or the name of the Ports). It's intended use is a situations where a full topology description (with all ports) is not required or not desirable. NML: Link --(providesLink)--> Link The subject (Link on the left) is on the server layer. The link of the right (the object) is one the client layer, and source and sinks of both Links MUST be related with an equal adaptation stack. In other words, both Links MUST span the same distance. For example, in the following ASCII-art, the following statements are True: l0 --(providesLink)--> l1 - True l0 --(providesLink)--> l2-2 - True l1 --(providesLink)--> l2-2 - True While the following statements are all False: l0 --(providesLink)--> l3 - False l1 --(providesLink)--> l3 - False l2-2 --(providesLink)--> l3 - False l3 O -----------------------------------------------> O | | _ _ V V | l2-1 l2-2 l2-3 | O -------------> O -------------> O -------------> O | | _ _ V V | l1 | O -------------> O | | _ _ V V | l0 | O -------------> O >From these requirements follows that the subject is always a terminated network connection (thus not a segment of a larger link connections), while the object is never a serial compound link. XML example: <nml:Link id="urn:ogf:network:example.net:2012:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm"> <nml:name>1530nm wave between NOR and AMS</nml:name> <nml:Relation type="providesLink"> <nml:Port idRef="urn:ogf:network:example.net:2012:link:eth:NOR-AMS-0001" /> </nml:Relation> </nml:Service> RDF example: @prefix nml: <http://example.ogf.org/schemas/nml/>; . @prefix nmlrel: <http://example.ogf.org/schemas/nml-relation/>; . @prefix ex: <urn:ogf:network:example.net:2012> . ex:link:fiber:NOR:xe-1-1-0:AMS:xe-2-1-0:1530nm a nml:Link ; nml:name "1530nm wave between NOR and AMS" ; nmlrel:providesLink ex:link:eth:NOR-AMS-0001 .

4 5

Extensability (was: Labels)
by Freek Dijkstra 10 May '12

10 May '12

Roman Łapacz wrote an example of his label proposal: > <nml:label> > <nml:parameter name="type">c-vlan</nml:parameter> > <nml:parameter name="value>42</nml:parameter> > </nml:label> > > > By default, other namespaces than nml basic one are not needed but I > would not forbid them. Use of a set of nml:parameter elements (flat > structure) seems to be enough flexible to cover almost all possible > cases but I can imagine a very rare requirement to have a nested > structure inside nml:label, for example: > > <nml:label> > <nml:paremeter name="type">xyz</nml:parameter> > <nml-ext:something_1> > <nml-ext:something_2> > ... > </nml-ext:something_2> > </nml-ext:something_1> > </nml:label> > > (that is why I've added anyElement in the RNC snippet) > > If you are 100% sure that such a requirement will not come up I'm fine > to remove this extension possibility. My question to all: how to we want NML to be extensible? In this particular use case I'm pretty confident that if we extend NML as in the above example, all parsers need to be rewritten/modified, and we will make this a "NML version 2" including the required change in (URL of) the NML base schema. Hence, this extensibility is not required for this NML version 1. That said, I can imagine that someone will interweave third-part XML constructs. E.g., some software may add some policy attributes: > <nml:label> > <nml:paremeter name="type">xyz</nml:parameter> > <myauth:policy> > <myauth:user>PSNC</myauth:user> > <myauth:permission>allow-all-labels</myauth:permission> > </myauth:policy> > </nml:label> Specific questions: 1. Should we allow/support interweaving of third-part XML constructs in NML, or explicitly restrict/forbid that? 2. We now define keywords for: - relation type <nml:Relation type="*"> - label parameter name <nml:parameter name="*"> - label type <nml:label><nml:parameter name="type">*</nml:parameter></nml:label> - service type <nml:Service type="*"> - adaptation type (not defined in syntax yet) These are clear and well-defined extensions, which is good. My question: would these extensions require a OGF standards action? Since none of these contain a namespace, a third party can not create them without the risk of a name-conflict. - I don't think this will stop 3rd parties, leading to potential name conflicts - It requires the OGF to define a document for each technology (each label and each adaptation). Is this what we want? Freek

2 2

OGF 35
by Freek Dijkstra 10 May '12

10 May '12

Roman Łapacz wrote: > I see that NML has 3 sessions scheduled on 17.05. I'd like to confirm > that I'll be there (I've just starting arrange the trip). > > http://ogf.org/gf/event_schedule/index.php?event_id=24 Great! Do you plan to also attend the plugfest prior to and/or HPDC'12 after OGF? (see mail of Alan Sils yesterday) I was just looking at it on Tuesday, but haven't made up my mind if I should attend HPDC'12 or not. It seems I need separate registration which is rather expensive. Freek

2 1

NML Call May 10rd
by Freek Dijkstra 09 May '12

09 May '12

For next week, neither me nor Jeroen is available at the regular time slot. Would it be possible to have a short call at: UTC 18:00 - CEST 20:00 - Eastern 14:00 - Pacific 11:00 Aaron or Jason, would the following still work, or do we need another access code? 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 Thanks, Freek

3 5

Labels (was: Notes from NML call on May 3)
by Freek Dijkstra 04 May '12

04 May '12

Jeroen van der Ham wrote: > - Label proposal from Roman on the list describes the outcome of the discussion last week. > Freek notes that we should only allow one label per port. In the call I mentioned one exception: source and destination address. But I have some good hope that this is not an issue. In G.800 terms, this seems a different thing. What we're talking about is a "resource label", used in multiplexing adaptation and channels in links. "Source and destination labels" are apparently used for termination, and thus something else (for those interested: Section 6.7.1.1 of G.800, but also section 7 and 8 -- in particular Figure 18). Also, I was briefly worried that VRFs would complicate things when describing IP addresses as labels. Historically, routers routed based on destination IP address only. Most modern routers support VRFs, which -I thought- routed based on source and destination IP address. Turns out I was wrong: they route based on destination IP address and source *port*, which -I think- can be described in current NML using multiple Switching Services. > This makes it possible to described configured networks very well. The motivation for the one-label limitation is mostly simplicity. Multiple labels might be possible, but complicates things (e.g. do we need to specify order?; can there be a stack of labels, isn't that the same as adaptations, and if so-how to related which label to which layer, etc. I rather avoid these questions for now). If this is too strict, we can extend things later. Regards, Freek

1 0