Make line-coding-bitrate configurable

[italobusi]

The line-coding-bitrate within the grouping common-transceiver-configured-param should be config true

[italobusi]

Discovered during the WDM call on 18 January, 2024

[sergiobelotti]

@all: The “ common-transceiver-configured-param” has been defined with the scope to report values that are not configured via YANG model, this is what I remind of the initial discussion. For example for line bitrate , operational mode can provide a range of values and the attribute in the grouping reporting the single configured value (that has to be in the range proposed in operational mode). If in the operational-mode is proposed directly a single value, the attribute in the grouping could also not been reported.

It is not in the definition and scope of this grouping to permit the configuration via model. In this case the “config false” statement in line-coding-bitrate would not be a bag but on purpose. Is correct my remind ?

[sergiobelotti]

From Italo: Maybe the confusion is caused by the lack of qualification about which model is implied in this sentence: “It is not in the definition and scope of this grouping to permit the configuration via model”

In the OI topology, all these attributes are instantized as RO independently on how they are defined in the L0 types

This is due to the config false statement defined for the whole transceiver list and IMHO it is correct because the scope of the OI topology is to report how the transceiver has been configured and not to configure the transceiver. So, “It is not in the definition and scope of this grouping to permit the configuration via model” when the model is the OI topology model.

However, the plan was to re-use this grouping also in the WDM interface model and, in this case, the attributes defined as config true in the L0 types shall be instanced as RW since they are intended to be used by the controller to configure the transceiver on the device.

This seems to logic followed for the tx-channel-power which is defined as config true in L0 types such that it can be instantiated as RW in the WDM tunnel model (when properly updated to re-use L0 types definitions) and as RO in the OI topology model (as already done)

The rx-channel-power and rx-total-power are instead defined as config false in L0 types since they can never be configured and therefore they will be instantiated as RO in both the WDM tunnel (when properly updated to re-use L0 types definitions) and the OI topology models (as already done)

The doubt is about the line-coding-bitrate: should it be instantiated as RW or RO in the WDM interface model (when properly updated to re-use L0 types definitions)? If it should it be instantiated as RO, how can the device know how to properly configure the line-coding-bitrate in the transceiver?

When reviewing the YANG code to address this comment, I have got few other doubts on the current YANG definitions ☹

1) Is the tx-channel-power reporting the power values measured by the device (e.g., through an optical power monitor function) or the applied configuration of the tx-channel-power? 2) Are the rx-channel-power and rx-total-power reporting the power values measured by the device (e.g., through an optical power monitor function) or the nominal estimated values by path computation?

[sergiobelotti]

@italobusi : Not clear what do you mean with “the nominal estimated values by path computation”

[sergiobelotti]

@italobusi : Not clear what do you mean with “the nominal estimated values by path computation”

From Italo: Let me take a simpler example to explain my doubt If you request the setup of a TE tunnel/path with a TE delay bound of 10ms, you set 10m in the path-metric-bounds The path computation selects a path and report a delay path-metric of 8ms in the computed-path-properties. This is what I wanted to mean with “nominal estimated values by path computation” Then you enable OAM and you measure the delay along the path and you measure different values (e.g., 8.2ms, 7.9ms, 7.5ms …) at different time

[sergiobelotti]

From Esther: I am not sure I full understand the issue in the discussion here. Here is my understanding:

I assume read-only means that this is data you can not set at the input of your tool, while “read-write” is data you can set as target. Then I think that the fact that data should be read-only or nor depends on use cases.

I can see several use cases for the OI model:

• Representing data extracted from the field. (output data: read-only)
• Feeding topology in a tool (path computation, analysis, …) (input data write data) where topology could be: o Extracted data o Synthetic data o Mixed extracted and synthetic data
• Generating a topology from a tool/ or user (input/output data= read or write) green field or brown field, meaning completely synthetic or mixed data.

In all these use cases, I would prefer to have the same data model (I mean data structure, name of attributes, ..). The fact that these are read-only or read-write data depends on the use case. For example:

• Gain of the amplifier is read-only for the extracted data, but a target data for the input in the computation tool, so a write data. We can to an extensive analysis of each attribute and make a table vs use cases, but at this point, I am not sure if I have correctly listed all use cases. Besides I have the feeling that topology analysis requires everything to be write data. For example:

Regarding rx-channel-power, this is something that is computed with GNPy, but this is not a setting. I mean that I do not expect to set this value as a target when requesting a path computation. In case I would like to set a target for rx-power, then I think I would use rx-channel-power-min and max values. But, In case I use my analyzer tool, I will use the extracted data at the input and the extracted rx-channel-power is then a setting that the analyzer must check 😊

[sergiobelotti]

From Esther: I am not sure I full understand the issue in the discussion here. Here is my understanding:

I assume read-only means that this is data you can not set at the input of your tool, while “read-write” is data you can set as target. Then I think that the fact that data should be read-only or nor depends on use cases.

I can see several use cases for the OI model:

• Representing data extracted from the field. (output data: read-only)
• Feeding topology in a tool (path computation, analysis, …) (input data write data) where topology could be: o Extracted data o Synthetic data SB> What do you mean with Synthetic data ? o Mixed extracted and synthetic data
• Generating a topology from a tool/ or user (input/output data= read or write) green field or brown field, meaning completely synthetic or mixed data. SB> I always thought that OI model should feed path computation , are you ok with that? If that would be the case I would consider the last case as reference

In all these use cases, I would prefer to have the same data model (I mean data structure, name of attributes, ..). The fact that these are read-only or read-write data depends on the use case. For example:

• Gain of the amplifier is read-only for the extracted data, but a target data for the input in the computation tool, so a write data. We can to an extensive analysis of each attribute and make a table vs use cases, but at this point, I am not sure if I have correctly listed all use cases. Besides I have the feeling that topology analysis requires everything to be write data. For example:

Regarding rx-channel-power, this is something that is computed with GNPy, but this is not a setting. I mean that I do not expect to set this value as a target when requesting a path computation. In case I would like to set a target for rx-power, then I think I would use rx-channel-power-min and max values. But, In case I use my analyzer tool, I will use the extracted data at the input and the extracted rx-channel-power is then a setting that the analyzer must check 😊