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

First draft of NML Schema document
by Jeroen van der Ham 29 Nov '12

29 Nov '12

Hello all, It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1". Please have a look through it and let us/me know what you think about this document. With the feedback we get, we will improve the document and we plan to finally start the process on this document next month. Thanks! Jeroen.

5 10

brief minutes of the NML call today
by Jeroen van der Ham 02 Nov '12

02 Nov '12

Hi, Very brief minutes of the call we had today: Present: Roman, Aaron, Freek, Jeroen - about two dozen views, but no responses yet on the NML schema draft - Roman will check layerencoding in the XML examples - use id for now, figure out the clashing yourself if present. use reference in a version 2 as a special relation A single document should be unambiguous and clear - make sure that we mention something along these lines in the security section. - Jeroen to checkout the definition of encoding in RDF - Freek will poke Andre for the Redmine transition - We will prepare an abstract for TNC2013, describing applications of NML, especially NSI. Jeroen will start with a structure after SC. Next call will be after SC, on November 22nd.

2 2

Conference call
by Jeroen van der Ham 25 Oct '12

25 Oct '12

Hi, We've just had a very successful OGF, and we're all very busy with ramping up to SC. I would still like to have an NML call, but I'm proposing that we skip this week, and plan one for October 25th at the usual time (UTC 15:00 - CEST 17:00 - Eastern 11:00 - Pacific 8:00). For that conference call I would like to discuss the following points: - Final draft of NML Schema - ID/Reference discussion - Experimental NML document Jeroen.

1 1

CFP: IEEE Communications Magazine - Monitoring and Troubleshooting Multi-domain Networks using Measurement Federations
by Jason Zurawski 22 Oct '12

22 Oct '12

[Apologies if you receive multiple copies of this CFP] ------------------------------------------------------------- IEEE Communications Magazine - Monitoring and Troubleshooting Multi-domain Networks using Measurement Federations CALL FOR PAPERS - First announcement ------------------------------------------------------------- http://www.comsoc.org/files/Publications/Magazines/ci/cfp/cfpcommag1113.htm Aims and Scope In both the scientific and corporate worlds, users, resources, and data are often physically distributed, making networks increasingly important for all operations. Enormous progress has been made in increasing the capacity and accessibility of networking infrastructures, which in turn has fostered wider adoption of Cloud and Grid environments. Unfortunately, these advances have not directly translated into improved performance for all applications and users; instead, network performance problems become even more subtle and detrimental as the capacity of the network increases, and troubleshooting them on multi-domain network paths is highly challenging. These problems may be as benign as congestion from other network users, or as serious as packet loss caused by one or more intermediate-domain infrastructure and architectural flaws. Troubleshooting performance problems on multi-domain networks requires a great deal of effort and expertise, as well as measurement policy agreements that mutually benefit domains within measurement federations. Novel approaches are needed to foster wider adoption of explicit measurement federations such as perfSONAR, SamKnows, Grenouille and M-Lab involving co-operating agents in collaborating vendor organizations as well as user communities. These approaches may also be suitable for implicit measurement federations seen in content-delivery networks involving multiple service providers that co-operate to reduce operating costs, while providing satisfactory end-user experience. Building upon current end-to-end measurement federation related standards-development efforts - at Open Grid Forum (OGF), IETF IP Performance Metrics (IPPM), IEEE 802.1 ag, ITU-T Y.1731, and Metro Ethernet Forum (MEF) - can benefit the interoperability and sustainability of explicit and implicit measurement federations. In addition, sophisticated tools are required to monitor multi-domain networks and to detect, localize and diagnose performance problems in real-time. As networks increase in capacity, and new paradigms such as Software Defined Networking emerge to aid in traffic management, performance monitoring tools must be scalable and capable of detecting performance issues in a timely manner. The monitoring and diagnosing tools must comply with measurement federation policies, and aid network operators when troubleshooting perceived abnormalities, as well as help network middleware and intelligent applications to work around problems, ultimately minimizing the impact to end users. This special issue will cover novel techniques and standardization efforts in the area of monitoring and troubleshooting of multi-domain networks using measurement federations. Topics to be covered include, but are not limited to: • Algorithms and Techniques for Automated Network Troubleshooting • Architectures for Federated Measurement Collection and Sharing • Intra and Inter Domain Monitoring Strategies • Measurement Federation related Standards-development Efforts • Monitoring of Software Defined, Content-delivery and Overlay Networks • Troubleshooting of Hybrid Packet and Circuit Networks • Network-aware Middleware for High Speed Networks • Measurements from Cloud and Grid Environments • Security and Policy Considerations for Federated Measurements • New Policy-based Network Monitoring/Analysis Tools and Paradigms • End-to-End ("Disk-to-Disk") Performance Problem Troubleshooting • Scalability of Measurement Methods and Infrastructures • Embedded Active Monitoring based Collaborative Management • Case Studies of End-to-End or Network Performance Troubleshooting • Federations to jointly troubleshoot Home-area and Wide-area Networks Submission Guidelines Articles should be tutorial in nature and written in a style comprehensible to readers outside the specialty of the article. Authors must follow the IEEE Communications Magazine's guidelines for preparation of the manuscript. Complete guidelines for prospective authors can be found at http://www.comsoc.org/commag/paper-submission-guidelines. It is very important to note that the IEEE Communications Magazine strongly limits mathematical content, and the number of figures and tables. Paper length should not exceed 4,500 words. All articles to be considered for publication must be submitted through the IEEE Manuscript Central (http://mc.manuscriptcentral.com/commag-ieee) by the deadline. Select "November 2013/Monitoring and Troubleshooting Multi-domain Networks using Measurement Federations" from the drop down menu. Important Dates Manuscript Submission Due: March 1, 2013 Acceptance Notification: July 1, 2013 Final Manuscript Due: September 1, 2013 Publication: November 2013 Guest Editors Constantine Dovrolis - Georgia Institute of Technology - dovrolis(a)cc.gatech.edu Prasad Calyam - Ohio Supercomputer Center/OARnet, The Ohio State University - pcalyam(a)osc.edu Raj Kettimuthu - Argonne National Laboratory - kettimut(a)mcs.anl.gov Brian Tierney - Energy Sciences Network - bltierney(a)es.net Jason Zurawski - Internet2 - zurawski(a)internet2.edu Loki Jorgenson - NooCore Technology Consulting - ljorgenson(a)noocore.com ----- Jason Zurawski, Senior Research Engineer Internet2 zurawski(a)internet2.edu office: [+1-202-331-5354] mobile: [+1-703-981-2494] fax: [+1-202-872-4318] TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/

