[Nml-wg] NML call on March 29th

Wed Mar 28 09:12:17 EDT 2012

As promised, some clarification:

If you only have a short comment, would you be so kind to do so at the
artifacts tracker whose URL is listed?

For a discussion, you can of course use the mailing list.

Implicit relations
==================

> * implicit hasTopology relation between Topology and (sub)topology
>   https://forge.ogf.org/sf/go/artf6537
>   https://forge.ogf.org/svn/repos/nml-examples/201203-subtopology/hasTopology.xml
>   (proposal #2 and optional #1)
> 
> * implicit hasNode relation between Topology and Node
>   (no artifact created)
>   https://forge.ogf.org/svn/repos/nml-examples/201203-subtopology/hasNode.xml
>   (proposal #1 and optional #3)

Summary: We need to relate Topology with a Node (meaning that the
topology contains a Node), and related a Topology with a Topology
(meaning that the topology contains a subtopology).

Proposal: In XML, we allow (1) implicit relations; in RDF it is required
to use an explicit relation.

Example:

XML:
<nml:Topology id="urn:ofg:network:example.net:2012:mynetwork">
  <nml:Node id="urn:ofg:network:example.net:2012:mynode1">
    ...
  </nml:Node>

  <nml:Topology id="urn:ofg:network:example.net:2012:location1network">
    ...
  </nml:Topology>
</nml:Topology>

RDF:
@prefix exnet <urn:ofg:network:example.net:2012> .
exnet:mynetwork  nml:hasNode      exnet:mynode1
exnet:mynetwork  nml:hasTopology  exnet:location1network

Open question (1):
It is unclear if in XML, the relation MUST be implicit, or MAY be implicit.

Thus: it is clear that the above is allowed. But it is unclear if the
following if also allowed or explicitly forbidden:

<nml:Topology id="urn:ofg:network:example.net:2012:mynetwork">
  <nml:Relation type="hasNode">
    <nml:Node id="urn:ofg:network:example.net:2012:mynode1">
      ...
    </nml:Node>
  </nml:Relation>

  <nml:Relation type="hasNode">
    <nml:Topology id="urn:ofg:network:example.net:2012:location1netw">
     ...
    </nml:Topology>
  </nml:Relation>
</nml:Topology>

Choices:
1a) Explicit hasNode and hasTopology relation is forbidden in NML
1b) Explicit hasNode and hasTopology relation is allowed in NML,
    but deprecated in favour of an implicit relation.

Name of Serial Compound Relation
================================

> * name of the serial compound relation is "isSerialCompoundLink"
>   https://forge.ogf.org/sf/go/artf6545
>   https://forge.ogf.org/svn/repos/nml-examples/201203-vlans/compoundlink.xml
>   (first question at footer)

I think we already have a collective "sigh, it's ugly, but can we please
move on" on this one, so I won't waste more text :)

Summary: Can we move on?

Proposal: Can we move on?

Example: Can....

Direction of Port-Link Relation
===============================

> * What is the direction and name of the relation between Port and Link?
>   https://forge.ogf.org/sf/go/artf6550
>   https://forge.ogf.org/svn/repos/nml-examples/201203-vlans/compoundlink.xml
>   (second question at footer)

This one was brought up by Jeroen, and backed by Roman at OGF34.

Summary: We need to define a two relations between port and link: for
traffic from port to link, and for traffic from link to port. (aka
source and sink relations).

Proposal: Use a "isSource" and "isSink" relation to relate a Port to a Link.

Semantics:
  Port A --(isSource)-> Link X
   means: there is a traffic flow from Port A to Link X.
  Port B --(isSink)-> Link X
   means: there is a traffic flow from Link X to Port A.

Note: this is contrary to how we currently related Ports and Links:
  Link --(hasSource)-> Port
  Link --(hasSink)-> Port
The rationale is that this proposal provides a "hierarchy" of relations:
  Topology --> Node --> Port --> Link

Example:

XML:
<nml:Port id="urn:ogf:network:example.net:2012:PortA">
  <nml:Relation type="isSource">
    <nml:Link idRef="urn:ogf:network:example.net:2012:LinkX"/>
  </nml:Relation>
</nml:Port>
<nml:Port id="urn:ogf:network:example.net:2012:PortB">
  <nml:Relation type="isSink">
    <nml:Link idRef="urn:ogf:network:example.net:2012:LinkX"/>
  </nml:Relation>
</nml:Port>

RDF:
@prefix exnet <urn:ofg:network:example.net:2012> .
exnet:PortA  nml:isSource   exnet:LinkX
exnet:PortB  nml:isSink     exnet:LinkX

VLAN
====

> * VLAN is a link with multiple source and multiple sink ports,
>   and optional parameter noReturnTraffic
>   https://forge.ogf.org/sf/go/artf6503
>   https://forge.ogf.org/sf/go/artf6542 (duplicate)
>   https://forge.ogf.org/svn/repos/nml-examples/201203-vlans/vlan-link.xml

Summary: We want to describe a LAN (or VLAN) between Nodes

Proposal: Use a single Link object, with multiple sources and sinks, and
an optional parameter "noReturnTraffic" to signify that

Rationale: A LAN is basically a broadcast domain, with multiple Ports.
The "noReturnTraffic" is an optimisation in present (switched) networks,
and seems the easiest way to describe the special case that no traffic
flows back to it's source, like it used to in a old LAN with HUBs. The
idea to put this in parameters comes from OGF 33:
https://forge.ogf.org/svn/repos/nml-examples/201109-switchservice/2vlans_option1.xml

Example:
<nml:Port id="urn:ogf:network:example.net:2012:PortAsrc">
  <nml:Relation type="isSource">
    <nml:Link idRef="urn:ogf:network:example.net:2012:VLAN42"/>
  </nml:Relation>
</nml:Port>
<nml:Port id="urn:ogf:network:example.net:2012:PortAsink">
  <nml:Relation type="isSink">
    <nml:Link idRef="urn:ogf:network:example.net:2012:VLAN42"/>
  </nml:Relation>
</nml:Port>
<nml:Port id="urn:ogf:network:example.net:2012:PortBsrc">
  <nml:Relation type="isSource">
    <nml:Link idRef="urn:ogf:network:example.net:2012:VLAN42"/>
  </nml:Relation>
</nml:Port>
<nml:Port id="urn:ogf:network:example.net:2012:PortBsink">
  <nml:Relation type="isSink">
    <nml:Link idRef="urn:ogf:network:example.net:2012:VLAN42"/>
  </nml:Relation>
</nml:Port>
<nml:Port id="urn:ogf:network:example.net:2012:PortCsrc">
  <nml:Relation type="isSource">
    <nml:Link idRef="urn:ogf:network:example.net:2012:VLAN42"/>
  </nml:Relation>
</nml:Port>
<nml:Port id="urn:ogf:network:example.net:2012:PortCsink">
  <nml:Relation type="isSink">
    <nml:Link idRef="urn:ogf:network:example.net:2012:VLAN42"/>
  </nml:Relation>
</nml:Port>
<nml:Link idRef="urn:ogf:network:example.net:2012:VLAN42">
  <nml:name>VLAN 42</nml:name>
  <nml:parameter name="noReturnTraffic">true</nml:parameter>
</nml:Link>

Note: the concept of using a nml:parameter is in-scope of this proposal.
The exact XML representation of the nml:parameter is out-of-scope, and
may be discussed later, if the WG prefers so.

Note: I used the isSource/isSink relation rather than the
hasSource/hasSink relation.

Regards,
Freek