September 2011 - nml-wg - lists.ogf.org

NML terminology: Port vs Interface
by Freek Dijkstra 10 Oct '11

10 Oct '11

All, A few years ago the NML group agreed to describe an object equal to the G.800 "Forwarding Point", but name it "Port", after prior usage in the NM-WG. Recently, it was proposed to rename this object to "Interface", after some confusion over the term "Port" in two projects. To end this discussion, I ask everyone reading this mail to vote what they think is the best term. The options are: * Port * Interface * ForwardingPoint * LogicalPort * LogicalInterface * No discussion, but further discussion on this term This is a ranked ballot, so if you don't care about the name, but like this discussion to end, you can rank the first five options with high priority (rank 1), and the last option (further discussion) as rank 6. Please vote at: http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/vote.pl?id=E_74473334af26… The voting system has some easy-to-circumvent methods in place to prevent people voting multiple times. If you have problems voting, let me know. Thanks, Freek

7 9

Fwd: [oscars-users] Graphical topology editor tool
by Jason Zurawski 30 Sep '11

30 Sep '11

Howdy; This is a pretty cool project that I wanted to pass along. Thanks; -jason -------- Original Message -------- Subject: [oscars-users] Graphical topology editor tool Date: Fri, 30 Sep 2011 15:38:53 -0700 From: Chin Guok <chin(a)es.net> To: oscars-users(a)es.net CC: chin(a)es.net, "bharath(a)es.net" <bharath(a)es.net>, Bharath Honnenahalli Ramaprasad <bharath.hr(a)umassd.edu> Hi all, I just wanted to forward this link to folks who might be interested in describing their network topology in the OGF NMWG Control Plane schema (used by OSCARS), but wanted an easier way of doing it then manually typing XML. - https://code.google.com/p/topology-wizard/ The tool as developed by Bharath Ramaprasad of UMass Darthmouth over the summer when he did an internship at ESnet. This is still a work in progress, so comments are welcomed. Thanks. - Chin

1 0

Meeting notes NML session OGF 33
by Freek Dijkstra 27 Sep '11

27 Sep '11

