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@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg