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

New schema
by Freek Dijkstra 09 Jul '12

09 Jul '12

I've just updated the schema to include PortGroups and LinkGroups and list all relations that Jeroen recently send out to the list. https://forge.ogf.org/sf/go/doc15481 Note that per UML standards, all abstract classes are now in italics. The source document can be found in the Subversion repository. I also added a schema that detailed the Relations as opposed to the class hierarchy. https://forge.ogf.org/svn/repos/nml-base/sources/NML-schema.graffle https://forge.ogf.org/svn/repos/nml-base/NML-schema.pdf https://forge.ogf.org/svn/repos/nml-base/NML-relations.pdf Feedback is most appreciated (did I forget something, are there any errors or omissions?) Regards, Freek

1 1

Extensibility
by Freek Dijkstra 06 Jul '12

06 Jul '12

At the call earlier today we shortly discussed how to deal with future extensibility of NML. Let me give two practical examples: 1) Topologies may change over time, and the "version" attributed is used as a serial number to distinguish between updates in the Topology description (akin to the serial number in DNS SOA records). Currently this version attribute is only allowed for Topologies; allowing it for each network object may complicate change management more than needed. However, we can envision a situation where a future NML version would allow this use. 2) the "hasTopology" relation is only allowed between two Topologies, but perhaps in the future NMLv2 allow it from a Service to a Topology. We hope that the following will work: * The schema (UML schema, RDF schema and XML schema) will be "loose": they will liberally allow all sorts of extensions. In the above examples, the version attribute can be part of all Network Objects, and hasTopology may relate any Network Object to a Topology. * In the text, we will add further restrictions about the behaviour of NML version 1 compliant agents. In the above examples, a NMLv1 generator SHOULD NOT add version attributes to non-Topology network objects; a NMLv1 parser SHOULD ignore version attributes for non-Topology network objects; the meaning of the "hasTopology" relation between a Service and a Topology is undefined, and SHOULD be ignored by NMLv1 parsers. * Specific application may pose further restrictions on the NML descriptions that are generated and parsed. For example, NSI may impose restrictions how a STP is described in NML. Is this a useful way forward that both allows extensibility, without allowing too many variations (and thus interoperability) of NML? Regards, Freek

2 2

Re: [Nml-wg] Label sets
by Jason Zurawski 28 Jun '12

28 Jun '12

On 6/28/12 10:47 AM, thus spake Jeroen van der Ham: > On 28 Jun 2012, at 16:17, Jason Zurawski wrote: > >> Option 2 is how OSCARS currently works today, and I believe it works well. I would vote to go with that for 'ease of implementation' :) > > Good to hear! > Can you describe the syntax constraints that OSCARS uses? What do I look like, a programmer :) Aaron or Andy may be able to. I believe the comma and dash are popular and expected as I look at examples: > <vlanRangeAvailability>3800-3809</vlanRangeAvailability> -jason

4 5

is alias
by Freek Dijkstra 28 Jun '12

28 Jun '12

FYI, at the conference call today we decide to rename the "alias" relation to "isalias" per https://forge.ogf.org/sf/go/artf6538 Freek (PS: sorry to spam your mailbox like this, I'm just trying to make sure that everything that is discussed at conferences or calls is replicated on the list, as per policy http://www.ogf.org/pipermail/nml-wg/2009-June/000270.html)

1 0

Conference call Thu June 28
by Freek Dijkstra 28 Jun '12

28 Jun '12

Hi all, We have a call today at the usual time and place: UTC 15:00 - CEST 17:00 - Eastern 11:00 - Pacific 8:00 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: - Notes on OGF35 - NSI integration - Progress on action items Note that we will not have a call next week; the next scheduled call after June 28 is at July 12. Freek

2 1

Label sets
by Freek Dijkstra 28 Jun '12

28 Jun '12

