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

Conf call March 1
by Freek Dijkstra 29 Feb '12

29 Feb '12

The next NML conf call will be shifted in time (again). Jerry and Roman excused themselves for the next call. NML conference call starts at: *** 16:30 UCT (17:30 CET, 8:30 Pacific, 11:30 Eastern). *** 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

3 2

Notes for Feb 23 conf call
by Freek Dijkstra 23 Feb '12

23 Feb '12

Here are some notes from todays call. Some text is shuffled for readability. If you have any correction or additions, please follow up. The actions items are at the end of the notes. Notes for NML call 23 February ============================== Attendance: Aaron Brown (I2), Jerry Sobieski (Nordunet), Roman Łapacz (PSNC), Freek Dijkstra (SARA) Excused: Jason Zurawski, Jeroen van der Ham, Chin Guok 1. Action items from previous call: ---------------------------------- Jeroen was not able to attend today's call; his action items will be postponed to the next call. Roman and Freek send NMLified version of the AutoGOLE topology to the list. Jerry was pleased to see them and thinks they're great starting points for integrating NML and NSI concepts. Jerry suggested to create a smaller example. Freek suggests to instead pick one network and compare them in the original and proposed drafts. Freek contacted the NSI group about the integration, but got no formal reply yet. The NSI-WG is currently very busy on other topics. Freek will contact Guy for the best time slot. 2. Preparation for OGF 34. ------------------------- Freek, Roman and Jerry will attend OGF 34. Likely no-one from Internet2 will be able to attend. Freek will sent out a call for presentations. The topics during OGF 34 will be: * NML-NSI integration - unidirection - explicit links * recursion of topologies (discussion/proposal) * VLAN description (discussion/proposal) * General document improvement (WORKING session a.k.a. the shut-up-and-start-writing-session) 3a. NML-NSI integration ----------------------- NSI issues: * Enumeration: Possible large number of end-points. Unclear how to group them. * Distribution process: how to update the world view by each nml/nsi topology consumer and how to deal with inconsistencies. Nordunet issue: * NORDUnet has multiple locations (New York and Copenhagen). Not really one network. Three solution: (1) one network, with exposing some of the internal details and constraints, or (2) describe as 2 topologies with 1 controlling NSA. * In practice multiple topologies are needed: one detailed topology for internal use; one published to trusted peers; perhaps yet another published to end-users or other entities. 3b. Unidirectional vs bidirectional ----------------------------------- Freek gives some background. When the topic came up first, it was decided that is was probably easier to pick one instead of doing both at the same time. Since unidirectional is more flexible, that was chosen. It was acknowledged that a bidirectional concept is useful, but for simplicity, this was only a grouping of unidirectional links. Jerry sees use case where not specifying directionality gives ambiguity. There are examples where bidirectionality is required. Freek recalled an example given by Richard Hughed-Jones: a single fiber strand, that carries data in two directions. Upstream at 1310 nm, and downstream at 1550 nm. This is an actual technology used in some FttH networks. A broadcast network has multiple output ports. Roman asks Freek and Jerry to write down these use cases. 3c. Difference between NML:topology, dtox:NSNetwork, dtox:NSA ------------------------------------------------------------- NML topology is set on network object with some internal connectivity NSI Network is a connection service. A NML topology should be thought of as a big round circle with ports on the edges, and a black box in the middle that can provide some data transport. The document surely has a more formal definition. A NML network not the same thing. A NML network is a IP subnet; think of it as a Ethernet VLAN with attached hosts. These terms were decided in Munich after a rather lengthy discussion where we concluded that the term "Network" was severely overloaded. Jerry: propose to put dtox:nsnetwork in nml:topology for now, and perhaps take it a step further, put all child elements of dtox:nsnetwork in directly in the nml:topology. Freek and Jerry will look at the exact definition of NML:Topology and NSI Network, and see if they can sync their definition. If that is possible, they are the same thing. If not, we can than think what the relation between the two is. 3d. Recursion of NML topologies ------------------------------- Layers have abstraction, but there is also recursion on a single layer. Freek referred to figure 7 of G.800. The public URL of G.800 is: http://www.itu.int/rec/T-REC-G.800 (Note: ITU-T just published a new version of G.800 this month; Freek referred to figure 7 in the 2007 version of the document. Direct link: http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.800-200709-S!!PDF-…) Roman: can there be more than one NSI network in a domain? Jerry: Each NSA controls exactly one NSI Network, and each NSI Network is controlled by exactly one NSA. Both NSI Network and NSA can recursive. E.g. a federated NSA can act a agent for multiple subdomain NSAs. NML should be able to describe a federated topology, and subtopologies. We need to define how to describe the relation of these topologies with each other. Jerry will write this down as a use case (he has multiple slides on it) Freek will dig up the URL for the use-case tracker: https://forge.ogf.org/sf/tracker/do/listArtifacts/projects.nml-wg/tracker.u… NSI has control plane topology and data plane topology. Jerry hopes that NML topology constructs can be described by NML concepts. Action items: ============= * Jeroen to go through document and set up action points * Jeroen to check the Security considerations of NM * Freek to write use case on bidirectional and unidirectional links: single fiber with two wavelengths in different directions. * Jerry to write use case on bidirectional and unidirectional links * Jerry to write usecase on NORDUnet being a geographical segregated network (NY and CPH), with possible restrictions between the two locations/networks * Jerry to write this down federated and sub-NSA as a use case. * Freek and Jerry look at the exact definition of NML:Topology and NSI Network, and see if they can sync their definition

