[Nml-wg] Notes on NML sessions at OGF 35

[Freek Dijkstra]

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