Merge branch 'master' into ifsubif

.github/CODEOWNERS

@@ -6,3 +6,4 @@
 # the release/models directory (all YANG content)
 # is maintained by the public-writers OpenConfig team. 
 /release/models/ @openconfig/public-writers
+/release/models/wifi @mike-albano

cloudbuild.yaml

@@ -32,23 +32,23 @@ steps:
 
 ############### COMMON PREP ###############
 # Create GOPATH
-- name: 'gcr.io/cloud-builders/go:debian'
+- name: 'golang'
   entrypoint: 'bash'
   args: ['-c', 'mkdir -p /go/src/github.com/openconfig']
   volumes:
   - name: 'gopath'
     path: /go
   id: 'go path creation'
 # Clone CI repository
-- name: 'gcr.io/cloud-builders/go:debian'
+- name: 'golang'
   entrypoint: 'bash'
   args:
   - '-c'
   - |
     git clone git@github.com:openconfig/models-ci.git /go/src/github.com/openconfig/models-ci
     cd /go/src/github.com/openconfig/models-ci
     # Modify the major version to update models-ci version.
-    branch=$(git tag -l 'v7*' | sort -V | tail -1)
+    branch=$(git tag -l 'v8*' | sort -V | tail -1)
     git checkout $branch
   volumes:
   - name: 'ssh'
@@ -57,11 +57,11 @@ steps:
     path: /go
   id: 'models-ci clone'
 # Get CI script dependencies
-- name: 'gcr.io/cloud-builders/go:debian'
-  args: 
-  - 'get'
-  - './cmd_gen'
-  - './post_results'
+- name: 'golang'
+  entrypoint: 'go'
+  args:
+  - 'install'
+  - './...'
   volumes:
   - name: 'ssh'
     path: /root/.ssh
@@ -72,7 +72,7 @@ steps:
   dir: '/go/src/github.com/openconfig/models-ci'
   id: 'models-ci dep'
 # Generate validator scripts
-- name: 'gcr.io/cloud-builders/go:debian'
+- name: 'golang'
   entrypoint: 'bash'
   args:
   - -c
@@ -97,7 +97,7 @@ steps:
 
 ############### REGEXP TESTS ###############
 # Clone CI repository
-- name: 'gcr.io/cloud-builders/go:debian'
+- name: 'golang'
   entrypoint: 'bash'
   args:
   - '-c'
@@ -115,8 +115,9 @@ steps:
   waitFor: ['validator prep']
   id: 'regexp clone'
 # Get regexp dependencies
-- name: 'gcr.io/cloud-builders/go:debian'
-  args: ['get', './...']
+- name: 'golang'
+  entrypoint: 'go'
+  args: ['install', './...']
   volumes:
   - name: 'gopath'
     path: /go
@@ -169,7 +170,7 @@ steps:
   id: 'yanglint'
 
 ############### MISC-CHECKS ###############
-- name: 'gcr.io/cloud-builders/go:debian'
+- name: 'golang'
   entrypoint: 'bash'
   args: ['-c', "/go/src/github.com/openconfig/models-ci/validators/misc-checks/test.sh"]
   secretEnv: ['GITHUB_ACCESS_TOKEN']
@@ -207,14 +208,14 @@ steps:
   id: 'oc-pyang'
 
 ############### GOYANG/YGOT ###############
-- name: 'gcr.io/cloud-builders/go:debian'
-  args: ['get', 'github.com/openconfig/ygot/generator']
+- name: 'golang'
+  entrypoint: 'go'
+  args: ['install', 'github.com/openconfig/ygot/generator@latest']
   volumes:
   - name: 'gopath'
     path: /go
   env:
   - 'GOPATH=/go'
-  - 'GO111MODULE=on'
   waitFor: ['go path creation']
   id: 'goyang-ygot prep'
 - name: 'gcr.io/$PROJECT_ID/models-ci-image'

doc/terminal-device-properties-guide.md