1 0

Call for presentations during OGF 34
by Freek Dijkstra 23 Feb '12

23 Feb '12

Hi, I you consider giving a formal or informal presentation during one of NML's timeslots at the upcoming OGF 34 conference, please contact me on-list or off-list, preferably in the next week. Thanks, Freek

1 0

NMLify of AutoGOLE topology
by Freek Dijkstra 23 Feb '12

23 Feb '12

Hi all, I've tried to NML-ify the AutoGOLE topology. I did in RDF/XML because that is probably readable by both OWL and XML folks. Below are the steps I took in detail, along with intermediate results (which may help in understanding the differences). The main changes are: - made ports and link unidirectional, per NML specs. - use explicit link object to describe the SDP (NML has no connectedTo concept) - change the urn:ogf:network identifiers to a valid syntax, the ones currently in AutoGOLE use are not valid according to proposed standard nor previous use in either GLIF or perfSONAR community. The file AutoGOLE-Topo-2012-02-22.rdf gives the result so far. Notes: 1. The resulting topology file has three layers: - NML topology - dtox NSNetwork - dtox NSA I really like the clear distinction between the data plane (NML) and control plane (dtox/NSI). However, I wonder if we should move this to two layers, perhaps merging dtox:NSNetwork and nml:topology. 2. The dtox:hasSTP relation now points to a nml:bidirectionalport. NML defines a similar "hasPort" relation between a nml:Topology and nml:Port. (and there is some discussion to differentiate between hasOutboundPort and hasInboundPort). If dtox:NSNetwork and nml:topology are merged, I recommend to use these relations. 3. Yet unclear how exactly to tie Ethernet specifics to the examples, it seems prudent to use labels and the subnetwork concept as discussed in the NML-WG in Lyon (see subversion: https://forge.ogf.org/svn/repos/nml-examples/20110922/other_examples/config…; you need a gridforge login. Drop me a line if you can't access it.) Regards, Freek Dijkstra List of steps I took: Source: AutoGOLE-Topo-2012-01-25.owl Removed owl:NamedIndividual Removed schema definitions (owl:Ontology, owl:AnnotationProperty, etc.) Removed Position comments (used by auto-gole.appspot.com) Removed unnecessary comments Result: AutoGOLE-Topo-2012-01-25.rdf Changed dtox:lat, dtox:long and dtox:Location to geo84:lat, geo84:long and geo84:SpatialThing Corrected label of Netherlight location from Copenhagen to Amsterdam (geo84 was OK) Changed dtox:STP to nml:bidirectionalport Grouped ports of a single network in a nml:topology Commented dtox:connectedTo, since this is not valid NML Added rdfs:label to all NSA and all locations Changed admin contact from string to vCard Result: AutoGOLE-Topo-2012-02-20.rdf Change urn:ogf:network identifiers to valid syntax (urn:ogf:network:<FQDN>:<date>:<opaque>) Make all bidirectional ports unidirectional Explicitly defined NML links, with sources and sinks Result: AutoGOLE-Topo-2012-02-22.rdf Possible future direction: Merge NML:topology with dtox:NSNetwork Remove the dtox:managedBy property, as there is already an inverse relation dtox:managing to find the correct dtox:NSA Added switch matrix to each NML topology Define switching capabilities for each topology. use nml:hasPort instead of dtox:hasSTP Result: (the-AutoGOLE-future-is-yet-to-be-written.rdf)

3 10

Conf call Feb 23
by Freek Dijkstra 22 Feb '12

22 Feb '12