Attached are meeting notes of the NML sessions during OGF33. Thanks to Jeroen van der Ham for keeping notes during the second session. All errors in here are mine, please send corrects to the list. The document is also available at http://forge.gridforum.org/sf/docman/do/listDocuments/projects.nml-wg/docma… Meeting notes NML session OGF 33 ================================ NML had three sessions, two on Tue 20 Sep, and one on Thu 22 Sep. The first sessions consisted of formal presentation of related work: * Jason Zurawski – Circuit Monitoring * Jeroen van der Ham – GEYSERS; NOVI; GLIF DTOX-TF The second sessions contained presentations with discussions: * Jerry Sobieski – Jerry's Topology Wishlist * Jeroen van der Ham – Port vs. Interface * Freek Dijkstra – URN:OGF:network Status and Proposal * Freek Dijkstra - Status and Work Items * Jeroen van der Ham & Freek Dijkstra – Label Proposal The third session was devoted to a technical discussion on the XML syntax for labels, adaptations and switching services. * Jason Zurawski - XML syntax Jason Zurawski – Circuit Monitoring ----------------------------------- Slides: http://www.ogf.org/OGF33/materials/2350/20110920-CircuitMonitoring.ppt Jason presented slides describing the circuit monitoring work by Internet2, done late 2010, early 2011. Some of these slides were presented earlier in the NMC working group, but this time, Jason focussed a bit more on the schemas used. Live demo: http://ndb1.internet2.edu/circuits/ Q: Why is there a topology collector (that queries both OSCARs and a topology service)? A: Topology service has static topology info, OSCARs has the dynamic information. One of the slides had a screenshot describing the following circuit: -> ion.internet2.edu -> dragon.maxgigapop.net -> <- dragon.maxgigapop.net <- ion.internet2.edu <- This was confusing, as both dataflows seem to go from Internet2 to Max Gigapop. It was unclear if the bandwidth utilization of an interface lists the total bandwidth of that interface, or just the bandwidth of a VLAN on that interface. (The GUI does not list the VLAN number, so we presumed it listed the bandwidth utilization of all VLANs on that interface). The source code of the project is available online. Code base topology service available at http://anonsvn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-TopologySe… Code base GUI is available at http://anonsvn.internet2.edu/svn/perfSONAR-PS/branches/aaron-circuits/perfS… Jeroen van der Ham – GEYSERS; NOVI; GLIF DTOX-TF ------------------------------------------------ Slides: http://www.ogf.org/OGF33/materials/2350/1109-OGF-NML-UvA-Activities.pdf Jeroen presented three slide decks: - on the GEYSERS project that the UvA is involved with - on the NOVI project that the UvA is involved with - on the Automated GOLE demo at GLIF, and the DTOX (dynamic topology exchange) workgroup of the GLIF Jeroen invited participants to join a BoF session at SC'11 on "Semantic Resource Descriptions in Advanced Cyberinfrastructures". URL: http://sc11.supercomputing.org/schedule/event_detail.php?evid=bof116 Both GEYSERS and NOVI use semantic (= OWL-based) topology descriptions. Jeroen explained their schemata. GEYSERS: Richard asked why a "Network Element" is different from a "Node Component". Would it be possible to integrate the network with other resources (such as CPU, memory and storage)? NOVI: Slide manager - manages virtual pool of composed resources from different domains Aggregate manager - manage resource pool under single management In a future plan, the ASB will be responsible for composition and slicing of resources across domains. However, the Slice manager can not be removed from the SFA, since not all (PlanetLab) domains have a ESB. DTOX: Discussion if NSI Topology represents the data plane or the control plane. According to Jerry, the NSI Topology represents the data plane, according to Jeroen the control plane. According to Jeroen, an endpoint is combination of URN and label Jerry Sobieski – Jerry's Topology Wishlist ------------------------------------------ Slides: http://www.ogf.org/OGF33/materials/2350/NSI+Topology+Wishlist.pptx Jerry presented two slides with a wishlist that NSI has with regards to topology description. Jeroen van der Ham – Port vs. Interface --------------------------------------- Jeroen argued that the change of the term "Port" to the term "Interface" in NML would reduce confusion. Both the NOVI and GEYSERS project use most of the concepts defined in NML, and also use the same terminology, with the exception of the term "Port", which is changed to "Interface" by both projects. The term "Port" was deemed confusing with the ports in TCP and UDP. Jeroen noted that a TCP port is actually a label on an Port/Interface. There's no real advantage to changing the term other than to reduce confusion. A vote will be held on the mailing list to decide on the term in NML. Freek Dijkstra – URN:OGF:network Status and Proposal ---------------------------------------------------- Slides: http://www.ogf.org/OGF33/materials/2350/NML+Progress+OGF33.pptx (slides 8-11) Freek presents progresson URN:OGF(:network) - URN:OGF has been accepted by IETF, waiting for sister-doc in OGF - document for registering subnamespaces is now in public-comments. - urn:ogf:network request draft has been written Problem with current urn:ogf:network syntax: domain names are somewhat volatile. Creating a registry for organisations that assign URNs would solve the problem. - suggestion for the registry: - organisation name - DNS + version - DNS + year Freek will write a proposal to the mailing list. Jeroen van der Ham & Freek Dijkstra – Label Proposal ---------------------------------------------------- Slides: http://www.ogf.org/OGF33/materials/2350/NML+Progress+OGF33.pptx (slides 12-13) Jerry and Jeroen volunteer to provide a candidate solution for expressing this in the UML. IP and MAC addresses as labels? Freek Dijkstra - Tasks Ahead ---------------------------- Slides: http://www.ogf.org/OGF33/materials/2350/NML+Progress+OGF33.pptx (slides 14-18) URL: http://forge.gridforum.org/sf/tracker/do/listTrackers/projects.nml-wg/track… Freek added tasks in the Tracker at the Gridforge website. Everyone is invited to shepherd any item that is marked as "New" or "Waiting for Volunteer". Jeroen notes that OWL is now the more standard syntax for ontologies. Proposes to change RDF to OWL. Jerry is volunteering to review the schema document once it nears completion. Jeroen volunteers to write the OWL schema Jason volunteers to finish the RNC schema Freek volunteers to help with the schemas Jason Zurawski - XML syntax --------------------------- Jason energetically led the working group through a couple of examples in XML, trying to reach consensus on syntax. The effort started in the hallway, and continued during the third session. The XML files are available from subversion repository at http://forge.ogf.org/svn/repos/nml-examples/20110922 Consensus was reached on the single layer XML syntax. Freek noted that he still thought the syntax of NML relations could be improved, but also made it clear that there is rough consensus on <nml:relation type="name_of_the_relation"/>. He reserved the right to re-iterate on a previous proposal after creating an implementation, to show the advantages (if any), but also urged the working group to continue with the current syntax, and not wait on that proposal. The goal of the third working session was to create a syntax to describe a VLAN switch, including a 802.1x-capable link between two devices. This problem was tackled in the following steps: 1. nmlbase.xml: A syntax to describe channels over a single link, in this case a single (default) VLAN (ID 0) over a link between Houston and Atlanta. This introduces two complimentary concepts: - A "providesChannel" relation between the (physical) link and (channel) link. - A syntax to describe adaptation between a (physical) fibre port, and the (logical) VLAN ports. This was done using an "adaptation" Service, which includes the adaptation between the two ports. 2. switch_matrix_without_labels.xml: Introduce the concept of a "switching" Service, that can provide cross connects. 3. switch_matrix_w_labels.xml: Introduce the concept of "labels" associated with ports (the possibility if they can be associated with links as well was not discussed. This is still open for debate.) 4. configured_vlan.xml: Description of a single VLAN as a "switching" Service. 5a. 2vlans_option1.xml: Description of two VLANs as two "switching" Services. 5b. 2vlans_option2.xml: Description of two VLANs as one "switching" Service. - It should be decided which of these two option is the best syntax. - 2vlans_option1.xml is more verbose, but easier to parse - 2vlans_option1.xml scales better (more compact syntax), but harder to parse The XML files are a first pass on agreeing with the syntax. They are not yet production ready examples: - they contain comments listing some (usually minor) open issues - some agreed upon syntax is commented out, so it validates against the RNC schema - some syntax may be superfluous for a given example, the examples should be trimmed to remove redundant code. Freek, Jason and Jeroen agreed to work on these examples, so they can be used in the schema document (or in an accompanying document).

