Proprietary (or new) modulation format in openconfig-terminal-device-properties
Closed this issue · 4 comments
We are trying to figure out how to define proprietary or new modulation formats that are not currently defined in the model for use in a transponder implementation.
The model for modulation format is a union of a string and typedef/identity.
leaf modulation-format {
type union {
type string;
type oc-opt-term-prop-types:modulation-format;
}
description
"Optical modulation format associated to the mode. The
modulation format associated to the optical signal.";
}
The model also defines an identity MODULATION_FORMAT_PROPRIETARY.
It seems like there are a few options:
a) vendors can define a vendor specific string for the new modulation format
b) vendors can use "MODULATION_FORMAT_PROPRIETARY" as the modulation format
c) vendors can define a new identity for the modulation format in the vendor namespace using MODULATION_FORMAT as the base
d) vendors can define a new identity for the modulation format in the vendor namespace using MODULATION_FORMAT_PROPRIETARY as the base
Note: our preference would be to avoid (b) as this loses any distinction if the vendor supports multiple modulation formats that are currently not defined in the model.
Is there a recommendation from the OC community on which approach would be the preferred approach for adding vendor proprietary modulation formats?
Generally speaking, we have seen vendors provide vendor proprietary YANG augments to the openconfig models to expand them to include vendor specific configuration and telemetry.
@ejbrever for additional insights
@dplore
However, in this case it seems like there are 3 different ways that I can augment:
- use the string value to define vendor custom modulation formats
- create a new identity built off the MODULATION_FORMAT base identity in a vendor augment file (vendor namespace)
- create a new identity built off the MODULATION_FORMAT_PROPRIETARY identity as base type also in a vendor augment file.
I was wondering if the author of this model had any thoughts on which mechanism would be preferred.
Or is it up to the vendor to just choose one of the three options.
Ah, so the reference to the modulation above is within the device manifest directory. This isn't for use for configuring devices, but rather can be thought of as a way to get read-only data (i.e. documentation or white paper type data). Not sure if that is what you are after, but since you mentioned "transponder implementation" it sounded like you might have interest in the config side?
For configuring a device's line port configuration, the operational-mode is what is used:
This operational mode is essentially a mapping of line port config to an int. Generally, vendors have wrapped FEC, modulation, and baud rate into this, but it can include more in theory if a vendor wants. They then provide us documentation that gives us this mapping. For example, it might say operational-mode 10 == 64QAM, SDFEC, 200G. This allows vendors to not be tied to OC yang models as these settings have become highly proprietary over the years and we wanted to limit any dependencies by coupling new line port technology/features with OC model identityrefs. As long as they tell us the mapping we can easily translate this to what we need. Hope this helps.
This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.