openconfig
CLEI-code
https://github.com/openconfig/public/issues/626
@dplore @earies Can you please review?
@ejbrever -- I see that there is one implementation linked from the issue specified. Could we link others here too please?
@robshakir sure, I linked a couple other implementations in the issue as well that were publicly accessible. I believe all optical vendors (at least the ones I have worked with) support CLEI codes, although most of the documentation is not publicly accessible.
I would then also question about CLLI to allow configuration for location that is related to CLEI based on Telcordia closed specifications. These originated prior to the divesture of A&T and are largely US telco requirements that pertain to a small subset of providers and deal with inventory and asset management that are best left to other backend systems as these attributes are of practical use by operations and teams dealing with the management and operational state of the device. The vendors selling to these telco provides are required to provide CLEI like larger router and optical vendors who also still use outdated TL1 protocols for management and configuration. Can these be provided, yes, but should they as the industry moves forward with increasing virtualization where these do no apply?
@osquitun, I am okay either way with CLLI as well. CLEI and CLLI I think also present two different problem spaces for me.
With CLLI, from the device's perspective, this is just a random string as it doesn't know or care where it physically is located. You may have to configure it, but ultimately it doesn't drive any meaningful changes on the device.
With CLEI, I do worry if this is offered as a config leaf that it might get used one day by an implementation to drive configuration. It is also a special piece of information that the platform knows already and that operators would not know without digging into the platform's documentation.
For those reasons, I am okay with both of these ending up in OpenConfig. However, CLEI should only be a state leaf, where CLLI should be config and state.
- Side note...I have no intentions of adding CLLI into this PR :)
@ejbrever can you reference at least two vendors that support providing CLEI data? Ideally you could provide a link to documentation showing these vendors support this information.
Also note, you'll need to rebase/merge this PR to catch it up with recent contributions.
@dplore sure. Most (if not all) optical platforms support CLEI codes. A couple references: Cisco: https://www.cisco.com/c/en/us/support/docs/optical-networking/ons-15454-sonet-multiservice-provisioning-platform-mspp/46247-15454-cleicodes.html Nokia: https://documentation.nokia.com/html/365-372-324R10.0/index.html?i=365-372-324R10.0-qzx79
LGTM, but need a version bump:
⛔ submodule versions must match the belonging module's version module set openconfig-platform is at 0.17.0 (openconfig-platform.yang), non-matching files: openconfig-platform-common.yang (0.16.0)