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