The PortGroup and LinkGroup concepts require a "set of labels" concept. E.g. "VLAN 8,42,100-119". Here are two proposals how to represent this. Please pick one (personal preference, XML/RDF-fetish, or throwing a dice are valid selection mechanisms for today). Option 1. ========= XML: <nml:PortGroup id="urn:ogf:network:example.net:2010:mytrunk"> <nml:label> <nml:parameter name="type">vlan</nml:parameter> <nml:parameter name="set"> <nml:parameter name="value">8</nml:parameter> <nml:parameter name="value">42</nml:parameter> <nml:paramater name="range"> <nml:paramater name="start">100</nml:paramater> <nml:paramater name="end">119</nml:paramater> </nml:paramater> </nml:parameter> </nml:label> </nml:PortGroup> RDF: @prefix ex: <urn:ogf:network:example.net:2010> . @prefix nml: <http://example.ogf.org/schemas/nml/base/201303/> . @prefix nmlparam: <http://example.ogf.org/schemas/nml/param/201303/> . ex:mytrunk a nml:PortGroup . ex:mytrunk nml:label #12345678 . #12345678 nmlparam:type "vlan" . #12345678 nmlparam:set #9876543 . #9876543 nmlparam:value "8" . #9876543 nmlparam:value "42" . #9876543 nmlparam:range #asdfghj . #asdfghj nmlparam:start "100" . #asdfghj nmlparam:start "119" . Option 2. ========= XML: <nml:PortGroup id="urn:ogf:network:example.net:2010:mytrunk"> <nml:label> <nml:parameter name="type">vlan</nml:parameter> <nml:parameter name="values">8,42,100-119</nml:paramater> </nml:label> </nml:PortGroup> RDF: @prefix ex: <urn:ogf:network:example.net:2010> . @prefix nml: <http://example.ogf.org/schemas/nml/base/201303/> . @prefix nmlparam: <http://example.ogf.org/schemas/nml/param/201303/> . ex:mytrunk a nml:PortGroup . ex:mytrunk nml:label #12345678 . #12345678 nmlparam:type "vlan" . #12345678 nmlparam:values "8,42,100-119" . Thanks, Freek

4 3

Fwd: [callforparticipants] TIP2013: Call for Participation
by Jerry Sobieski 27 Jun '12

27 Jun '12

hi all - sorry to spam everyone... I think NSI, NML, and AutoGOLE projects - since they are related and form an important component for much future global virtualization work - ought to make a substantive showing here. These three technologies will have made substantial progress and demos over this fall, and will be seeing considerable global deployment in both experimental and early production environments in the spring of 2013, so we need to be presenting the engineering/deployment issues to this community. NORDUnet will be providing workshops on these programs internally to the Nordic community this fall... perhaps we could offer such a workshop at TIP as well.... Thoughts? Jerry -------- Original Message -------- Subject: [callforparticipants] TIP2013: Call for Participation Date: Wed, 27 Jun 2012 11:08:23 -0400 From: Stephen Wolff <swolffadmin(a)internet2.edu> To: callforparticipants(a)internet2.edu, jtjan08(a)internet2.edu, tony(a)cenic.org Colleagues, Once again, the APAN <http://apan.net/> and Joint Techs <http://www.internet2.edu/jt/> meetings will converge in Honolulu to form the *Techs in Paradise (TIP) 2013 <http://events.internet2.edu/2013/tip/>*conference, hosted by the University of Hawaii <http://www.uhm.hawaii.edu/>. By bringing these meetings together into one location, TIP 2013 encourages greater global dialogue, facilitates technical collaboration across the Pacific and provides an important discussion forum for issues of concern to R&E network stakeholders in this region of the world. The meeting will take place from January 13 – 16, 2013. To ensure a dynamic and thought-provoking program, planning is already underway. We are currently inviting abstract proposals for: a) full or "lightning round" presentations, b) tutorials (90-minute, 1/2-day and full-day), c) lunchtime meetings (SIGs, BoFs and Working Groups), d) posters and e) co-located meetings and workshops. TIP2013 will include two (2) concurrent netcast sessions and, if possible, a third (smaller non-taped) session to increase the number of talks, papers, posters, and side meetings available and expand the opportunities for dialogue across the communities. The following topics have been identified as being of particular interest, although proposals in other areas relating to research and education networking are also invited: *Network Research and Emerging Technologies* (including Software Defined Networking / OpenFlow; Security in R&E Networking; Network Performance and Measurement; and "Future Internet") *Network Architecture and Operations* (including 100G implementation experiences; IPv6; Network performance and utilization; R&E network infrastructure and connectivity updates; and Pacific Islands connectivity) *R&E Network Applications* (including Astronomy; Ocean observatories; Climate and environment; Disaster management; e-Medicine and e-Health; e-Culture and performance; Global collaboration; and e-Learning) Please submit your abstract for review by *September 14, 2012* using the link at http://events.internet2.edu/2013/tip/focus-areas.cfm. Abstracts must include collaborators or intended demonstrations. Submissions will be judged by a formal program committee process based on relevance to posted focus areas and audience areas of interest. *Registration* for TIP2013 will be announced in Septmber; information on the *conference hotel* will be announced as soon as it is posted. If you have any questions, please do not hesitate to email tip2013-questions(a)internet2.edu <mailto:tip2013-questions@internet2.edu> or visit the meeting website at: http://events.internet2.edu/2013/tip/ We look forward to hearing from you! /Jacqueline Brown /(APAN),/Inder Monga/ (ESnet), and /Steve Wolff /(Internet2) on behalf of the TIP2013 Program Committee

2 1

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

Notes on NML sessions at OGF 35
by Freek Dijkstra 21 Jun '12

21 Jun '12

Hi all, Below are some highlights of OGF 35. I'm sure there are still some questions, and I hope I can explain them in more detail in the coming weeks. Note that we have a busy schedule this summer, especially now that NSI has agreed to use NML, and they are implementing NSI v2 in Q3. Action Items ============ The following two call data are agreed: * June 28 * July 12 Actions and deadlines: July 3: Jeroen: update on section 2 base document Freek: urn:ogf:network document Freek: NML example for NSI AutoGOLE July 10: Add 2 examples to section 4 (Roman) identifier section (Freek) July 24: XML schema 1st draft (Roman) RDF schema 1st draft (Jeroen) Improvement on section 2 (Freek) NSI-NML Collaboration ===================== * NSI decided to use NML topology descriptions instead of their custom NSNetwork/STP descriptions. They in particular need PortGroups and alias relations. * NSI plans to release version 2 in Q3, so the NML features used by NSI MUST be ready over summer. * Jeroen gave a presentation to the NML and NSI groups on how to uniquely identify a Port within a PortGroup by using the PortGroup URI + a query component. (instead of using the URI of the individual Port). See https://forge.ogf.org/sf/go/doc16453 Schema Proposals ================ * Freek created two hand-written example files: https://forge.ogf.org/svn/repos/nml-examples/201206-lhcopn/ No proper (fully written out) proposal were created, but multiple issues have been discussed. * Addition of the PortGroup and LinkGroup (as Groups) Agreed: consensus by OGF participants. Like to see a generic Group concept instead of separate LinkGroup and PortGroup, but for now the distinction is made so it is easy to distinguish between a Group of Ports and a Group of Links. Suggestions for change are welcome. * Use case: NodeGroup Jerry will create a use case to group Nodes. * Use case: group nodes where other parameters but label is varied. In the proposal, a PortGroup is a group of Ports which can be distinguished by their label. It is desirable to be more flexible: group Ports where other parameters change, and even PortGroups whose ports can be distinguished by multiple labels (e.g. "all VLANs in all wavelengths of port 1/5/4") * Description of label ranges in PortGroups/LinkGroups -> with nml:label with set parameter (instead of nml:label with value parameter). Syntax need refinement. Proposal is needed. * Already allowed: Port --(isSource|isSink)--> Link Also allow: PortGroup --(isSource|isSink)--> LinkGroup -> Only allowed if labels are the same in both group -> ports and links in these groups are associated by having the same label -> The following relations are not yet allowed, because it is yet unclear what their meaning is: Port --(isSource|isSink)--> LinkGroup PortGroup --(isSource|isSink)--> Link * Already allowed: Node --(isOutboundPort|isInboundPort)--> Port Also allow Node --(isOutboundPort|isInboundPort)--> PortGroup -> Allowed. * Definition of the properties: name, encoding, label, capacity, mtu, one-way-latency (last one for links only) -> Encoding property is useful, akin to GMPLS to specify the type of Port (e.g. Ethernet VLAN Port, MAC Port, Wavelength Port, etc.) -> There is no clear definition of MTU and capacity. MTU and PDU often gets mixed up. Capacity can mean the link capacity, or the maximum achievable bandwidth. Eg. 1 Gbit/s Ethernet carries 1.25 Gbaud with 4/5 encoding, but due to interframe gap, preamble, header, CRC and footer the effective bandwidth is only 0.941482 Mbit/s. http://sd.wareonearth.com/~phil/net/overhead/. This depends on MTU. -> The NML base schema will only define name, encoding and label. -> capacity, MTU and latency may be defined in an extension later. * Domain and Network groups are not used, and will be removed from the NML base schema. NSI should define domains (e.g. NSA). NML will only define Topology. Issues such as delegation of control are out of scope of the NML version 1. * Topology and Node are basically the same thing -> There are simularties (both represent a virtual/abstracted node with the notion that its ports can be connected by a cross-connect), but we will keep both concepts for clarity. * implementedBy and hasTopology are inverse relations, so we can remove implementedBy. -> No. hasTopology represents topology abstraction, with implementedBy represents partitioning or virtualization. We will keep both relations. * Freek proposes to distinguish between resource label, source label and destination label to allow description of MAC and IP layer networks. -> Agree on the above, and the intention. -> Disagreement on the current practical implementation in syntax. Note: resource labels are used for two distinct purposes: for identification of channels (sub-Links) in a Link, and for flow forwarding (e.g. "data of VLAN 42 of interface 1/2 is forwarded to VLAN 18 of interface 0/3"). You can implement source and destination with either of the above in mind. E.g. assume a port at a router. Is that modelled as the possible IP flows through that port, or as the IP address of that port. Note that a port in a router in fact does not need an IP address to forward traffic (although it is used by ICMP). How to model a IP Port without an IP address? For this reason, Freek modelled it as the flows through that Port, which can efficiently be done using a PortGroup. * DWDM channels have an channel width, which will become important in the coming years if the ITU G.694.1 grid is abondoned to efficiently fill DWDM connection with channels of different capacity (10G, 40G, 100G). There are two ways to describe this: * Central frequency (or central wavelength) + spacing * minimum frequency (or maximum wavelength) and maximum frequency (or minimum wavelenght). -> Agreement that central wavelength + spacing is currently more common, so we use that for DWDM label descriptions. * Allow NML descriptions without Ports Freek created a multilayer NML description without ports, which was about 60% smaller than a description with ports, while retaining all features. It did require the addition of a "hasChannel" relation. -> Need more information -> Generally favourable to allow this description, but keep NML with Ports as the "normal" NML since most people still regard Ports as the basis for a network description, instead of regarding Links as the basis for a network description. Regards, Freek