No-one objected to the shift in starting time, so it is set: NML conference call starts at: *** 16:00 UCT (17:00 CET, 8:00 Pacific, 11:00 Eastern). *** 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: 1. Action points from previous call: Jeroen to go through document and set up action points Jeroen to check the Security considerations of NM Freek to contact NSI to set up topology discussion Freek and Roman to create an NML version of the topology 2. Preparation for OGF 34 - Participants - Presentations - Work items - NML-NSI integration 3. Short discussion on: - unidirectionality of NML - difference between NML:topology, dtox:NSNetwork, dtox:NSA - recursion of NML topologies - ... (the goal of the discussion is to (1) identify new issues, (2) formulate work items for these issues and (3) assign volunteers to them) Note that I plan to use the tracker at https://forge.ogf.org/sf/tracker/do/listTrackers/projects.nml-wg/tracker again. Regards, Freek

1 0

bidirectionality (was: NMLify of AutoGOLE topology)
by Freek Dijkstra 22 Feb '12

22 Feb '12

Roman Łapacz wrote: > btw. I'm still thinking that we don't need nml:bidirectionalport in NML > :) We could use port with "bidirectional" relation. The distinction between <nml:port type="bidirectional"> and <nml:bidirectionalport> is only syntactic, so I presume you are referring to not only change the syntax, but also the semantic. Meaning that all the rules and relations that apply to nml:ports can be applied to nml:bidirectional ports as well. Actually, the problem is not so much with bidirectional ports, but with bidirectional links. I personally hope you are right. We identified some issues related to identifying the direction (ingress or egress) for physical interfaces that did both de-adaptation AND adaptation for ingress traffic (this is uncommon, I only know of one practical example). For that reason, we decided at the time to do everything unidirectional (so that identifying directionality is trivial) and see if we can later come up with either syntactic of semantic simplifications for bidirectional links. I just took another look at the problem we had back than, and I start to wonder if the problem is solved because we now use explicit links, and we have some basic understanding how to handle multicast and broadcast (as links with multiple end-points). Let me describe the problem we had a few years ago. If you have time to propose a solution, and it works with the following three examples, that's a good indication for me that we can make it work, and I would back up your proposal. If you make a proposal, make sure to do it in the UML schema, since that is leading. 1. A link between one network that described all links unidirectional and another network that describes all links bidirectional. 2. A link with more than two end-points, such as a Ethernet LAN or VLAN (this one is probably easy). 3. How to describe a physical interfaces that did both de-adaptation AND adaptation for ingress traffic. The only example I know is an Ethernet interface in a SONET switch. Here, the Ethernet traffic is first de-adapted from the fiber layer (e.g. using 1000base-LR decoding), and than, //at the same interface// adapted to the VC-4 layer (e.g. using GFP-F encoding or the older LEX encoding). The questions are: a) how to make the distinction between the link on the ingress and egress side of an such an interface, and b) the distinction between the adaptation stack on the ingress and egress side of such an interface. Use case 3 is rather complex, so I made a picture, see attached (it's still complex, so I'm happy to explain in more detail if required). As you can see, on the Ethernet layer, there is a direct link between port C1 and D2 (thus NOT between C2 and D1 as is the case on the fiber layer). Data coming in at C1 from either A1 or B1 is really different from data coming in from D2. For use case 3a, how do the links and ports look like when described on the Ethernet layer (without describing the underlying fiber infrastructure). Would be possible to distinction to describe the connections A1, B1 and C2? For use case 3b, how to describe the links, ports and adaptation if only the fiber layer and adaptations are described, but the Ethernet layer is not explicitly defined (but should be inferred from the underlying infrastructure on the lower layer). Regards, Freek

2 1

Conf call Feb 23
by Roman Łapacz 21 Feb '12

21 Feb '12

Hi Jeroen, would it be possible to start the call at 5pm CET in case of NMC call cancellation? Jason, are we going to have the NMC call on Thu? Cheers, Roman

4 3

NSI -> NML integration
by Jerry Sobieski 17 Feb '12

17 Feb '12

Hi all - With the discussion around NSI integration into NML, I have constructed a few slides to present the NSI topological notions to the NML folks. These are general, and so we should discuss in a joint call... but the basics of the two efforts are fairly close... I am much more comfortable now that we have a notion that many of these NML topology constructs are logical notions rather than physical analogues... we just need to identify where there are semantic differences and where there is just terminology differences... the latter are easily reconciled. The former may be a bit more effort - but I am very optimistic these will fall over reasonably easy as well. Please offer any questions of comments... Jerry

1 0

source/sink versus ingress/egress (was: Example topology of Automated GOLE)
by Freek Dijkstra 17 Feb '12

17 Feb '12

