Can we introduce termination-port in GNPy ROADM attributes ?

[EstherLerouzic]

There is no way today to identify which OMS is reversed from a given OMS on a bidirectional topology. This matching is only implicit: if there is only one OMS from ROADMA to ROADMB, and only one from ROADMB to ROADMA then these two can be associated.
But in case of parallel OMS (several with the same ROADM end points) we have no clue about how the bidir entity should be associated. This is in particular an issue for spectrum assignment, and also for GUI representation if bidir links need to be represented out of a topology.
eg: what is the correct association ? OMS1 + OMS3 or OMS1 + OMS4
OMS1 : ROADMA -->- element1 --- element2 --- element3 --- ROADMB
OMS2 : ROADMA -->- element4 --- element5 --- element6 --- ROADMB
OMS3 : ROADMA --<- element9 --- element8 --- element7 --- ROADMB
OMS4 : ROADMA --<- element12 --- element11 --- element10 --- ROADMB

Since we plan to base the model on the ietf network topology RFC8345, we will benefit from source-tp and dest-tp which can be used to associate links in case of bidir

" An OMS Media link is terminated on both ends by a link termination
point (LTP) as defined in [RFC8345]. Links in optical transport
networks are typically bidirectional but have to be modeled as a pair
of two unidirectional links following the [RFC8345] modeling
approach. Unlike TE links, which are unidirectional, the LTPs on
either end of the TE link pair forming the bidirectional link, are
bidirectional as described in
[I-D.ietf-teas-te-topo-and-tunnel-modeling] and the pair of
unidirectional links are connected to the same bidirectional LTP on
either end of the link pair."

So if we also introduce tp in the ROADM attributes, we may also use the same property, i.e use tp identifier to identify parallel OMS:

for example: it could be a tp dict:

eg
ROADMA
{ tp-c: [element1, element9],
tp-f: [element4, element12] }
ROADMB
{ tp-a: [element3, element7],
tp-b: [element6, element10] }

OMS1 (tp-c) : ROADMA -->- element1 --- element2 --- element3 --- (tp-a) ROADMB
OMS2 (tp-f) : ROADMA -->- element4 --- element5 --- element6 --- (tp-b) ROADMB
OMS3 (tp-c) : ROADMA --<- element9 --- element8 --- element7 --- (tp-a) ROADMB
OMS4 (tp-f): ROADMA --<- element12 --- element11 --- element10 --- (tp-b )ROADMB

[jktjkt]

This sounds related to the per-degree parameters (currently only the launch power) we discussed in #365, where we also indicated that adopting the concept of "ports" is one possibility.

This particular problem, however, can be probably also solved by adding an explicit notion of "bidirectional mapping" to other elments, though (typically to fibers and in-line amplifiers). That way it would be possible to say that element1 and element4 refer to the same fiber pair, and that element2 and element5 are the W->E and E->W stages of the same ILA. I'm not saying that this is better, just offering another (possible) approach. Also, I think this is something that we need to address for the GUI anyway.

Let's talk about this today on the coders call.

[ojnas]

For reference, here is how OpenROADM handles bidirectionality by introducing an "opposite-link" attribute in the network model:

https://github.com/OpenROADM/OpenROADM_MSA_Public/blob/9ae5192c79f9b1bbcefd2344b24a71d55670b02c/model/Network/org-openroadm-common-network.yang#L212