Examples of how vendors can define their operational modes.

[italobusi]

Based on this change, one or two examples shall be put into an Appendix of draft-ietf-ccamp-optical-impairment-topology-yang explaining how vendors can define their operational modes.

_Originally posted by @dieterbeller in https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/pull/70#discussion_r1256001718_

[dieterbeller]

Text proposal:

Appendix C.  Examples How to Use the organizational-mode Attribute

   One option to describe the transceiver capabilities of an optical
   transponder (supported-mode list in the supported-modes container as
   defied in [I-D.ietf-ccamp-rfc9093-bis]) is to describe the
   organizational-modes a transceiver supports as described in section
   Section 2.6.2.

   [I-D.ietf-ccamp-rfc9093-bis]) defines the operational-mode of type
   identityref, which means that the identity the operational-mode
   attribute is referring to needs to be defined in a separate
   organization-specific or vendor-specific YANG module.  An example of
   such an organization-specific YANG module as well as a vendor-
   specific YANG module is provided below.

   YANG module example containing the identity definition for a 400G
   operational-mode specified by the organization Forum A:

   module forum-a-operational-modes {
     yang-version 1.1;

     import "ietf-layer0-types"{
       prefix "id-base"};

     namespace "urn:forum-a:example:forum-a-op-modes";
     prefix "op-modes";

   …

     identity 400G-operational-mode {
       base "id-base:operational-mode"
         description "400G mode specified by Forum A.";
     }

   …

   }

   YANG module example containing the identity definition for a 400G
   operational-mode specified by the organization Vendor B with the same
   identity name "400G-operational-mode" as an operational mode that
   specified by Forum A.

   module vendor-b-operational-modes {
     yang-version 1.1;

     import "ietf-layer0-types"{
       prefix "id-base"};

     namespace "urn:vendor-b:example:vendor-b-op-modes";
     prefix "op-modes";

   …

     identity 400G-operational-mode {
       base "id-base:operational-mode"
         description "400G mode specified by Vendor B.";
     }

   …

   }

   If there are transceivers in a network that are supporting any of the
   two 400G operational modes, the one specified by Forum A or the one
   specified by Vendor B or even both, the different name spaces allow
   to unambiguously identify the two modes that are defined in the YANG
   modules above with exactly the same identity name.

   The NETCONF server providing the optical impairment-aware topology
   will have to support both YANG modules above and will have to
   advertise both as capability in the NETCONF hello message indicating
   that these operational mode identities are used in the description of
   the optical impairment-aware topology model defined in this document.

@italobusi , @sergiobelotti could you please review the text proposal above.

[ggrammel]

Would this approach still work if a single TXP supports both modes, each being identified with the same identity 400G-operational-mode?

TXP-AB:

• description "400G mode specified by Forum A."
• description "400G mode specified by Vendor B."

[dieterbeller]

Would this approach still work if a single TXP supports both modes, each being identified with the same identity 400G-operational-mode?

TXP-AB:

* description "400G mode specified by Forum A."

* description "400G mode specified by Vendor B."

yes, the different name spaces allow to distinguish the two operational modes with the same identity name (even though it is very unlikely). @sergiobelotti explained that during his presentation at IETF 117 (see IETF 117 slide deck). This new appendix just describes what has been presented at IETF 117.

draft text --> "the different name spaces allow to unambiguously identify the two modes that are defined in the YANG modules above with exactly the same identity name."