A somewhat related issue on source/sink. I don't think this was ever written down. Freek Dijkstra wrote: > The question at hand is basically how to describe the following (with > apologies with my poor ASCII art skills) > > port A link X port B link Y port C > O------------------>O------------------>O > [...] > In the NML schema it is currently defined as: > > link X > relation=source > port A > relation=sink > port B > link Y > relation=source > port B > relation=sink > port C For the record, an alternative way to describe this is making the ports leading instead of the links: port A relation=egress link X port B relation=ingress link X relation=egress link Y port C relation=ingress link Y Technically I think these are equivalent: the provide a directed relation between links and ports. Which one is syntactically better depends what is more common, a one-to-many or a many-to-one relation between ports and links. For the circuits, this is often a one-to-one relation. Since we implemented cross-connects as links, VLANs are likely also described as some kind of "link", but one with multiple sources and sinks. Hence, there is a one to many relation from link to port. This means that the source and sink relation we have now is more easy to convey in XML than the alternative ingress and egress relation. I personally think the source/sink stuff is still the best alternative we have. Regards, Freek

2 1

NML-NSI integration
by Freek Dijkstra 17 Feb '12

17 Feb '12

Roman, Can I forward the following to the list? Freek All, Roman created an update to the AutoGOLE topology. This lead to an off-list discussion regarding the namespaces. Since this may be relevant to the group, I would like to take this discussion on-list. Freek -------- Original Message -------- Subject: Re: [Nml-wg] Notes for teleconference Feb 16 Date: Fri, 17 Feb 2012 15:53:09 +0100 From: Roman Łapacz <romradz(a)man.poznan.pl> To: Freek Dijkstra <Freek.Dijkstra(a)sara.nl> CC: Jeroen van der Ham <vdham(a)uva.nl>, Jason Zurawski <zurawski(a)internet2.edu> Freek suggested: >>>>> * Use NML namespace over NML-NSI namespace where possible Roman: >>>> nml-nsi:port indicates that the port element represents NSI's STP >>>> nml-nsi:link indicates that the link element represents NSI's SDP >>>> nm-nsi:network indicates that the network element represents NSI's nsnetwork >>>> All three things are specific to NSI so I would keep their nsi >>>> namespaces to stress that. Freek: >>> I understand your point, and agree that is may be beneficial to denote >>> somehow that these are SDP or STP to NSI. >>> >>> However, would using a different namespace not defeat the purpose of NML >>> of having a single schema that everyone uses? >>> >>> (Also, I'm not sure if that should be in the topology; I'm actually >>> hoping that we can keep the topology clean from control plane >>> information, and have the the control plane simply refer to the topology.) Roman: >> I see your point. Just one basic NML namespace would be an ideal >> situation. But still think that extensions/namespaces should be allowed >> to assign more and specific information to the basic NML elements. The >> NSI application(s) may want such extension to easily identify NSI >> abstract connections or points. Freek: > I was perhaps a bit quick in saying "let's use NML (base) namespace > everywhere". I don't know what the best option is. I try to make up my > mind as we discuss this. > > It is certainly possible to overload (subclass? I'm not sure about the > correct term here) a namespace to let's say include NSI-specific > attributes next to the regular NML-attributes. > > However, I see a big risk there: in the past we have been discussing the > option to overload (subclass?) a namespace for the purpose of > differentiating between different technologies (Ethernet, WDM, ...). > I don't see a clean way to put something in both a nml-nsi AND a > nml-ethernet namespace. Unless we are creating nml-base, nml-nsi, > nml-ethernet, and also nml-nsi-ethernet namespaces. I have a feeling > that that solution does not scale. What if tomorrow some policy working > group comes along, and we have to create a nml-nsi-ethernet-public and > nml-nsi-ethernet-restricted namespace (or whatever someone may come up > with). > > In programming patterns, I think we need to use has-a instead of is-a (a > Port has-a STP-attribute, rather than a Port is-a STP). > > > Here is my current thinking. > > I understand there is a need for NSI (and perhaps others) to tag a given > port as being a "STP", and perhaps it should go in the topology. It > actually is a matter how to refer to it. The option above tags certain > ports as "an STP" by being in a different namespace. My thought (hope) > was that the NSI protocol could add a tag somewhere like this: If we allow adding new tags as extensions in any place in the structure then we don't have too much control over the structure. Generic parsers will not know how to interpret such unexpected (not included in the base NML schema) changes. On the contrary, namespaces as extensions allow parsers to, at least, understand their standard properties, others would be ignored. The structures defined in the base NML schema are still followed. (Of course it is possible to define a schema in such way that any element could be inserted in any place but I don't think it's the right direction). Roman > <nml:topology id="1234"> > .... >  > ... > <nsi:stp-list> > <nml:port idref="...."/> > <nml:port idref="...."/> > <nml:port idref="...."/> > </nsi:stp-list> > </nml:topology> > <nsi:domain> > <contact> > <vCard> > </contact> > <controller> > <url>http://example.net/webservices/NSI-controller</url> > <topology idref="1234"/> > <controller> > </nsi-domain>

3 5