@@ -0,0 +1,39 @@
+# Openconfig Terminal Device Manifest files guidelines
+
+**Contributors:** Arturo Mayoral López de Lerma
+
+This page documents the purpose and usability guidelines for the openconfig-terminal-device-properties.yang and openconfig-terminal-device-property-types.yang models included in openconfig/devices-manifest folder. These models enter in the category of devices manifest files, which is a new category of openconfig models which are intended to expose the static properties of a devices, which are traditionally documented by the device's manufacturers in the product datasheets. These properties are typically required by network planning teams to plan the network deployments.
+
+# Motivation
+
+Current optical transport networks are evolving into new degrees of openness and flexibility, where the optical terminal units become more and more independent from the rest of the DWDM line system, management and control. This means for instance that an optical terminal device, i.e., a transponder/muxponder device can be deployed as a standalone unit and connected to the line system of a third-party provider. In order, to make this type of integrations efficient, the optical channel signal characteristics can be exposed through the management interface (i.e., through OpenConfig models in this case), to allow the remote controller entity to ingest the required data for successful optical planning and impairment validation of the end-to-end transmission across the Optical Line System (OLS). This intends to remove ambiguity on how suppliers expose data required for network planning and physical impairment validation of end-to-end Optical Channels (OCh/OTSi) and foster openness across the optical transport industry.
+
+Currently in OpenConfig, the optical channels characteristics are opaque to some extent and the model only offers an abstraction named 'operational-mode', which allows the manufactures to encode the different transmission modes supported by the device into a single integer value. While this may be sufficient in some cases (the manufacturer can offer the related mode details offline to its customers), and very practical for configuration purposes, it becomes cucumbersome for an network operator to encode this information into their network controller application, specially if the network contains many different vendor solutions which may expose their signal characteristics in different formats, adding or omitting some information in each case. Thus, this model intends to provide uniformity on the way operational-modes are characterized by including a set of static attributes associated to each mode.
+
+This proposal was submitted by the Telecom Infra Project (TIP) Mandatory Use Cases for SDN Transport (MUST) sub-group. This is an operator centric initiative which intends to achieve a wider consensus about the SDN standards to use on the network transport segment.
+
+# Model content
+The model contains two main building blocks:
+* **operational-mode-capabilities** this set of attributes contains all characteristic information of the signal (modulation format, FEC, bit rate...), relevant information for the physical impairment validation (OSNR Rx sensitivity, CD/PMD tolerance and penalties).
+* **optical-channel-config-value-constrains** which contains the transmission configuration constrains/ranges of the optical-channel's attributes characterized by the operational-mode, i.e., the central frequency range, the frequency grid and the configurable transmitted power.
+
+
+# Model logic
+
+1. **Terminal device manufacturing – Operational modes hardcoding**
+Terminal device manufacturer encodes supported transmission modes characteristic information into the terminal-device's manifest file which is hardcoded into the device firmware. This process shall takes into account the transmission modes supported third-party transceiver pluggable modules compatible with the terminal device.
+
+2. **Terminal device w/o pluggable – Initial setup**
+When the device is started, the operational modes list is complete and contains all the information about the compatible transceivers and their associated operational modes. The manifest file defined by the openconfig-terminal-device-properties.yang model is static and will remain available and invariant through the terminal device's management interface which exposes openconfig models.
+
+3. **Terminal device with equipped pluggable – Running State**
+Once the line-card module is successfully equipped with the fixed or pluggable transceiver and the module is discovered by the Terminal Device, the operational data store is updated with the actual modes available (see openconfig-terminal-device.yang module). The list of modes present in the terminal-device/operational-modes list represents the actual modes which are available in runtime by the device and which can be configured as part of the optical-channel configuration. Please note, that this information can be dynamically updated if the pluggable unit changes. For each operational-mode/mode-id present in the operational data store, there should be an operational-modes/mode-descriptor item with the same mode-id, included in the manifest file.
+
+# Model implementation guidelines
+
+Manifest files are a special OpenConfig model category since they do not represent operational data. Thus, this category of models will be included within the "models/tree/master/yang/devices-manifest" folder.
+
+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";
+```

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

@@ -0,0 +1,18 @@
+module openconfig-openflow-types-test {
+  prefix "openflow-types-t";
+  namespace "urn:openconfig-openflow-types-test";
+
+  import pattern-test { prefix "pt"; }
+  import openconfig-openflow-types { prefix "openflow-types"; }
+
+  leaf datapath-id {
+    type openflow-types:datapath-id;
+    // Upper 16-bits (UD), Lower 48-bits (MAC)
+    pt:pattern-test-pass "00:0a:00:9c:02:d8:18:00";
+    pt:pattern-test-pass "00:ff:0a:3c:67:c8:12:01";
+    pt:pattern-test-pass "00:FF:0A:3C:67:C8:12:01";
+    pt:pattern-test-pass "11:11:11:11:11:11:11:11";
+    pt:pattern-test-fail "0:a:0:9:0:d:1:0";
+    pt:pattern-test-fail "0h:0a:00:9c:02:d8:18:00";
+  }
+}

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

@@ -0,0 +1,38 @@
+module openconfig-vlan-types-test {
+  prefix "oc-vlan-types-t";
+  namespace "urn:openconfig-vlan-types-test";
+
+  import pattern-test { prefix "pt"; }
+  import openconfig-vlan-types { prefix "oc-vlan-types"; }
+
+  leaf vlan-range {
+    type oc-vlan-types:vlan-range;
+    pt:pattern-test-pass "1..10";
+    pt:pattern-test-pass "30..32";
+    pt:pattern-test-pass "1024..2048";
+    pt:pattern-test-fail "100..4097";
+    pt:pattern-test-fail "14";
+    pt:pattern-test-fail "A..40";
+  }
+
+  leaf qinq-id {
+    type oc-vlan-types:qinq-id;
+    pt:pattern-test-pass "10.10";
+    pt:pattern-test-pass "23.2000";
+    pt:pattern-test-pass "1000.*";
+    pt:pattern-test-fail "525";
+    pt:pattern-test-fail "100.4097";
+    pt:pattern-test-fail "300.4A";
+  }
+
+  leaf qinq-id-range {
+    type oc-vlan-types:qinq-id-range;
+    pt:pattern-test-pass "1.10..100";
+    pt:pattern-test-pass "100.400..1000";
+    pt:pattern-test-pass "300..400.1000";
+    pt:pattern-test-pass "1024..2048.1024";
+    pt:pattern-test-fail "1024..2048..1024";
+    pt:pattern-test-fail "10.20.30";
+    pt:pattern-test-fail "1020..1030";
+  }
+}

release/models/acl/openconfig-acl.yang

@@ -34,7 +34,13 @@ module openconfig-acl {
     packets should be handled. Entries have a type that indicates
     the type of match criteria, e.g., MAC layer, IPv4, IPv6, etc.";
 
-  oc-ext:openconfig-version "1.2.1";
+  oc-ext:openconfig-version "1.2.2";
+
+  revision "2022-01-14" {
+    description
+      "Fix when statements for MIXED mode ACLs";
+    reference "1.2.2";
+  }
 
   revision "2021-06-16" {
     description
@@ -416,42 +422,48 @@ module openconfig-acl {
         }
 
         uses oc-match:ethernet-header-top {
-          when "../../config/type='ACL_L2'" {
+          when "../../config/type='ACL_L2' or " +
+            "../../config/type='ACL_MIXED'" {
             description
-              "MAC-layer fields are valid when the ACL type is L2";
+              "MAC-layer fields are valid when the ACL type is L2 or
+              MIXED";
           }
         }
 
         uses oc-match:ipv4-protocol-fields-top {
-          when "../../config/type='ACL_IPV4'" {
+          when "../../config/type='ACL_IPV4' or " +
+            "../../config/type='ACL_MIXED'" {
             description
               "IPv4-layer fields are valid when the ACL type is
-              IPv4";
+              IPv4 or MIXED";
           }
         }
 
         uses oc-match:mpls-header-top {
-          when "../../config/type='ACL_MPLS'" {
+          when "../../config/type='ACL_MPLS' or " +
+            "../../config/type='ACL_MIXED'" {
             description
               "MPLS-layer fields are valid when the ACL type is
-              MPLS";
+              MPLS or MIXED";
           }
         }
 
         uses oc-match:ipv6-protocol-fields-top {
-          when "../../config/type='ACL_IPV6'" {
+          when "../../config/type='ACL_IPV6' or " +
+            "../../config/type='ACL_MIXED'" {
             description
               "IPv6-layer fields are valid when the ACL type is
-              IPv6";
+              IPv6 or MIXED";
           }
         }
 
         uses oc-match:transport-fields-top {
           when "../../config/type='ACL_IPV6' or " +
-            "../../config/type='ACL_IPV4'" {
+            "../../config/type='ACL_IPV4' or " +
+            "../../config/type='ACL_MIXED'" {
             description
               "Transport-layer fields are valid when specifying
-              L3 ACL types";
+              L3 or MIXED ACL types";
           }
         }