[Nml-wg] bidirectionality (was: NMLify of AutoGOLE topology)

[Jerry Sobieski]

On 2/22/12 3:15 PM, Freek Dijkstra wrote:
> Roman Łapacz wrote:
>
>> btw. I'm still thinking that we don't need nml:bidirectionalport in NML
>> :) We could use port with "bidirectional" relation.
> The distinction between<nml:port type="bidirectional">  and
> <nml:bidirectionalport>  is only syntactic, so I presume you are
> referring to not only change the syntax, but also the semantic. Meaning
> that all the rules and relations that apply to nml:ports can be applied
> to nml:bidirectional ports as well.
>
> Actually, the problem is not so much with bidirectional ports, but with
> bidirectional links.
>
> I personally hope you are right. We identified some issues related to
> identifying the direction (ingress or egress) for physical interfaces
> that did both de-adaptation AND adaptation for ingress traffic (this is
> uncommon, I only know of one practical example). For that reason, we
> decided at the time to do everything unidirectional (so that identifying
> directionality is trivial) and see if we can later come up with either
> syntactic of semantic simplifications for bidirectional links.
>
> I just took another look at the problem we had back than, and I start to
> wonder if the problem is solved because we now use explicit links, and
> we have some basic understanding how to handle multicast and broadcast
> (as links with multiple end-points).
>
> Let me describe the problem we had a few years ago. If you have time to
> propose a solution, and it works with the following three examples,
> that's a good indication for me that we can make it work, and I would
> back up your proposal.
>
> If you make a proposal, make sure to do it in the UML schema, since that
> is leading.
>
> 1. A link between one network that described all links unidirectional
> and another network that describes all links bidirectional.
>
> 2. A link with more than two end-points, such as a Ethernet LAN or VLAN
> (this one is probably easy).
>
> 3. How to describe a physical interfaces that did both de-adaptation AND
> adaptation for ingress traffic. The only example I know is an Ethernet
> interface in a SONET switch. Here, the Ethernet traffic is first
> de-adapted from the fiber layer (e.g. using 1000base-LR decoding), and
> than, //at the same interface// adapted to the VC-4 layer (e.g. using
> GFP-F encoding or the older LEX encoding). The questions are:
> a) how to make the distinction between the link on the ingress and
> egress side of an such an interface, and
> b) the distinction between the adaptation stack on the ingress and
> egress side of such an interface.
This is where abstraction comes in.  Those de-adaptations and 
adaptations are all functional network elements.  They can be engineered 
topologically just like other devices and preserve your notions of port 
orientation etc.  Granted, some are virtual elements but the point 
remains - they can easily be represented topologically.  Right?

The real issue here is that in order to describe these details, you *DO* 
in fact end up reverse engineering all the hardware.  And it gets very 
complex and increasingly difficult to represent in a generalized manner 
all that detail...you could get down to the gate level if you keep 
going.   It becomes increasingly difficult for pathfinders to model this 
much varied detail. (Imagine all the 1000-baseLR adaptations that occur 
on a campus...is this detail truly necessary for a pathfinder to know in 
another country on the otehr side of the world?  There needs to be a way 
of accounting for the function without actually having to model it 
generically externally.

At some level, you simply have to glom all these internal functions 
together into a single opaque object and say "I cannot or will not 
represent these internal details topologically, so here is an active 
agent you can send your requirements to and *it* will magically do it 
for you - or tell you it can't be done."     The rub is that the remote 
pathfinder still needs to know conclusively the input state and output 
state.  Thus you need a means of specifying the ports - but not the 
internals. I.e. you define the interfaces to the service domain rather 
than the internals of the service domain.

This is how NSI functions.
>
> Use case 3 is rather complex, so I made a picture, see attached (it's
> still complex, so I'm happy to explain in more detail if required). As
> you can see, on the Ethernet layer, there is a direct link between port
> C1 and D2 (thus NOT between C2 and D1 as is the case on the fiber
> layer). Data coming in at C1 from either A1 or B1 is really different
> from data coming in from D2. For use case 3a, how do the links and ports
> look like when described on the Ethernet layer (without describing the
> underlying fiber infrastructure). Would be possible to distinction to
> describe the connections A1, B1 and C2? For use case 3b, how to describe
> the links, ports and adaptation if only the fiber layer and adaptations
> are described, but the Ethernet layer is not explicitly defined (but
> should be inferred from the underlying infrastructure on the lower layer).
Is your diagram then a bidirectional diagram?   It seems to me this 
should really be a diagram of unidirectional links to avoid asymetric 
and diverse connectivity issues.
> Regards,
> Freek
>
>
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/c1b0feaa/attachment.html>