1 0

Re: [Nml-wg] layerencoding vs. encoding
by Roman Łapacz 22 Oct '12

22 Oct '12

W dniu 2012-10-22 14:14, Jeroen van der Ham pisze: > Hi, > > According to https://forge.ogf.org/sf/sfmain/do/go/artf6577 it should be encoding? It seems 'encoding' is valid now. I'll update the XSD schema. I saw your updated topology file for the NSI demo (https://github.com/jeroenh/AutoGOLE-Topologies/blob/nsiv2/master.n3) and if you want to apply artf6577 the use of nmleth will have to be replaced with nml:label labeltype. Roman > > Jeroen. > > On 19 Oct 2012, at 16:34, Roman Łapacz <romradz(a)man.poznan.pl> wrote: > >> Hi Jeroen, >> >> I noticed that the UML diagram (and the OWL schema) has 'encoding' attribute in PortGroup (the same for LinkGroup but in this case the OWL schema does not have it) but I remember clearly that we replaced it with 'layerencoding' attribute (I included this in the XSD schema). To be honest now I don't know what is valid (at the beginning it was 'encoiding', than 'layerencoding' and now again 'encoding'?) . >> >> Roman >> >> >> W dniu 2012-10-11 21:25, Jeroen van der Ham pisze: >>> Hello all, >>> >>> It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1". >>> >>> Please have a look through it and let us/me know what you think about this document. >>> >>> With the feedback we get, we will improve the document and we plan to finally start the process on this document next month. >>> >>> >>> Thanks! >>> Jeroen. >>> >>> >>> >>> _______________________________________________ >>> nml-wg mailing list >>> nml-wg(a)ogf.org >>> https://www.ogf.org/mailman/listinfo/nml-wg

1 0

References
by Freek Dijkstra 17 Oct '12