1 0

Proposal: remove of type attribute from Link object
by Freek Dijkstra 21 Sep '11

21 Sep '11

In the wake of the NML sessions (for which the meeting minutes will follow shortly), Jeroen, Jason and I had some discussion on the schema. Based on these discussions, I propose two changes to the schema. Here is the first. I propose to remove the "type" attribute from the Link object. We currently define two values for this type: <link type="crossconnect"> and <link type="link">. There seem two reasons to distinguish between Links and Cross-connects: 1. Tie a cross connect to a particular switching matrix, so it is clear which switching matrix is providing the transport service. 2. Convey information on the volatility of a link object. A <link type="link"> is pretty static, while a <link type="crossconnect"> is more dynamic, and a client may want to query the status of cross connects more often. It is my opinion that there are better ways to convey the above information, rather then with the 'type' attribute. (Perhaps using a relation between Link and SwitchMatrix and an extension of the Lifetime object). Even thought these proposals have not been made, I think that removing "type" will avoid undeserved expectations. FReek

2 1

Open issues tracker
by Freek Dijkstra 21 Sep '11

21 Sep '11

All, During OGF33 we decided to keep track of open issues and tasks by using the Tracker in Gridforge. Have a look at http://forge.gridforum.org/sf/tracker/do/listTrackers/projects.nml-wg/track… You are cordially invited to shepherd any item that is marked as "New" or "Waiting for Volunteer". Also, if you think of any other tasks or use cases, by all means add them to the tracker. Groet, Freek

1 0

Proposal: Adaptation object and adaptation relation
by Freek Dijkstra 21 Sep '11

21 Sep '11

Here is another proposal, on Adaptation. Serial compound links can be SPECIFIED using a "serial_compound" relation between Link objects. Serial compound links can also be DERIVED from the source and sink relation between Links and Ports. If Link A has sink Port X, and Link B has source Port X, then it follows that Link A and B are placed in series. Proposal: I think we should treat adaptation similar to links. This means that we need two thinks: - a "Adaptation" object that describes the adaptation (data encoding) function between Ports, similar to how a Link describes a data transport function. - a "adaptation" relation between Links, meaning that one Link (on the 'server' layer) provides connectivity to another Link (on the 'client' layer) The adaptation relation can thus be SPECIFIED between Links using a "adaptation" relation, and it can also be DERIVED by considering the source and sink relations between Links and Ports and between Adaptations and Ports. In this proposal, the "adaptation" relation only exists between Links, not between Ports. This is different from the description of adaptation in NDL (which is defined as a Predicate between Interface -- similar to a relation between Ports). Open issues: - it may be confusing to have both a "Adaptation" object and "adaptation" relation with the same name (especially if the "adaptation" relation is between Links, not to/from a "Adaptation" object. I gladly accept proposals for a better name. - Link and Adaptation are similar. Rather than a new object in the UML schema, it is possible to create a common parent class (e.g. create a "DataTransport" class below the "Network Object" class, and make Link and Adaptation class children of "DataTransport"). It may be possible to use the same class for Link and Adaptation (and distinguish between e.g. a "Type" attribute -- and yes, that is ironic, given the proposal in my previous email). I think just adding a new class is easiest, but I gladly hear other opinions. Regards, Freek

1 0

NML-WG sessions at OGF33
by Freek Dijkstra 20 Sep '11

20 Sep '11

To all at not present at OGF 33 in Lyon -- if you like to follow the NML-WG session, please reply to me off-list, and I'll set up a Skype call. The slides will be available at http://www.ogf.org/gf/event_schedule/index.php?id=2350 and at http://forge.gridforum.org/sf/docman/do/listDocuments/projects.nml-wg/docma… The times for the sessions are (Tue 20 Sep): 11.00-12.30 CEST = 9.00-10.30 UTC 14.00-15.30 CEST = 12.00-13.30 UTC (There is a third session, but because of scheduling problems, this is likely to be swapped with Thursday's first NMC-WG session). Regards, Freek