1 0

Discussion on identifiers for relations
by Freek Dijkstra 19 Jun '12

19 Jun '12

Roman, Jeroen, While we're here together I still like a short discussion on identifiers for relations. Currently, it is just a string in XML. e.g. "isSink", "hasPort" However, it is a full URL in RDF, e.g. "http://schemas.ogf.org/nml/2013/10/relation#isSink", "http://schemas.ogf.org/nml/2013/10/relation#hasPort". So the translation is to simply prefix the XML-identifier with a fixed (special-purpose) URI. So far I used "http://schemas.ogf.org/nml/2013/10/relation#". However, as we found at the previous OGF, this is a problem when a new version of NML is defined in the future, with possibly more relations. Eg.: "http://schemas.ogf.org/nml/2016/08/relation#isSink". In that case, it is no longer clear which URL should be prepended to the base name ("isSink"). I can see two solutions: 1. Append the namespace of the element when translating. E.g. <nml:Topology xmlns:nml="http://schemas.ogf.org/nml/2013/10/base#"> ... <nml:Relation type="isSink"> becomes "http://schemas.ogf.org/nml/2013/10/base#isSink" (thus not "http://schemas.ogf.org/nml/2013/10/relation#isSink") 2. Don't translate relation identifier between XML and RDF, and use full URI in XML (yes, it's ugly, but it's simple): <nml:Relation type="http://schemas.ogf.org/nml/2016/08/relation#isSink"> Can we talk this over during a break today? Freek

1 0