17 Oct '12

Hi all, The WG has been discussing the id/idRef/isReference last week at OGF36, with valuable input from Aaron by email. Unfortunately, there still does not seem a clear consensus. This means that I feel forced to move this issue to the experimental draft. If you disagree, please read the rest of this email and reply before the Oct 25 conference call. Since nearly all participants agree that the discussed concepts are useful, I do suggest to continue to discussion. We do need this in the experimental document, not drop it altogether. It seems that there are three overlapping use cases: authority (distinguishing between something defined by the sender, or defined by a third party), reference (pointing to the location -third party, or other place in the document-) and finally verification (making sure that a definition is complete, and uniquely defined). Most proposal I've seen dealt with syntax, some with logic, but none really started with a requirement based on these use cases. That leads me to believe that this issue is not fully understood and belongs in the experimental document. These topics have one thing in common: they all are part of the control plane of the NML protocol, rather than issues dealing with actually Topology description. For example, the authority use case ultimately deals with trust. Jeroen's proposal is to basically accept all messages as authoritative and combine them in a single object, regardless of origin of the message and how it is described (or at least deal with this sort of logic on the application layer). Aaron's proposal is more elaborate, and does allow the sender to make a distinction between a full definition and a object reference. This might allow syntax checks or change the confidentiality level that a NML recipient may have in a statement (compare "here a full description of a Port" to "I *think* this link ends up at this-and-that 3rd party Port, but I don't know the details of that port"). If I was recipient, I would place more confidentiality in the first message than the second statement, and if the conflict, I would drop the second statement in favour of the first. I still feel that Aaron's proposal has a good potential. However, I'm still not 100% sure about the logic -- is it only about verification, or also authority? Despite the subject line in this email thread, it doesn't seem to be about reference (after all, an idRef means the id may either be defined elsewhere in the document, or it may be defined by a third party, but it doesn't tell me who that third party is or where in the document the definition can be found). Hence, I'm going with the most simple (and IMHO less elegant) proposal by Jeroen which doesn't make any statement about any of the above, and just uses "id" all the time. No idRef, no isReference, no isDefinedBy. One thing we still want to consider is to include idRef in the NML-base document, and say that NML compatible parsers SHOULD also accept the "idRef" in addition to the "id" parameter. A parser SHOULD treat them equally. This would at least allow us to later differentiate between id and idRef. This may help prevent backward incompatibility if we decide to add idRef later. This issue has some strong opponents, so if you feel that I as co-chair made the wrong decision here, please let me know off-list of on-list. I'm always open to suggestions and improvement. And please, do not stop discussing this issue. We should pursue it; it is just that at the current state of discussion I see no other option to move it to experimental not to unduly delay publication of the base document. Regards, Freek

2 1

References
by Jeroen van der Ham 12 Oct '12

12 Oct '12

Hi, We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it. Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. Jeroen.

6 26

slides from today's OpenFlow and SDN workshop
by Guy Roberts 08 Oct '12

08 Oct '12

The slides from today's OpenFlow and SDN workshop are now available to download here (at the bottom of the page): https://www.ogf.org/gf/event_schedule/index.php?id=2543 Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

1 0

atributes of Services
by Freek Dijkstra 05 Oct '12

05 Oct '12