1 0

Registration of URN:OGF
by Freek Dijkstra 17 Sep '11

17 Sep '11

All, Let me give a short report on the status of the URN:OGF:network identifier registration. This registrations involves three documents: 1. Delegation of the urn:ogf namespace to the OGF (this was not the case yet). 2. Put a OGF procedure in place for the registration of subnamespace identifiers. 3. Register urn:ogf:network using this procedure. Last week, the IESG approved the urn:ogf registration, and today IANA registered the namespaces identifier at http://www.iana.org/assignments/urn-namespaces/urn-namespaces.txt. It is expected that the associated RFC will be published within 60 days (it is waiting for details of the following normative reference). It is expected that the document which described the OGF procedure will go in 60-day public comment next week (it is now in GFSG review). After that, it will receive one final GFSG last call before it is published. I'll report on the urn:ogf:network document later. For now, I like to express my gratitude to those who helped publish the first document (the RFC). Given that it may be a simple and non-controversial document, I was pleased to see that so many people took the time to scrutinise the document: Richard Hughes-Jones (co-author) Andre Mersky (setting up the OGF registry) Joel Replogle (setting up the OGF registry) Amanda Baber (IANA) Cindy Morgan (IETF Secretariat) Amy Vezza (IETF Secretariat) Sandy Ginoza (RFC Editor team) And all reviewers: Wesley Eddy (IESG) Brian Carpenter (IETF General Area Review Team) Jeroen van der Ham (NML group member) Russ Housley (IESG chair) Peter Saint-Andre (IETF Applications Area Director, document shepherd) Gunter Van de Velde (IETF participant) Mykyta Yevstifeyev (IETF URN-NID workgroup) Jari Arkko (IESG) Ron Bonica (IESG) Stewart Bryant (IESG) Gonzalo Camarillo (IESG) Adrian Farrel (IESG) Stephen Farrell (IESG) Pete Resnick (IESG) Dan Romascanu (IESG) Robert Sparks (IESG) Sean Turner (IESG) Thanks, Freek

1 0

Spam
by Freek Dijkstra 12 Sep '11

12 Sep '11

Hi all, The amount of spam sent to the NML list has recently increased from 2-3 each week to 5-10 each day. Fortunately, the current filters have caught all spams so far (knock on wood). This means that I'm no longer able to review all e-mails in person. In particular I may miss mails sent from a secondary account, since those will be flagged as "not from a list member". If you have trouble posting, or do not see your email on the list within 10 minutes (check http://www.ogf.org/pipermail/nml-wg/) please contact me off-list, and I'll try to get your message across ASAP. Sorry for the inconvenience, Freek

1 0

Interface vs Port
by Jeroen van der Ham 01 Sep '11

01 Sep '11

Hello, A long time ago we have had a discussion on naming, where we finalized on Nodes and Ports. However, due to feedback that I'm getting in projects where semantic network descriptions are now actually being used, I have received requests to change Port to Interface. The problem is that in these projects the network descriptions become part of a larger infrastructure. Having an object named Port there to describe a network connection point is confusing to users who are not network-centric. They think that a Port object would describe something like a TCP/UDP port, instead of a whole network interface. Would it be possible that NML also changes the Port object to Interface, so as to sync up with the schemas that are already in use in GENI, Geysers and NOVI? Jeroen.

6 11