|
|
|
Freek Dijkstra: 07/11/2012 4:32 PM EDT
|
| |
Action: |
Update
Closed set to 07/11/2012
Status changed from Last Call to Completed
|
|
|
Jeroen van der Ham: 03/29/2012 11:38 AM EDT
|
| |
Action: |
Update
Status changed from Under discussion to Last Call
|
|
|
Jason Zurawski: 03/28/2012 7:08 AM EDT
|
| |
Comment: |
As stated, I do not have a strong reason to oppose, so inbound/outbound is fine.
I will have to side with Freek instead of Roman on this one, bi-directional port is not a first class element (its a group). Therefore this makes the
most sense to me:
Node -> (Unidirectional) Ports
BidirectionalPort -> (Unidirectional) Ports
|
| |
Action: |
Update
|
|
|
Freek Dijkstra: 03/28/2012 4:08 AM EDT
|
| |
Comment: |
Jason, you claim that "the [direction of a port] could be derived from other information in the description"
Usually, yes. However, not always. Imagine a Node with two interfaces: one ingress, the other egress. With the "hasPort" relation between the Node and
both Port, it is unclear which one is which. With the hasInboundPort and hasOutboundPort, this is obvious.
Also, I have to note that this proposal conflicts with a proposal that Roman suggested: he preferred to specify the following relation hierarchy:
Node -> BidirectionalPort -> (Unidirectional) Ports
This proposal instead relates:
Node -> (Unidirectional) Ports
BidirectionalPort -> (Unidirectional) Ports
I personally like Romans proposal, but found that it did not work as I hoped. Imagine the scenario:
Node A -> BidirectionalPort B
Link X -> BidirectionalPort B
BidirectionalPort B -- (inbound) -> Port P1
BidirectionalPort B -- (outbound) -> Port P2
In this case it is unclear if P1 is inbound with respect to the Node or to the Link.
|
| |
Action: |
Update
|
|
|
Freek Dijkstra: 03/28/2012 3:53 AM EDT
|
| |
Comment: |
Full proposal:
Inbound/Outbound Ports
======================
https://forge.ogf.org/sf/go/artf6539
https://forge.ogf.org/svn/repos/nml-examples/201203-subtopology/inbound-outbound-ports.xml (proposal #3)
Summary: It is useful to specify the direction of a port: ingress or egress with respect to a Node or Topology.
Proposal:
* use hasInboundPort or hasOutboundPort to relate a Node/Topology/Service to a Port.
Example:
<nml:Node id="urn:ogf:network:internet2.edu:2012:rtr.atla.net">
<nml:Relation type="hasInboundPort">
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-6-0-0_in" />
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-7-0-0_in" />
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-8-0-0_in" />
</nml:Relation>
<nml:Relation type="hasOutboundPort">
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-6-0-0_out" />
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-7-0-0_out" />
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-8-0-0_out" />
</nml:Relation>
</nml:Node>
<!-- optional grouping of ports as a bidirectional ports (not part of the proposal) -->
<nml:BidirectionalPort id="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-6-0-0">
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-6-0-0_in" />
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-6-0-0_out" />
</nml:BidirectionalPort>
<nml:BidirectionalPort id="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-7-0-0">
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-7-0-0_in" />
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-7-0-0_out" />
</nml:BidirectionalPort>
<nml:BidirectionalPort id="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-8-0-0">
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-8-0-0_in" />
<nml:Port idRef="urn:ogf:network:internet2.edu:2012:rtr.atla.net:ge-8-0-0_out" />
</nml:BidirectionalPort>
|
| |
Action: |
Update
Assigned To set to Freek Dijkstra
Category changed from Procedural to – Device / Node / Port
Status changed from New to Work in Progress
|
|
|
Jason Zurawski: 03/27/2012 7:34 PM EDT
|
| |
Comment: |
I don't have a strong opinion on this issue. The changes seem fine to me, but the information we want (direction of a port) could be derived from
other information in the description.
|
| |
Action: |
Update
|
|
|
|
|
|
