Meeting notes NML-WG OGF30 ========================== The NML working group had three meetings: - Ad-hoc discussion between 7 participants on Monday - Regular meetings on Wed 27 and Thu 28 Oct. Note takers: Richard Hughes-Jones, Jason Zurawski, Freek Dijkstra Slides: http://forge.gridforum.org/sf/docman/do/listDocuments/projects.nml-wg/docman.root.meeting_materials.ogf30 Participants: Agenda ====== Since no progress presentations were prepared, the agenda was decided upon during the meeting. Procedural: - NML status and Future – Jeroen van der Ham Technical discussion: - Identifier Syntax - Relations - Unidirectional / Bidirectional - Adaptation on Port/Link - Links with Crossconnects - Properties of Relations - Ordering of Links - Channels and Labels NML Status and Future ===================== The group makes progress, but only at face-to-face sessions. Perhaps this is partly due to the technical nature of the working group. We will organise conference calls to see if that helps uptake. By now, the schema is getting in such a shape that it is possible to create early implementations. No organisation has stood up to commit to an implementation yet. This is summarised with this (fictional) discussion: - “Is NML useful to you?” - “Yes, we are going to use it!” - “Great, are you going to implement it?” - “No, we wait for someone else to do it.” ESnet, Internet2, SURFnet and GÉANT3 have expressed interest in an implementation, but need to discuss this internally before they can commit on spending resources. Action: - Jeroen will schedule a teleconference - Jason will ask about whiteboard software (Adobe connect) for teleconference Technical Discussion ==================== Current Schema -------------- The current schema is shown. Not a whole lot will change anymore. Somethings that may change: - Path, does it make sense? - bidirectional link, add, remove, add more things like this? - relations (need more info on them) - Layers - Labels Document -------- Jeroen likes to get some help about the structure of a standards track document. Richard points out that it must be clear which sections are informative and which sections are normative. Jasons proposes to first write an informational document, and only after it is implement, turn into a standards track document. Richard explains a bit more about the standards process as defined in GFD-C.152. Identifier Syntax ----------------- Proposed namespace (after GFD-C.084) is http://schemas.ogf.org/nml/2013/10/base/ Jason counter proposal http://schemas.ogf.org/nml/base/2013/10/ (where 2013/10 is year/month of schema publication) Rough consensus on: - http://schemas.ogf.org/nml/base/2013/10/ (Jason's proposal) In Catania NML decided on Instance identifiers format: urn:ogf:network:: is opaque only processed by end parts GLIF also agreed to use this format. Richard & Freek did put together a doc for the IETF RFC to define the URI Freek has translated to xml but he needs to consult Joel on web site details Case insensitive: RFC says have to specify case sensitive/insensitive So need to define urn:ogf: at OGF level Then :network: and the rest case insensitive. i.e. have to define the lexical equivalence. Rough consensus on: - Different objects eg link and port MUST have different identifiers - instance identifiers are case insensitive - instance identifiers are non-international (thus an URI instead of IRI) - URI are not restricted by length, other than possible restrictions by RFC 2141 (the current GLIF recommendation is max 48 to 80 bytes) Action: - Freek will follow up with Joel, complete the urn:ogf doc and send to RFC editor. - Freek will add the urn:ogf:network syntax to the schema document Relations --------- Rough consensus on: - Everything is just a link – don’t need to distinguish between paths, links and segments. Three relations are defined between links (see slides for details): - serial compound relation concatenation of links in series forming a longer link (on the same layer) (informally: a link is "comprised of" segments) - parallel compound relation aggregation of links in parallel forming a link with higher capacity or redundancy (on the same layer) (informally: a link is "aggregated by" other links) - adaptation relation the offering of a link on a lower layer as a link on a higher layer (informally: a link is "provided by" a link on a lower layer) Examples: - Equal cost multipath is a parellel compound relation - a VLAN over a link is a adaptations relation - A services provided by mutliple SDH VC4 (each taking a different route) is a parallel compound relation. In the case of SDH VC4, the parallel compound relation would have to enumerate all VC4s Discussion indicated that XML parsers may not be ordered – need to solve this for serial compound and parallel compound. Actions: - Jason will check if there is an existing XML syntax to provide ordering. - Jeroen will check if there is an existing RDF syntax to provide ordering. Unidirectional / Bidirectional ------------------------------ (see slides of day 2: NML OGF30 open issues) A bi-directional link is a Group of two uni-directional Link object. A BidirectionalLink is a subclass of the Group object. This allows bidirectional links to be named; no further attributes are defined (yet). Four proposals: 1. Don't subclass the Group, make "bidirectionallink" an attribute of the Group object 2a. Subclass "Group" with "BidirectionalLink", "BidirectionalPort", etc. 2b. Subclass "Group" with "Bidirectional", used for both links and ports. 3. Make "bidirectional" an attribute of a Link, don't use the Group object Jason don’t like concept bidirectional grouping but use a relation – semantic not schema Questions: Is a bidirectional link a first class element - no, its a group thing, it gets a name though. What about multicast - hard problem, need help to sort it out Action: - Freek, Richard will propose description of multicast and broadcast links Rough consensus on: 2a. Subclass "Group" with "BidirectionalLink", "BidirectionalPort", etc. Richards ponders about a (theoretical) use case of a bidirectional link provided by a unidirectional link: two wavelengths (for upload and download respectively) over a single fibre. Freek gives an example how to combine links if we have the bi-directional components: a->b is an unidirectional link b->a is an unidirectional link b->c is an unidirectional link c->b is an unidirectional link Do you: a) combine the ends (a_b and b_c; c_b and b_a), then make a bidirectional link (Group of 2 Serial compound links) b) make 2 bidirectional links (a_b and b_c) and combine those? (Serial compound link of 2 Groups) Rough consensus on: - (a) seems more natural. - Disallow relating groups together until a clear use case and related logic is presented. Adaptation on Port/Link ----------------------- Where do adaptations belong? Use the example from yesterday to illustrate. Do adaptations relate ports (e.g. this is what NDL has done all along) or do they relate links? Or do they relate both? Jason thinks that unless there is a use case where having the adaptation be on the link (and only the link?) it may make sense to define adaptation relations between ports. Otherwise by being on the port there is a transitive relationship (adaptation on port -> adaptation on any [and all] links connected to that port). Some discussion on NSI STB concept (layerless concept - still maps to a port). Freek ponders if an adaptation can be described as a Link object with "adaptation" or "deadaptation" type with source and sink attributes, instead of the current Relation object. Inder ponders if it is possible to extend the use of adaptation relation from data planes to relate service levels as well. Rough consensus on: - Adaptation relates ports, not links. This is still open for discussion. Action: - Jeroen and Jason will be finishing an example the created earlier using both ways (relating ports and relating links) Links with Crossconnects ------------------------ Serial compound = multiple links in series How are these connected? - connectors (plastic) - cross connect within a device Should the cross connect be described in the serial compound link itself? Freek notes that cross connects are current described in the schema as a Link object of type="crossconnect". Rough consensus: - cross connects must be included in a serial compound link - connectors (plastic) can be described as a port, without the need to describe a cross connect Data provenance can be figured out by tracking the source and sink ports of links. Need to explore this idea more. Freek notes that it is theoretically possible to create a serial compound link with two cross connects in the same device. Action: - Freek creates an example of a serial compound with and without a cross connect, and show how a data path can be followed using the source and sink ports. Properties of Relations ----------------------- How to specify the properties of relations? - Types of adaptations, types of protections - Is this an attribute? - more information inside of the element? Need more discussion and use cases to explore these ideas. This discussion is postponed to a later time. Ordering of Links ----------------- How to specify the order in serial compound or parallel compound relationships? XML and RDF are not ordered. In XML, parsers respect 'document order', but this is not required in the specification. XML schema can be used to force ordering of certain elements (w/ different names) How to link? - Ordering attribute? - 'next hop' information Action: - Jason will propose a solution for specifying an ordering in XML - Jeroen will propose a solution for specifying an ordering in XML Channels and Labels ------------------- Jerry/Freek were to look into the topic of Cross connects, channels, labels. Their preliminary work was presented at the previous OGF, no further progress was made. Freek says he is probably not able to work on this topic coming time. NSI will have requirements for channels, labels, ranges. NSI does have a problem statement, including the need to specify label ranges (e.g. VLAN 8 to 312) but has no solution yet. Action: - Tomohiro Kudah will summarise the current NSI specifications and mail them to the NML group. Rough Consensus =============== * Namespace for schema (object and attribute identifiers) is http://schemas.ogf.org/nml/base/2013/10/ (with year and month the date of the actual schema) * Instance identifiers SHOULD follow the urn:ogf:network:domain.name:opaque_id syntax. These identifiers are case insensitive, and non-international. Rough Consensus =============== * Namespace for schema (object and attribute identifiers) is http://schemas.ogf.org/nml/base/2013/10/ (with year and month the date of the actual schema) * Instance identifiers SHOULD follow the urn:ogf:network:domain.name:opaque_id syntax. These identifiers are case insensitive, and non-international. * Instance identifiers are not restricted in length, like GLIF requires. * Different objects eg link and port MUST have different identifiers * Everything is just a link – don’t need to distinguish between paths, links and segments. * "Group" is subclassed with "BidirectionalLink", "BidirectionalPort", etc. * Allow grouping of 2 serial compounds links * Disallow relating groups together until a clear use case and related logic is presented. * Adaptation relates ports, not links. This is still open for discussion. * cross connects must be included in a serial compound link * connectors (plastic) can be described as a port, without the need to describe a cross connect Action Items ============ * Revise definition of multiplexing: Freek, Jeroen * Setup a teleconference: Jeroen * Ask for whiteboard software (Adobe connect) for teleconference: Jason * Specs for delegation of urn:ogf namespace: Freek, Richard, Joel Replogle * Specs for urn:ogf:network identifiers: Freek * Propose description of multicast and broadcast links: Richard, Freek * Create example of adaptation on Port/Link: Jeroen, Jason * Given example of serial compound links with and without cross connect: Freek * How to specify properties of relations: * How to specify the order in relations: Jason (XML), Jeroen (RDF) * Explain NSI requirements/solutions for channels and labels: Tomohiro