Hi Freek/All; On 3/28/12 5:30 AM, thus spake Freek Dijkstra:

Jeroen van der Ham wrote:

...

We'll be discussing most of the issues I sent out earlier. Freek will followup with a more detailed list soon.

We propose to discuss the following topics: * implicit hasTopology relation between Topology and (sub)topology artf6537

https://forge.ogf.org/svn/repos/nml-examples/201203-subtopology/hasTopology.... (proposal #2 and optional #1)

Since I won't be on the call, I include the exchange from early May via email in this ticket, and my commentary to the various proposals.

* 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)

Commentary on this also in the notes/email exchange, and included in artifact 'artf6537'

* name of the serial compound relation is "isSerialCompoundLink" https://forge.ogf.org/sf/go/artf6545 https://forge.ogf.org/sf/go/artf6510 (related)

https://forge.ogf.org/svn/repos/nml-examples/201203-vlans/compoundlink.xml (first question at footer)

This is fine by me.

* What is the direction and name of the relation between Port and Link? https://forge.ogf.org/sf/go/artf6538 (second part)

https://forge.ogf.org/svn/repos/nml-examples/201203-vlans/compoundlink.xml (second question at footer) (this needs some further explanation, I'll provide that shortly)

Being consistent is what would prefer, either: - we always use the same 'direction' but multiple works (is/has) - We always use the same word (has or is) and that may imply different directions I can get used to either I suppose.

* 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

These proposals were fine with me, the only extra comment I could add is if we need to be 'naming' (assigning IDs) to bidirectional ports and links for later use. Thanks; -jason

Sorry for the delay. I was too tired yesterday, and found that not all issues have an artifact, and a few duplicate artifact were created, and some artifacts cover two items. I'll try to correct this in a few hours time and post a full proposal.

Freek

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.... (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: ... ... 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: ... ... 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: 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_opt... Example: nml:nameVLAN 42 true 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