Hi, I'm reviewing the NML document a few times in detail, adding notes what examples are useful. One thing I can't seem to do is distinguish between the Ports that can be configured by an AdaptationService and the Ports are are already configured. The providesPort relation seem to aim the ports that are already configured, akin to providesLink for the SwitchingService. Current situation ================= Here are the current attributes and relations for SwitchingService: - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup Here are the current attributes and relations for AdaptationService: - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --adaptationfunction--> URI (*) N/A - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup (* The adaptationfunction attribute can be used to determine client layer encoding, but not the available labels) Here are three (3) proposals to rectify this omission and subsequently align the SwitchingService and AdaptationService definitions: Proposal 1: encoding and hasLabelGroup ====================================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add attribute and relation): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --encoding--> URI AdaptationService --hasLabelGroup--> LabelGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 2: canProvidePort ========================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add canProve): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --canProvidePort--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 2: canProvidePort ========================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add canProvidePort): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --canProvidePort--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 3: Behave like a SwitchingService ========================================== For SwitchingService (has[In|Out]boundPort is replaced with canConnect[Sink|Source]Port): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(canConnectSinkPort)--> Port|PortGroup SwitchingService --(canConnectSourcePort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (it now is provided by a Node or Topology): - associate with static component: Node|Topology --(hasService)--> AdaptationService AdaptationService --(hasServerSinkPort)--> Port AdaptationService --(hasServerSourcePort)--> Port - associate which client AND server layer ports CAN be created: AdaptationService --(canConnectClientSinkPort)--> Port|PortGroup AdaptationService --(canConnectClientSourcePort)--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesClientSinkPort)--> Port|PortGroup AdaptationService --(providesClientSourcePort)--> Port|PortGroup The advantage of the later configuration is that is allows bidirectional adaptations services (no more distinction between AdaptationService and DeAdaptationService). With only minor modifications it is also possible to support inverse multiplexing adaptation. I did not add this, because I'm not a big fan (it adds more complexity, which can be provided with the more simple experimental isParallelCompoundLink relation.) My opinion ========== I would say proposal #2 is cleanest. What do you think? Freek

3 3

schedule for OpenFlow and SDN workshop at OGF36
by Guy Roberts 03 Oct '12

03 Oct '12

Hello All, Please find detailed agenda for the OpenFlow and SDN workshop at OGF36. There will be 6 presentations of 10 minutes each followed by a 20 minute discussion. Regards, Guy OpenFlow and SDN workshop @ OGF36 Location: Comiskey room, Hyatt Regency Chicago, 151 East Wacker Drive, Chicago, IL 60601 Time: 10:30 - 12:00, Monday, 8th October 2012 · Ping Pan (Infinera) "Supporting SDN in Transport Networks" · Jerry Sobieski (NORDUnet) "The role of NSI in emerging SDN environments" · Joan A. Garcia-Espin (I2Cat) "OpenFlow in GN3's Network Factory" · Takahiro Miyamoto (KDDI R&D Labs) "The relationship between OpenFlow and Switching Service" · Jeroen van der Ham (University of Amsterdam) "Current status of the NML and applicability to OpenFlow and SDN". · Chin Guok (ESnet) "ESnet's use of OpenFlow to facilitate science data mobility". · 20 minute panel discussion Ping Pan (Infinera) "Supporting SDN in Transport Networks" This presentation considers how SDN can be used to build an overlay network on top of transport infrastructure. It is proposed that network services are then be deployed on top of this overlay. An architecture based on a light-weight virtual switch is proposed to achieve these aims. Jerry Sobieski (NORDUnet) "The role of NSI in emerging SDN environments" This presentation will consider the relationship between NSI and OpenFlow. NSI has the potential to play an important role in SDN initiatives by providing a framework for multi-provider circuit provisioning. This presentation considers how these standards can co-exist. Joan A. Garcia-Espin (I2Cat) "OpenFlow in GN3's Network Factory" Given the increasing momentum of Software-Defined Networking, GÉANT3 project is conducting an experimental deployment of OpenFlow in order to assess its validity for future NREN services in Europe. Facility design and implementation are being developed under GN3's Joint Research Activity 2, Task 5, namely Network Factory. This presentation shows the approach taken and on-going work. Takahiro Miyamoto (KDDI R&D Labs) "The relationship between OpenFlow and Switching Service" This presentation will consider how the NSI framework can be simply extended to deliver a switching service. The synergies between NSI and OpenFlow are considered. Jeroen van der Ham (University of Amsterdam) "Current status of the NML and applicability to OpenFlow and SDN". This presentation will provide an update on the current status of the NML working group at OGF. The uses and aims of the NML standard are presented and potential uses with OpenFlow and SDN in general are considered. Chin Guok (ESnet) "ESnet's use of OpenFlow to facilitate science data mobility". The focus of this presentation is to provide a subjective view of the strengths and weakness of the current iteration (v1.x) of Openflow in the WAN, to suggest how OpenFlow can be used in WANs today, and discuss on-going OpenFlow activities within ESnet to facilitate science data mobility. 20 minute panel discussion All presenters will participate in panel discussion on the synergies between OpenFlow/SDN and OGF standards. _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

1 0