Merge branch 'master' into master

doc/terminal-device-properties-guide.md

@@ -36,4 +36,94 @@ Manifest files are a special OpenConfig model category since they do not represe
 In order to keep separated them from the rest of operational models, the following openconfig extension is included in the model, to enrich the module metadata:
 ```
   oc-ext:origin "openconfig-properties";
-```
+```
+# Extensions introduced in the v0.2.0 release of the model.
+
+### Motivation
+
+After the initial release of the [openconfig-terminal-device-properties.yang](https://github.com/openconfig/public/blob/master/release/models/devices-manifest/openconfig-terminal-device-properties.yang), there have been significant technical questions and discussions happening within the Telecom Infra Project (TIP) Open Optical & Packet Transport (OOPT) community between operators and vendors.
+
+This issue summarizes the motivation and issues detected in the first release of the model and it will serve as an introduction and motivation of a new pull request (#911) with a new proposed comprehensive update of the model which will be accompanied by the relevant explanations on how the new model proposal will try to overcome the detected issues. It is worth mentioning that the current analysis and the new proposal are the outcomes of an extensive technical discussion within the OOPT community between vendors and service providers and that it consolidates an already discussed proposal starting from the issues and motivations explained here.
+
+### Context
+
+The current proposed terminal-device-properties model was designed with the objective of allowing the terminal devices' system vendors to expose the intrinsic properties (Modulation Format, FEC, Baud-rate) and performance characteristics (Rx-OSNR, CD/PMD limits) of the device's supported transmission modes.
+
+The initial version of the model was designed as a flat list of mode properties, where each entry represents a mode supported by the terminal device and includes the list of characteristics of that mode. However, this initial version presents a significant list of limitations.
+
+### Initial release limitations
+-  **First issue**: The current model exposes a list of modes available in the device, however, the characteristics of a mode of transmission are affected by the HW transceiver supplying it. In other words, two different transceivers (supported by the same terminal device) might support the same mode, but their mode characteristics are different.
+
+<img width="1062" alt="image" src="https://github.com/openconfig/public/assets/10529210/85d8f159-d753-434e-89e3-38a9b24cdd92">
+
+- **Second issue**: There is not an interoperability matrix within the Terminal Device's which exposes the compatibility between Terminal Device's chassis, linecards, transceivers and modes. Right now there is no compatibility information available in the model, to allow the supplier to properly describe which modes are supported by each transceiver module available in the terminal device.
+
+#### Operational challenges
+
+- It is not clear how mode IDs will be assigned and who will assign them.
+- Clarification of the bookended solution target by the model.
+
+### New proposal scope and initial assumptions
+
+Clarify the target of the next extension targets
+
+1. Bookended solutions, and interoperability between terminal devices of the same system vendor.
+2. Interoperability between different system vendors O-OTs through standard modes
+
+### Solution proposed
+
+This pull request covers a proposed solution to the issues described in #910.
+
+The changes to the existing model **are not backward compatible.**
+
+The summary of the changes proposed is the following:
+
+**1. Operational-mode list:** 
+  - The list of the exposed operational modes properties by the Terminal Device is augmented with the set of **CHARacteristic properties** of the operational mode. 
+  - The mode-ids are the same used within the operational datastore of the terminal device (exposed by the [openconfig-terminal-device.yang](https://github.com/openconfig/public/blob/master/release/models/optical-transport/openconfig-terminal-device.yang) model) and have network-wide scope assuming they guarantee interoperability in bookended scenarios (two Terminal Devices of the same system vendor supporting the same mode).
+  - The mode-ids are defined by the system vendor. 
+
+**2. Mode-descriptors list:** 
+ - The **design properties** of the modes, which are dependent on the transceiver component that implements the mode, are exposed as a nested list within the operational mode list. It is assumed that a single operational mode might be implemented by different transceivers which might have associated different design properties exposed by different mode descriptors.
+ - The **mode-descriptor-id** is a local index that does not have interoperability meaning outside the specific Terminal device which reports it. In other words, the same mode descriptors might be exported by different Terminal Devices with different IDs.
+
+**3. Interoperable mode list.**
+ - A given proprietary operational mode might be capable to comply with a certain number of standards or elsewhere publicly defined operational modes defined by other organizations e.g., ITU-T or OpenROADM. 
+ - This compatibility characteristic shall be assured by the system vendor and imply that the design properties of the implementations of that specific operational mode are a superset of all listed supported standard modes.
+ - This model block will replace the previous "G.698.2" node tree with a more generic definition able to accommodate multiple standards or MSA-defined modes.
+
+**4. Transceiver-descriptors list.**
+ - The Terminal Device exposes the list of the transceiver components which are supported by the device.
+ - Each transceiver exposes the list of compatible modes and their associated mode descriptor.
+ - This new model block enhances the previous version by allowing to expose explicitly the compatibility matrix between the Terminal Device, the set of transceiver modules supported and the associated modes supported.
+
+**5. Linecard-descriptors list.**
+ - The Terminal Device exposes the list of linecard components which are supported by the device.
+ - Each linecard component exposes the list of transceivers that are supported.
+ - Each linecard constrains the list of modes that can be supported among the ones supported by the transceiver.
+ - Each linecard constrains the optical-channel configuration, e.g., target-output-power and frequency range.
+ - This new model block enhances the previous version by allowing to expose explicitly the compatibility matrix between the Terminal Device, the line cards, the set of transceiver module per line card and the associated modes supported.
+
+Following the model tree with the 5 blocks described above. In green the new leaves/containers are added in this proposal; in black the non-modified leaves, even if they have been reallocated within the tree under different containers/lists.
+
+<img width="1150" alt="image" src="https://github.com/openconfig/public/assets/10529210/a1810dd0-2e84-40c5-baf4-bfc43aad623c">
+
+For more clarity on the above please check the following common definitions and assumptions defined during the design process of this proposal within the Telecom Infra Project (TIP) OOPT MUST project.
+
+#### Common definitions
+- System-vendor = the O-OT host platform provider (e.g. muxponder shelf, router, switch) and system integrator including the network operating system of the O-OT
+- Manufacturer = Transceiver manufacturer (pluggable)
+- Bookended scenario definition.
+   - The System Vendor is the same in the two O-OTs.
+   - The O-OTs of the same system vendor might host different Transceiver manufacturers.
+   - Mode-ids are defined and maintained by the system vendor.
+   - Interoperability shall be guaranteed by the system vendor if the same mode-id is configured in the line interfaces /optical-channels of the two O-OTs.
+
+#### Assumptions
+- The **openconfig-terminal-device-properties.yang** is a standalone model which represents static properties of a given terminal device, including:
+  - **Operational-modes’ characteristic properties** on the transceiver configuration which characterize the mode (modulation-format, baud-rate, bit-rate, fec-format, filter…)
+  - **Mode-descriptors** which describe the transmission design properties (Tx/Rx properties + CHARacteristic properties) of the implementation of the mode conditioned by the HW platform (transceiver + linecard) (Rx/Tx-OSNR, CD/PMD tolerances, penalties…)
+  - **optical-channel’s configuration constraints** introduced by the HW implementation (min/max-central-frequency, min/max-output-power…)
+- The openconfig-terminal-device-properties.yang is a standalone model representing a given mode’s static properties. We shall avoid any reference btw the manifest files and the operational openconfig trees which change dynamically. In other words, the references between mode-descriptors and operational modes, shall be through absolute identifiers.
+
+

regexp-tests/openconfig-network-instance-types-test.yang

@@ -13,6 +13,7 @@ module openconfig-network-instance-types-test {
     pt:pattern-test-pass "99:4294967295";
     pt:pattern-test-pass "999:999999999";
     pt:pattern-test-pass "9999:99999999";
+    pt:pattern-test-fail "09999:99999999"; // regression: not canonical    
     pt:pattern-test-pass "65535:0";
     pt:pattern-test-pass "59999:65536";
     pt:pattern-test-pass "64999:4294967289";
@@ -24,6 +25,7 @@ module openconfig-network-instance-types-test {
     pt:pattern-test-pass "65535:4289999999";
     pt:pattern-test-pass "65535:4199999999";
     pt:pattern-test-pass "65535:3999999999";
+    pt:pattern-test-pass "65535:2999999999"; // regression: [1-3][0-9]{9}, not just 3[0-9]{9}
     pt:pattern-test-fail "0:4294967296";
     pt:pattern-test-fail "65536:777777";
     pt:pattern-test-fail "65540:777777";
@@ -52,6 +54,7 @@ module openconfig-network-instance-types-test {
     pt:pattern-test-fail "1.1.1.1:65600";
     pt:pattern-test-fail "1.1.1.1:66000";
     pt:pattern-test-fail "1.1.1.1:70000";
+    pt:pattern-test-fail "1.1.1.1:09999"; // regression
     pt:pattern-test-fail "256.255.255.255:99";
     pt:pattern-test-fail "1.1.1.256:99";
     pt:pattern-test-fail "256.1.1.1%eth0:99";
@@ -71,7 +74,9 @@ module openconfig-network-instance-types-test {
     pt:pattern-test-pass "4293999999:65535";
     pt:pattern-test-pass "4289999999:65535";
     pt:pattern-test-pass "4199999999:65535";
+    pt:pattern-test-pass "1999999999:65535"; // regression
     pt:pattern-test-pass "3999999999:65535";
+    pt:pattern-test-fail "3999999999:05535"; // regression
     pt:pattern-test-fail "4294967296:0";
     pt:pattern-test-fail "777777:65536";
     pt:pattern-test-fail "777777:65540";

regexp-tests/openconfig-yang-types-test.yang

@@ -5,6 +5,19 @@ module openconfig-yang-types-test {
   import pattern-test { prefix "pt"; }
   import openconfig-yang-types { prefix "oc-yang"; }
 
+  leaf hex-string-prefixed {
+    type oc-yang:hex-string-prefixed;
+    pt:pattern-test-pass "0x0000";
+    pt:pattern-test-pass "0xffff";
+    pt:pattern-test-pass "0xFFFF";
+    pt:pattern-test-pass "0x0123456789abcdefABCDEF";
+    pt:pattern-test-pass "0xFEDCBAfedcba9876543210";
+    pt:pattern-test-fail "0xg";
+    pt:pattern-test-fail "0xG";
+    pt:pattern-test-fail "0x0123456789abcdefABCDEFG";
+    pt:pattern-test-fail "0xFED0xba9876543210";
+  }
+
   leaf hex-string {
     type oc-yang:hex-string;
     pt:pattern-test-pass "00000";