OpenROADM / OpenROADM_MSA_Public

Open ROADM MSA
http://www.openroadm.org/
61 stars 77 forks source link

network model and inline amplifiers (ILA) #43

Open ojnas opened 4 years ago

ojnas commented 4 years ago

The openroadm-network model augments the network node with management level attributes such as vendor and model. But ILAs are not network nodes in this model since there is no ILA network node type. Has it been considered to enable representation of such management level information also for ILAs in the network model or is this not thought of as needed?

orenais commented 4 years ago

Yo are right. We did not want to see Amplifiers appearing in the topology as nodes to simplify the path calculation. So details about amplifiers are included under the amplified-link-container. This includes a certain number of parameters to qualify the configuration settings of the amplifiers. We don't see the vendor as a needed information. Thus we prefer to define a "type" (we will enrich the defined types when adding amplifiers with different specifications and operating ranges) rather than "model".

ojnas commented 4 years ago

I understand that you don't want ILAs in the topology used for path calculation but in my understanding the openroadm-topology model is used for this, not openroadm-network. What I don't fully understand is why e.g. vendor and model is needed for ROADMs and Xponders but not for ILAs.

orenais commented 4 years ago

We want to keep the model as simple as possible, to limit the number of information we keep in the MDSAL (for controllers based on ODL). This is for scalability reasons. OR-topology introduces a second level of disaggregation : so it corresponds to OpenROADM -network where ROADMS are disaggregated, splitting them into degrees and SRGs. It also includes links. So, you are right, path calculation is based on or-topology, which includes more details than or-network. As amplifiers have been introduced at the link level, we don't have them in or-network. And we don't have any reason to make them appear in this layer. The models currently include vendor and model for Xponders, at the node level (in openroadm-network). It is there, in case we would need a this information. Currently we don't use it in transportPCE. This does not mean it is not used in other controller. AMmplifier have been added in a second step. as they don't appear at the node level, we do'nt have this information for them. We absolutely don't want to see them in OpenROADM -network, because we don't want to overload the global topology. We could add this parameter to see it appearing at a different level, but the real question is do we really need it? OpenROADM includes not only models but also specifications. This brings real interoperability. Then we made the model with a certain number of parameters that may be needed for adjustment. At that time we did not identify the need for having vendor and model information for amplifiers. I agree on the the fact that we don't have the same level of information as for xponder and roadms. OpenROADM works in a way where we try to build fast. then we refine, if needed the model. So if we see at a time that we have use cases that implies to know vendor and models for amplifier we will add it. Do you have any idea about such use cases?