SOme other considerations on unidirectional vs bidirectional Connections and Topology:

1- Unidirectional topology is (IMO) just the atomic construct for an interface.   And as JvdH says, we should be able to construct more complex or capability specific topo components from these atomic elements.

2. Atomic Bidirectional links are problematic.   For path finders, these circuit paths are almost never actually occupying the same physical resources- these are typically paired up elements that have been packaged together for human convenience - not for automated agents.  For example: switches employ [only] unidirectional fabrics internally.   The fabric has a set of input ports and a separate following set of output ports.  The device switches circuits or frames or packets from any input port to a designated output port according to a Look Up Table (LUT).   The design engineers simply relate an arbitrary input port on the fabric with an output port on the fabric, and then connect those two unidirectional ports to a duplex connectors on the faceplate and they call it a single interface with transmit and receive sides.   Even ethernet does this inside a switch, as do routers.
And other technologies - such as optical DWDM platforms - don't even hide this fact...the engineers do everything manually and unidirectionally in the transmit receive optics.    So if we really want to be able to avoid lots of technology specific hacks in the topology descriptions and path finders, we should adopt the unidirectional interface as an atomic element, and then make sure we have appropriate and generalized means of composing other topological service constructs from those atomics.

3. Bidirectional Connections with guarantees capacity/performance will pose scaling problems in the point to multipoint model.    In a mp connection model, the output capacity at any destination endpoint must be the sum of all input capacities of the other endpoints.  This is fine if you have a single source (i.e. unidirectional) p2mp connection.   But in bidirectional mp connections you have multiple sources.   It becomes a mp2mp connection (!!)  (e.g. if 5 endpoints all want to be part of a bidirectional connection, then you have actually created a broadcast domain, a mp2mp tree - not a single source p2mp multicast tree.   And if each of those 5 endpoints want to transmit at 1 Gbps, then it is possible that all endpoints will get 5 Gbps of traffic delivered to them.)  If you do not maintain this summation rule, then you cannot guaranty the performance of the bidirectional Connection under all input conditions - and so it becomes a best effort class of service. (Its starting to sound more and more like conventional ethernet, eh?)   If you can only guarranty best effort for the mp2mp broadcast domain, then there is no real value to requesting a capacity specification in the first place.   Further, if you add an endpoint to a bidir mp2mp connection, you then need to modify all of the existing endpoints and their output segments if you wish to maintain performance guarantees, which becomes totally impractical as the number of endpoints increases or gets large (N^2 problem)

4.  Bidirectional Connections would be better served if we treated them as two unidirectional connections bound together by some specific service constraints constraints that path finders can chew on.  The notion that such circuits transit the "same ports" in both directions is flawed and inaccurate in almost all cases.     For instance, what specifically is our definition of a "bidirectional" NSI Connection?  It does not really occupy the same fibers or ports end to end, and it is often separated by a meter or [much] more distance as it transits different transport kit in the pops.   So what are the specific constraints we feed the path finders that differentiate a "valid" bidirectional Connection layout from an "invalid" Connection path layout?   And if we can define a set of standard constraints that govern the relation between forward and backward paths, do we have those attributes defined in the topology such that path finders can see them and use them?  

I think bidirectional "Connections" (dba mp2mp "Broadcast Domains") are useful - even without capacity guarantees.  These are very practical and useful service constructs (IMO) and it would be good (and easy!) for NSI to support the reservation and provisioning of these.    We can extend the NSI-CS DestSTP semantics to include multiple end points.  These would build a single source tree for unidirectional Connections, with or without capacity guarantees.  And the same Reservation() syntax and semantics can be used to build bidirectional mp2mp Connections - again with capacity (slow and likely to exhaust resources) or without capacity (the b.e. broadcast domain).    The protocol can be extended easily (IMO) to support both modes and maintain backward compatbility to current v2 implementation.

So, the question comes down to this:  Do we really need to differentiate Unidirectional and Bidirectional connection constructs?  Can we simplify to just unidirectional, then build two independent connections going each way?  (Its what happens internally anyway...)   What do we get from a "bidirectional Connection" that you do not get from two "unidirected Connections"?  Its not sufficient to say we want bidir connections because thats what Ethernet does...a) Ethernet does not do this (see above), and b) this makes NSI technology specific rather than "service" oriented.  So what is the service requirement that dictates Bidirectional connections be differentiated from Unidirectional connections? (And how do we define that for PFs?)    Would it not simplify NSI protocol and syntax if we could have only unidirectional connections and we compose more sophisticated services on top of those atomics ?  For instance: "Given circuit A1:=A1>Z1, I would like a circuit A2:= Z2>A2 that is less than "R" radius from A1, AND the circuit A2 has an average latency equal to +/-5% average latency of A1.     Or just the opposite: I want a circuit A2:= A2>Z2 that is greater than "R" radius from this other circuit A1:=A1>Z1.  (The former example would construct a reverse path circuit A2 that is "close" to A1, the latter would construct a diverse circuit A2 that is "far away" from A1.)   My point is that these types of constraint based specifications allow a much richer set of functionality for the user, or for a service provider who wants to compose higher level service constructs  from the NSI base protocols.   These can scale globally so much easier because they do not rely on specific hardware features, traditional human factors, or antiquated service concepts. 

...just some thoughts for discussion next week...:-)
J

On 9/27/13 6:21 AM, Henrik Thostrup Jensen wrote:
On Wed, 25 Sep 2013, Jeroen van der Ham wrote:

Hmm… that seems to be an unneeded artificial restriction.  I should be able to build up my unidirectional topologies into other network constructs based on my needs.  Saying you can only have unidirectional topology is like saying you can paint as much art as you want but only using black.

Agreed 100%.

While most things are unidirectional at the bottom (there are exceptions like true ethers), some equipment can only be controlled from a bidirectional point of view (say, most switches). They are by all accounts bidirectional as that is what can be controlled.

As soon as we would add this construct everyone would just use NML to construct bidirectional topologies, and leaving out the unidirectional part. Then if the need ever arises to do asymmetrical, unidirectional, or disjoint return paths, then you can't because everyone is using bidirectional constructs.

If everyone could just buy ready-made cars, no-one would assemble their own cars or build weird 7-cylinder combustion engines, and very few people would even know how a car worked.


    Best regards, Henrik

 Henrik Thostrup Jensen <htj at nordu.net>
 Software Developer, NORDUnet 


_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg