Internet DRAFT - draft-ietf-teas-rfc8776-update

draft-ietf-teas-rfc8776-update







TEAS Working Group                                               I. Busi
Internet-Draft                                                    Huawei
Obsoletes: 8776 (if approved)                                     A. Guo
Intended status: Standards Track                  Futurewei Technologies
Expires: 25 August 2024                                           X. Liu
                                                               Alef Edge
                                                                 T. Saad
                                                      Cisco Systems Inc.
                                                              I. Bryskin
                                                              Individual
                                                        22 February 2024


             Common YANG Data Types for Traffic Engineering
                   draft-ietf-teas-rfc8776-update-10

Abstract

   This document defines a collection of common data types, identities,
   and groupings in YANG data modeling language.  These derived common
   types and groupings are intended to be imported by modules that model
   Traffic Engineering (TE) configuration and state capabilities.  This
   document obsoletes RFC 8776.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 25 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Busi, et al.             Expires 25 August 2024                 [Page 1]

Internet-Draft            TE Common YANG Types             February 2024


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Prefixes in Data Node Names . . . . . . . . . . . . . . .   3
   2.  Acronyms and Abbreviations  . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  TE Types Module Contents  . . . . . . . . . . . . . . . .   5
       3.1.1.  Path Computation Errors . . . . . . . . . . . . . . .  11
       3.1.2.  Protocol Origin . . . . . . . . . . . . . . . . . . .  11
     3.2.  Packet TE Types Module Contents . . . . . . . . . . . . .  11
   4.  TE Types YANG Module  . . . . . . . . . . . . . . . . . . . .  13
   5.  Packet TE Types YANG Module . . . . . . . . . . . . . . . . . 105
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . 121
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 121
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . 121
     8.2.  Informative References  . . . . . . . . . . . . . . . . . 124
   Appendix A.  Changes from RFC 8776  . . . . . . . . . . . . . . . 131
     A.1.  TE Types YANG Diffs . . . . . . . . . . . . . . . . . . . 135
     A.2.  Packet TE Types YANG Diffs  . . . . . . . . . . . . . . . 165
   Appendix B.  Option Considered for updating RFC8776 . . . . . . . 171
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 172
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 172
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 172

1.  Introduction

   YANG [RFC6020] [RFC7950] is a data modeling language used to model
   configuration data, state data, Remote Procedure Calls, and
   notifications for network management protocols such as the Network
   Configuration Protocol (NETCONF) [RFC6241].  The YANG language
   supports a small set of built-in data types and provides mechanisms
   to derive other types from the built-in types.







Busi, et al.             Expires 25 August 2024                 [Page 2]

Internet-Draft            TE Common YANG Types             February 2024


   This document introduces a collection of common data types derived
   from the built-in YANG data types.  The derived data types,
   identities, and groupings are designed to be the common definitions
   applicable for modeling Traffic Engineering (TE) features in model(s)
   defined outside of this document.

   This document adds new common data types, identities, and groupings
   to both the "ietf-te-types" and the "ietf-te-packet-types" YANG
   models and obsoletes [RFC8776].  For further details, see the
   revision statements of the YANG modules in Section 4 and Section 5,
   or the summary in Appendix A.

1.1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Terminology

   The terminology for describing YANG data models is found in
   [RFC7950].

1.3.  Prefixes in Data Node Names

   In this document, names of data nodes and other data model objects
   are prefixed using the standard prefix associated with the
   corresponding YANG imported modules, as shown in Table 1.

          +=================+======================+===========+
          | Prefix          | YANG module          | Reference |
          +=================+======================+===========+
          | yang            | ietf-yang-types      | [RFC6991] |
          +-----------------+----------------------+-----------+
          | inet            | ietf-inet-types      | [RFC6991] |
          +-----------------+----------------------+-----------+
          | rt-types        | ietf-routing-types   | [RFC8294] |
          +-----------------+----------------------+-----------+
          | te-types        | ietf-te-types        | RFCXXXX   |
          +-----------------+----------------------+-----------+
          | te-packet-types | ietf-te-packet-types | RFCXXXX   |
          +-----------------+----------------------+-----------+

             Table 1: Prefixes and corresponding YANG modules





Busi, et al.             Expires 25 August 2024                 [Page 3]

Internet-Draft            TE Common YANG Types             February 2024


   RFC Editor: Please replace XXXX with the RFC number assigned to this
   document.

2.  Acronyms and Abbreviations

   GMPLS:

      Generalized Multiprotocol Label Switching

   LSP:

      Label Switched Path

   LSR:

      Label Switching Router

   LER:

      Label Edge Router

   MPLS:

      Multiprotocol Label Switching

   RSVP:

      Resource Reservation Protocol

   TE:

      Traffic Engineering

   DS-TE:

      Differentiated Services Traffic Engineering

   SRLG:

      Shared Risk Link Group

   NBMA:

      Non-Broadcast Multi-Access

   APS:

      Automatic Protection Switching



Busi, et al.             Expires 25 August 2024                 [Page 4]

Internet-Draft            TE Common YANG Types             February 2024


   SD:

      Signal Degrade

   SF:

      Signal Fail

   WTR:

      Wait-to-Restore

   PM:

      Performance Metrics

3.  Overview

   This document defines two YANG modules for common TE types: "ietf-te-
   types" for TE generic types and "ietf-te-packet-types" for packet-
   specific types.  Other technology-specific TE types are outside the
   scope of this document.

3.1.  TE Types Module Contents

   The "ietf-te-types" module (Section 4) contains common TE types that
   are independent and agnostic of any specific technology or control-
   plane instance.

   The "ietf-te-types" module contains the following YANG reusable types
   and groupings:

   te-bandwidth:

      A YANG grouping that defines the generic TE bandwidth.  The
      modeling structure allows augmentation for each technology.  For
      unspecified technologies, the string-encoded "te-bandwidth" type
      is used.

   te-label:

      A YANG grouping that defines the generic TE label.  The modeling
      structure allows augmentation for each technology.  For
      unspecified technologies, "rt-types:generalized-label" is used.

   performance-metrics-attributes:





Busi, et al.             Expires 25 August 2024                 [Page 5]

Internet-Draft            TE Common YANG Types             February 2024


      A YANG grouping that defines one-way and two-way measured
      Performance Metrics (PM) and indications of anomalies on link(s)
      or the path as defined in [RFC7471], [RFC8570], and [RFC7823].

   performance-metrics-throttle-container:

      A YANG grouping that defines configurable thresholds for
      advertisement suppression and measurement intervals.

   te-ds-class:

      A type representing the Differentiated Services (DS) Class-Type of
      traffic as defined in [RFC4124].

   te-label-direction:

      An enumerated type for specifying the forward or reverse direction
      of a label.

   te-hop-type:

      An enumerated type for specifying that a hop is loose or strict.

   te-global-id:

      A type representing the identifier that uniquely identifies an
      operator, which can be either a provider or a client.  The
      definition of this type is taken from [RFC6370] and [RFC5003].
      This attribute type is used solely to provide a globally unique
      context for TE topologies.

   te-node-id:

      A type representing the identifier for a node in a TE topology.
      The identifier is represented as 4 octets in dotted-quad notation.
      This attribute MAY be mapped to the Router Address TLV described
      in Section 2.4.1 of [RFC3630], the TE Router ID described in
      Section 3 of [RFC6827], the Traffic Engineering Router ID TLV
      described in Section 4.3 of [RFC5305], or the TE Router ID TLV
      described in Section 3.2.1 of [RFC6119].  The reachability of such
      a TE node MAY be achieved by a mechanism such as that described in
      Section 6.2 of [RFC6827].

   te-topology-id:







Busi, et al.             Expires 25 August 2024                 [Page 6]

Internet-Draft            TE Common YANG Types             February 2024


      A type representing the identifier for a topology.  It is optional
      to have one or more prefixes at the beginning, separated by
      colons.  The prefixes can be "network-types" as defined in the
      "ietf-network" module in [RFC8345], to help the user better
      understand the topology before further inquiry is made.

   te-tp-id:

      A type representing the identifier of a TE interface Link
      Termination Point (LTP) on a specific TE node where the TE link
      connects.  This attribute is mapped to a local or remote link
      identifier [RFC3630] [RFC5305].

   te-path-disjointness:

      A type representing the different resource disjointness options
      for a TE tunnel path as defined in [RFC4872].

   admin-groups:

      A union type for a TE link's classic or extended administrative
      groups as defined in [RFC3630], [RFC5305], and [RFC7308].

   srlg:

      A type representing the Shared Risk Link Group (SRLG) as defined
      in [RFC4203] and [RFC5307].

   te-metric:

      A type representing the TE metric as defined in [RFC3785].

   te-recovery-status:

      An enumerated type for the different statuses of a recovery action
      as defined in [RFC4427] and [RFC6378].

   path-attribute-flags:

      A base YANG identity for supported LSP path flags as defined in
      [RFC3209], [RFC4090], [RFC4736], [RFC5712], [RFC4920], [RFC5420],
      [RFC7570], [RFC4875], [RFC5151], [RFC5150], [RFC6001], [RFC6790],
      [RFC7260], [RFC8001], [RFC8149], and [RFC8169].

   link-protection-type:

      A base YANG identity for supported link protection types as
      defined in [RFC4872] and [RFC4427].



Busi, et al.             Expires 25 August 2024                 [Page 7]

Internet-Draft            TE Common YANG Types             February 2024


   restoration-scheme-type:

      A base YANG identity for supported LSP restoration schemes as
      defined in [RFC4872].

   protection-external-commands:

      A base YANG identity for supported protection-related external
      commands used for troubleshooting purposes, as defined in
      [RFC4427] and [ITU_G.808.1].

   CHANGE NOTE: The description and reference of the identity action-
   exercise, which applies only to APS and it is not defined in RFC4427,
   has been updated to reference ITU-T G.808.1.

   RFC Editor: remove the CHANGE NOTE above and this note

   association-type:

      A base YANG identity for supported LSP association types as
      defined in [RFC6780], [RFC4872], [RFC4873], and [RFC8800].

   CHANGE NOTE: The association-type-diversity identity, defined in
   [RFC8800] has been added to the association-type base identity.

   RFC Editor: remove the CHANGE NOTE above and this note

   objective-function-type:

      A base YANG identity for supported path objective functions as
      defined in [RFC5541].

   CHANGE NOTE: The objective-function-type identity has been redefined
   to be used only for path objective functions and a new svec-
   objective-function-type identity has been added for the
   Synchronization VECtor (SVEC) objective functions.  Therefore the of-
   minimize-agg-bandwidth-consumption, of-minimize-load-most-loaded-link
   and of-minimize-cost-path-set identities, defined in [RFC5541] and
   derived from the objective-function-type identity, have been
   obsoleted because not applicable to paths but to Synchronization
   VECtor (SVEC) objects.

   RFC Editor: remove the CHANGE NOTE above and this note

   te-tunnel-type:

      A base YANG identity for supported TE tunnel types as defined in
      [RFC3209] and [RFC4875].



Busi, et al.             Expires 25 August 2024                 [Page 8]

Internet-Draft            TE Common YANG Types             February 2024


   lsp-encoding-types:

      A base YANG identity for supported LSP encoding types as defined
      in [RFC3471].

   lsp-protection-type:

      A base YANG identity for supported LSP protection types as defined
      in [RFC4872] and [RFC4873].

   switching-capabilities:

      A base YANG identity for supported interface switching
      capabilities as defined in [RFC3471].

   resource-affinities-type:

      A base YANG identity for supported attribute filters associated
      with a tunnel that must be satisfied for a link to be acceptable
      as defined in [RFC2702] and [RFC3209].

   CHANGE NOTE: The description of the path-metric-type has been updated

   RFC Editor: remove the CHANGE NOTE above and this note

   path-metric-type:

      A base YANG identity for supported path metric types as defined in
      [RFC3630] [RFC3785], [RFC5440], [RFC7471], [RFC8233] and
      [RFC8570].

      The unit of the path metric value is interpreted in the context of
      the path metric type.  The derived identities SHOULD describe the
      unit and maximum value of the path metric types they define.

      For example, the bound of the 'path-metric-loss', defined in
      'ietf-te-packet-types', is defined in multiples of the basic unit
      0.000003% as described in [RFC7471] and [RFC8570].

   explicit-route-hop:

      A YANG grouping that defines supported explicit routes as defined
      in [RFC3209] and [RFC3477].

   te-link-access-type:

      An enumerated type for the different TE link access types as
      defined in [RFC3630].



Busi, et al.             Expires 25 August 2024                 [Page 9]

Internet-Draft            TE Common YANG Types             February 2024


   CHANGE NOTE: The module "ietf-te-types" has been updated to add the
   following YANG identities, types and groupings.

   RFC Editor: remove the CHANGE NOTE above and this note

   lsp-provisioning-error-reason:

      A base YANG identity for reporting LSP provisioning error reasons.
      No standard LPS provisioning error reasons are defined in this
      document.

   path-computation-error-reason:

      A base YANG identity for reporting path computation error reasons
      as defined in Section 3.1.1.

   protocol-origin-type:

      A base YANG identity for the type of protocol origin as defined in
      Section 3.1.2.

   svec-objective-function-type:

      A base YANG identity for supported SVEC objective functions as
      defined in [RFC5541] and [RFC8685].

   svec-metric-type:

      A base YANG identity for supported SVEC objective functions as
      defined in [RFC5541].

   encoding-and-switching-type:

      This is a common grouping to define the LSP encoding and switching
      types.

   CHANGE NOTE: The tunnel-admin-state-auto YANG identity, derived from
   the tunnel-admin-status-type base YANG identity has also been added.
   No description is provided, since no description for the tunnel-
   admin-status-type base YANG identity has been provided in RFC8776.

   CHANGE NOTE: The lsp-restoration-restore-none YANG identity, derived
   from the lsp-restoration-type base YANG identity has also been added.
   No description is provided, since no description for the lsp-
   restoration-type base YANG identity has been provided in RFC8776.

   RFC Editor: remove the two CHANGE NOTEs above and this note




Busi, et al.             Expires 25 August 2024                [Page 10]

Internet-Draft            TE Common YANG Types             February 2024


3.1.1.  Path Computation Errors

   The "ietf-te-types" module contains the YANG reusable identities for
   reporting path computation error reasons as defined in [RFC5440],
   [RFC5441], [RFC5520], [RFC5557], [RFC8306], and [RFC8685].

   It also defines the following additional YANG reusable identities for
   reporting also the following path computation error reasons:

   path-computation-error-no-topology:

      A YANG identity for reporting path computation error when there is
      no topology with the provided topology identifier.

3.1.2.  Protocol Origin

   The "ietf-te-types" module contains the YANG reusable identities for
   the type of protocol origin as defined in [RFC5440] and [RFC9012].

   It also defines the following additional YANG reusable identities for
   the type of protocol origin:

   protocol-origin-api:

      A YANG identity to be used when the type of protocol origin is an
      Application Programmable Interface (API).

3.2.  Packet TE Types Module Contents

   The "ietf-te-packet-types" module (Section 5) covers the common types
   and groupings that are specific to packet technology.

   The "ietf-te-packet-types" module contains the following YANG
   reusable types and groupings:

   backup-protection-type:

      A base YANG identity for supported protection types that a backup
      or bypass tunnel can provide as defined in [RFC4090].

   te-class-type:

      A type that represents the Diffserv-TE Class-Type as defined in
      [RFC4124].

   bc-type:





Busi, et al.             Expires 25 August 2024                [Page 11]

Internet-Draft            TE Common YANG Types             February 2024


      A type that represents Diffserv-TE Bandwidth Constraints (BCs) as
      defined in [RFC4124].

   bc-model-type:

      A base YANG identity for supported Diffserv-TE Bandwidth
      Constraints Models as defined in [RFC4125], [RFC4126], and
      [RFC4127].

   te-bandwidth-requested-type:

      An enumerated type for the different options to request bandwidth
      for a specific tunnel.

   performance-metrics-attributes-packet:

      A YANG grouping that contains the generic performance metrics and
      additional packet-specific metrics.

   CHANGE NOTE: The module "ietf-te-packet-types" has been updated to
   add the following YANG identities and groupings.

   RFC Editor: remove the CHANGE NOTE above and this note

   bandwidth-profile-type:

      A base YANG identity for various bandwidth profiles specified in
      [MEF_10.3], [RFC2697], [RFC2698] and [RFC4115] that may be used to
      limit bandwidth utilization of packet flows (e.g., MPLS-TE LSPs).

   te-packet-path-bandwidth

      A YANG grouping that defines the path bandwidth information and
      could be used in any Packet TE model (e.g., MPLS-TE topology
      model) for the path bandwidth representation (e.g., the bandwidth
      of an MPLS-TE LSP).

      All the path and LSP bandwidth related sections in the "ietf-te-
      types" generic module, Section 4, need to be augmented with this
      grouping for the usage of Packet TE technologies.

      The Packet TE path bandwidth can be represented by a bandwidth
      profile as follow:








Busi, et al.             Expires 25 August 2024                [Page 12]

Internet-Draft            TE Common YANG Types             February 2024


            +--:(packet)
              +--rw bandwidth-profile-name?   string
              +--rw bandwidth-profile-type?   identityref
              +--rw cir?                      uint64
              +--rw eir?                      uint64
              +--rw cbs?                      uint64
              +--rw ebs?                      uint64

   NOTE: Other formats for the MPLS-TE path bandwidth are defined in
   [I-D.ietf-teas-yang-te-mpls] and they could be added in a future
   update of this document.

   te-packet-link-bandwidth:

      A YANG grouping that defines the link bandwidth information and
      could be used in any Packet TE model (e.g., MPLS-TE topology) for
      link bandwidth representation.

      All the link bandwidth related sections in the "ietf-te-types"
      generic module, Section 4, need to be augmented with this grouping
      for the usage of Packet TE technologies.

4.  TE Types YANG Module

   The "ietf-te-types" module imports from the following modules:

   *  "ietf-yang-types" and "ietf-inet-types" as defined in [RFC6991]

   *  "ietf-routing-types" as defined in [RFC8294]

   In addition to [RFC6991] and [RFC8294], this module references the
   following documents in defining the types and YANG groupings:
   [RFC9522], [RFC4090], [RFC4202], [RFC4328], [RFC4561], [RFC4657],
   [RFC4736], [RFC6004], [RFC6511], [RFC7139], [RFC7308], [RFC7551],
   [RFC7571], [RFC7579], and [ITU-T_G.709].

   CHANGE NOTE: Please focus your review only on the updates to the YANG
   model: see also Appendix A.1.

   RFC Editor: remove the CHANGE NOTE above and this note

   <CODE BEGINS> file "ietf-te-types@2024-01-29.yang"
   module ietf-te-types {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-te-types";
     prefix te-types;

     import ietf-inet-types {



Busi, et al.             Expires 25 August 2024                [Page 13]

Internet-Draft            TE Common YANG Types             February 2024


       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-routing-types {
       prefix rt-types;
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area";
     }

     import ietf-network {
       prefix "nw";
       reference "RFC 8345: A YANG Data Model for Network Topologies";
     }

     import ietf-network-topology {
       prefix "nt";
       reference "RFC 8345: A YANG Data Model for Network Topologies";
     }

     organization
       "IETF Traffic Engineering Architecture and Signaling (TEAS)
        Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/teas/>
        WG List:  <mailto:teas@ietf.org>

        Editor:   Tarek Saad
                  <mailto:tsaad.net@gmail.com>

        Editor:   Rakesh Gandhi
                  <mailto:rgandhi@cisco.com>

        Editor:   Vishnu Pavan Beeram
                  <mailto:vbeeram@juniper.net>

        Editor:   Xufeng Liu
                  <mailto:xufeng.liu.ietf@gmail.com>

        Editor:   Igor Bryskin
                  <mailto:i_bryskin@yahoo.com>";
     description
       "This YANG module contains a collection of generally useful



Busi, et al.             Expires 25 August 2024                [Page 14]

Internet-Draft            TE Common YANG Types             February 2024


        YANG data type definitions specific to TE.  The model fully
        conforms to the Network Management Datastore Architecture
        (NMDA).

        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
        'MAY', and 'OPTIONAL' in this document are to be interpreted as
        described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
        they appear in all capitals, as shown here.

        Copyright (c) 2024 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Revised BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC XXXX
        (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
        for full legal notices.";
     revision 2024-02-22 {
       description
         "This revision adds the following new identities:
         - lsp-provisioning-error-reason;
         - association-type-diversity;
         - tunnel-admin-state-auto;
         - lsp-restoration-restore-none;
         - restoration-scheme-rerouting;
         - path-metric-optimization-type;
         - link-path-metric-type;
         - link-metric-type and its derived identities;
         - path-computation-error-reason and its derived identities;
         - protocol-origin-type and its derived identities;
         - svec-objective-function-type and its derived identities;
         - svec-metric-type and its derived identities.

         This revision adds the following new data types:
         - path-type;
         - te-gen-node-id.

         This revision adds the following new groupings:
         - encoding-and-switching-type;
         - te-generic-node-id.

         This revision updates the following identities:



Busi, et al.             Expires 25 August 2024                [Page 15]

Internet-Draft            TE Common YANG Types             February 2024


         - objective-function-type;
         - action-exercise;
         - path-metric-type;
         - path-metric-te;
         - path-metric-igp;
         - path-metric-hop;
         - path-metric-delay-average;
         - path-metric-delay-minimum;
         - path-metric-residual-bandwidth;
         - path-metric-optimize-includes;
         - path-metric-optimize-excludes;
         - te-optimization-criterion.

         This revision updates the following data types:
         - te-node-id.

         This revision updates the following groupings:
         - explicit-route-hop:
           - adds the following leaves:
             - node-id-uri;
             - link-tp-id-uri;
           - updates the following leaves:
             - node-id;
             - link-tp-id;
         - record-route-state:
           - adds the following leaves:
             - node-id-uri;
             - link-tp-id-uri;
           - updates the following leaves:
             - node-id;
             - link-tp-id;
         - optimization-metric-entry:
           - updates the following leaves:
             - metric-type;
         - tunnel-constraints;
           - adds the following leaves:
             - network-id;
         - path-constraints-route-objects:
           - updates the following containers:
             - explicit-route-objects-always;
         - generic-path-metric-bounds:
           - updates the following leaves:
             - metric-type;
         - generic-path-optimization
           - adds the following leaves:
             - tiebreaker;
           - deprecate the following containers:
             - tiebreakers.



Busi, et al.             Expires 25 August 2024                [Page 16]

Internet-Draft            TE Common YANG Types             February 2024


         This revision obsoletes the following identities:
         - of-minimize-agg-bandwidth-consumption;
         - of-minimize-load-most-loaded-link;
         - of-minimize-cost-path-set;
         - lsp-protection-reroute-extra;
         - lsp-protection-reroute.

         This revision provides also few editorial changes.";
       reference
         "RFC XXXX: Common YANG Data Types for Traffic Engineering";
     }
     // RFC Editor: replace XXXX with actual RFC number, update date
     // information and remove this note

     revision 2020-06-10 {
       description
         "Initial Version of TE types.";
       reference
         "RFC 8776: Common YANG Data Types for Traffic Engineering";
     }

     /**
      * Typedefs
      */

     typedef admin-group {
       type yang:hex-string {
         /* 01:02:03:04 */
         length "1..11";
       }
       description
         "Administrative group / resource class / color representation
          in 'hex-string' type.

          The most significant byte in the hex-string is the farthest
          to the left in the byte sequence.  Leading zero bytes in the
          configured value may be omitted for brevity.";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
          Version 2

          RFC 5305: IS-IS Extensions for Traffic Engineering

          RFC 7308: Extended Administrative Groups in MPLS Traffic
          Engineering (MPLS-TE)";
     }

     typedef admin-groups {



Busi, et al.             Expires 25 August 2024                [Page 17]

Internet-Draft            TE Common YANG Types             February 2024


       type union {
         type admin-group;
         type extended-admin-group;
       }
       description
         "Derived types for TE administrative groups.";
     }

     typedef extended-admin-group {
       type yang:hex-string;
       description
         "Extended administrative group / resource class / color
          representation in 'hex-string' type.

          The most significant byte in the hex-string is the farthest
          to the left in the byte sequence.  Leading zero bytes in the
          configured value may be omitted for brevity.";
       reference
         "RFC 7308: Extended Administrative Groups in MPLS Traffic
          Engineering (MPLS-TE)";
     }

     typedef path-attribute-flags {
       type union {
         type identityref {
           base session-attributes-flags;
         }
         type identityref {
           base lsp-attributes-flags;
         }
       }
       description
         "Path attributes flags type.";
     }

     typedef performance-metrics-normality {
       type enumeration {
         enum unknown {
           value 0;
           description
             "Unknown.";
         }
         enum normal {
           value 1;
           description
             "Normal.  Indicates that the anomalous bit is not set.";
         }
         enum abnormal {



Busi, et al.             Expires 25 August 2024                [Page 18]

Internet-Draft            TE Common YANG Types             February 2024


           value 2;
           description
             "Abnormal.  Indicates that the anomalous bit is set.";
         }
       }
       description
         "Indicates whether a performance metric is normal (anomalous
          bit not set), abnormal (anomalous bit set), or unknown.";
       reference
         "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions

          RFC 7823: Performance-Based Path Selection for Explicitly
          Routed Label Switched Paths (LSPs) Using TE Metric
          Extensions

          RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
     }

     typedef srlg {
       type uint32;
       description
         "SRLG type.";
       reference
         "RFC 4203: OSPF Extensions in Support of Generalized
          Multi-Protocol Label Switching (GMPLS)
          RFC 5307: IS-IS Extensions in Support of Generalized
          Multi-Protocol Label Switching (GMPLS)";
     }

     typedef te-common-status {
       type enumeration {
         enum up {
           description
             "Enabled.";
         }
         enum down {
           description
             "Disabled.";
         }
         enum testing {
           description
             "In some test mode.";
         }
         enum preparing-maintenance {
           description
             "The resource is disabled in the control plane to prepare
              for a graceful shutdown for maintenance purposes.";
           reference



Busi, et al.             Expires 25 August 2024                [Page 19]

Internet-Draft            TE Common YANG Types             February 2024


             "RFC 5817: Graceful Shutdown in MPLS and Generalized MPLS
              Traffic Engineering Networks";
         }
         enum maintenance {
           description
             "The resource is disabled in the data plane for maintenance
              purposes.";
         }
         enum unknown {
           description
             "Status is unknown.";
         }
       }
       description
         "Defines a type representing the common states of a TE
          resource.";
     }

     typedef te-bandwidth {
       type string {
         pattern '0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|'
               + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?'
               + '[pP](\+)?(12[0-7]|'
               + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+'
               + '(,(0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|'
               + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?'
               + '[pP](\+)?(12[0-7]|'
               + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+))*';
       }
       description
         "This is the generic bandwidth type.  It is a string containing
          a list of numbers separated by commas, where each of these
          numbers can be non-negative decimal, hex integer, or
          hex float:

          (dec | hex | float)[*(','(dec | hex | float))]

          For the packet-switching type, the string encoding follows
          the type 'bandwidth-ieee-float32' as defined in RFC 8294
          (e.g., 0x1p10), where the units are in bytes per second.

          For the Optical Transport Network (OTN) switching type,
          a list of integers can be used, such as '0,2,3,1', indicating
          two ODU0s and one ODU3.  ('ODU' stands for 'Optical Data
          Unit'.)  For Dense Wavelength Division Multiplexing (DWDM),
          a list of pairs of slot numbers and widths can be used,
          such as '0,2,3,3', indicating a frequency slot 0 with
          slot width 2 and a frequency slot 3 with slot width 3.



Busi, et al.             Expires 25 August 2024                [Page 20]

Internet-Draft            TE Common YANG Types             February 2024


          Canonically, the string is represented as all lowercase and in
          hex, where the prefix '0x' precedes the hex number.";
       reference
         "RFC 8294: Common YANG Data Types for the Routing Area
          ITU-T Recommendation G.709: Interfaces for the
          optical transport network";
     }

     typedef te-ds-class {
       type uint8 {
         range "0..7";
       }
       description
         "The Differentiated Services Class-Type of traffic.";
       reference
         "RFC 4124: Protocol Extensions for Support of Diffserv-aware
          MPLS Traffic Engineering, Section 4.3.1";
     }

     typedef te-global-id {
       type uint32;
       description
         "An identifier to uniquely identify an operator, which can be
          either a provider or a client.

          The definition of this type is taken from RFCs 6370 and 5003.

          This attribute type is used solely to provide a globally
          unique context for TE topologies.";
       reference
         "RFC 5003: Attachment Individual Identifier (AII) Types for
          Aggregation

          RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers";
     }

     typedef te-hop-type {
       type enumeration {
         enum loose {
           description
             "A loose hop in an explicit path.";
         }
         enum strict {
           description
             "A strict hop in an explicit path.";
         }
       }
       description



Busi, et al.             Expires 25 August 2024                [Page 21]

Internet-Draft            TE Common YANG Types             February 2024


         "Enumerated type for specifying loose or strict paths.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Section 4.3.3";
     }

     typedef te-link-access-type {
       type enumeration {
         enum point-to-point {
           description
             "The link is point-to-point.";
         }
         enum multi-access {
           description
             "The link is multi-access, including broadcast and NBMA.";
         }
       }
       description
         "Defines a type representing the access type of a TE link.";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
          Version 2";
     }

     typedef te-label-direction {
       type enumeration {
         enum forward {
           description
             "Label allocated for the forward LSP direction.";
         }
         enum reverse {
           description
             "Label allocated for the reverse LSP direction.";
         }
       }
       description
         "Enumerated type for specifying the forward or reverse
          label.";
     }

     typedef te-link-direction {
       type enumeration {
         enum incoming {
           description
             "The explicit route represents an incoming link on
              a node.";
         }
         enum outgoing {



Busi, et al.             Expires 25 August 2024                [Page 22]

Internet-Draft            TE Common YANG Types             February 2024


           description
             "The explicit route represents an outgoing link on
              a node.";
         }
       }
       description
         "Enumerated type for specifying the direction of a link on
          a node.";
     }

     typedef te-metric {
       type uint32;
       description
         "TE metric.";
       reference
         "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a
          second MPLS Traffic Engineering (TE) Metric";
     }

     // CHANGE NOTE: The typedef te-node-id below has been
     // updated in this module revision
     // RFC Editor: remove the note above and this note
     typedef te-node-id {
       type union {
         type yang:dotted-quad;
         type inet:ipv6-address-no-zone;
       }
       description
         "A type representing the identifier for a node in a TE
          topology.

          The identifier is represented either as 4 octets in
          dotted-quad notation or 16 octets in full, mixed, shortened,
          or shortened-mixed IPv6 address notation.

          This attribute MAY be mapped to the Router Address TLV
          described in Section 2.4.1 of RFC 3630, the TE Router ID
          described in Section 3 of RFC 6827, the Traffic Engineering
          Router ID TLV described in Section 4.3 of RFC 5305, the TE
          Router ID TLV described in Section 3.2.1 of RFC 6119, or the
          IPv6 TE Router ID TLV described in Section 4.1 of RFC 6119.

          The reachability of such a TE node MAY be achieved by a
          mechanism such as that described in Section 6.2 of RFC 6827.";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
          Version 2, Section 2.4.1




Busi, et al.             Expires 25 August 2024                [Page 23]

Internet-Draft            TE Common YANG Types             February 2024


          RFC 5305: IS-IS Extensions for Traffic Engineering,
          Section 4.3

          RFC 6119: IPv6 Traffic Engineering in IS-IS, Section 3.2.1

          RFC 6827: Automatically Switched Optical Network (ASON)
          Routing for OSPFv2 Protocols, Section 3";
     }

     typedef te-oper-status {
       type te-common-status;
       description
         "Defines a type representing the operational status of
          a TE resource.";
     }

     typedef te-admin-status {
       type te-common-status;
       description
         "Defines a type representing the administrative status of
          a TE resource.";
     }

     typedef te-path-disjointness {
       type bits {
         bit node {
           position 0;
           description
             "Node disjoint.";
         }
         bit link {
           position 1;
           description
             "Link disjoint.";
         }
         bit srlg {
           position 2;
           description
             "SRLG (Shared Risk Link Group) disjoint.";
         }
       }
       description
         "Type of the resource disjointness for a TE tunnel path.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }




Busi, et al.             Expires 25 August 2024                [Page 24]

Internet-Draft            TE Common YANG Types             February 2024


     typedef te-recovery-status {
       type enumeration {
         enum normal {
           description
             "Both the recovery span and the working span are fully
              allocated and active, data traffic is being
              transported over (or selected from) the working
              span, and no trigger events are reported.";
         }
         enum recovery-started {
           description
             "The recovery action has been started but not completed.";
         }
         enum recovery-succeeded {
           description
             "The recovery action has succeeded.  The working span has
              reported a failure/degrade condition, and the user traffic
              is being transported (or selected) on the recovery span.";
         }
         enum recovery-failed {
           description
             "The recovery action has failed.";
         }
         enum reversion-started {
           description
             "The reversion has started.";
         }
         enum reversion-succeeded {
           description
             "The reversion action has succeeded.";
         }
         enum reversion-failed {
           description
             "The reversion has failed.";
         }
         enum recovery-unavailable {
           description
             "The recovery is unavailable, as a result of either an
              operator's lockout command or a failure condition
              detected on the recovery span.";
         }
         enum recovery-admin {
           description
             "The operator has issued a command to switch the user
              traffic to the recovery span.";
         }
         enum wait-to-restore {
           description



Busi, et al.             Expires 25 August 2024                [Page 25]

Internet-Draft            TE Common YANG Types             February 2024


             "The recovery domain is recovering from a failure/degrade
              condition on the working span that is being controlled by
              the Wait-to-Restore (WTR) timer.";
         }
       }
       description
         "Defines the status of a recovery action.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)
          RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection";
     }

     typedef te-template-name {
       type string {
         pattern '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*';
       }
       description
         "A type for the name of a TE node template or TE link
          template.";
     }

     typedef te-topology-event-type {
       type enumeration {
         enum add {
           value 0;
           description
             "A TE node or TE link has been added.";
         }
         enum remove {
           value 1;
           description
             "A TE node or TE link has been removed.";
         }
         enum update {
           value 2;
           description
             "A TE node or TE link has been updated.";
         }
       }
       description
         "TE event type for notifications.";
     }

     typedef te-topology-id {
       type union {
         type string {
           length "0";



Busi, et al.             Expires 25 August 2024                [Page 26]

Internet-Draft            TE Common YANG Types             February 2024


           // empty string
         }
         type string {
           pattern '([a-zA-Z0-9\-_.]+:)*'
                 + '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*';
         }
       }
       description
         "An identifier for a topology.

          It is optional to have one or more prefixes at the beginning,
          separated by colons.  The prefixes can be 'network-types' as
          defined in the 'ietf-network' module in RFC 8345, to help the
          user better understand the topology before further inquiry
          is made.";
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }

     typedef te-tp-id {
       type union {
         type uint32;
         // Unnumbered
         type inet:ip-address;
         // IPv4 or IPv6 address
       }
       description
         "An identifier for a TE link endpoint on a node.

          This attribute is mapped to a local or remote link identifier
          as defined in RFCs 3630 and 5305.";
       reference
         "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
          Version 2
          RFC 5305: IS-IS Extensions for Traffic Engineering";
     }

     // CHANGE NOTE: The typedef path-type below has been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     typedef path-type {
       type enumeration {
         enum primary-path {
           description
             "Indicates that the TE path is a primary path.";
         }
         enum secondary-path {
           description



Busi, et al.             Expires 25 August 2024                [Page 27]

Internet-Draft            TE Common YANG Types             February 2024


             "Indicates that the TE path is a secondary path.";
         }
         enum primary-reverse-path {
           description
             "Indicates that the TE path is a primary reverse path.";
         }
         enum secondary-reverse-path {
           description
             "Indicates that the TE path is a secondary reverse path.";
         }
       }
       description
         "The type of TE path, indicating whether a path is a primary,
         or a reverse primary, or a secondary, or a reverse secondary
         path.";
     }

     // CHANGE NOTE: The typedef te-gen-node-id below has been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     typedef te-gen-node-id {
       type union {
         type te-node-id;
         type inet:ip-address;
         type nw:node-id;
       }
       description
         "Generic type that identifies a node in a TE topology.";
     }

     /* TE features */

     feature p2mp-te {
       description
         "Indicates support for Point-to-Multipoint TE (P2MP-TE).";
       reference
         "RFC 4875: Extensions to Resource Reservation Protocol -
          Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE
          Label Switched Paths (LSPs)";
     }

     feature frr-te {
       description
         "Indicates support for TE Fast Reroute (FRR).";
       reference
         "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels";
     }




Busi, et al.             Expires 25 August 2024                [Page 28]

Internet-Draft            TE Common YANG Types             February 2024


     feature extended-admin-groups {
       description
         "Indicates support for TE link extended administrative
          groups.";
       reference
         "RFC 7308: Extended Administrative Groups in MPLS Traffic
          Engineering (MPLS-TE)";
     }

     feature named-path-affinities {
       description
         "Indicates support for named path affinities.";
     }

     feature named-extended-admin-groups {
       description
         "Indicates support for named extended administrative groups.";
     }

     feature named-srlg-groups {
       description
         "Indicates support for named SRLG groups.";
     }

     feature named-path-constraints {
       description
         "Indicates support for named path constraints.";
     }

     feature path-optimization-metric {
       description
         "Indicates support for path optimization metrics.";
     }

     feature path-optimization-objective-function {
       description
         "Indicates support for path optimization objective functions.";
     }

     /*
      * Identities
      */

     // CHANGE NOTE: The base identity lsp-provisioning-error-reason
     // has been added in this module revision
     // RFC Editor: remove the note above and this note
     identity lsp-provisioning-error-reason {
       description



Busi, et al.             Expires 25 August 2024                [Page 29]

Internet-Draft            TE Common YANG Types             February 2024


         "Base identity for LSP provisioning errors.";
     }

     identity session-attributes-flags {
       description
         "Base identity for the RSVP-TE session attributes flags.";
     }

     identity local-protection-desired {
       base session-attributes-flags;
       description
         "Local protection is desired.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Section 4.7.1";
     }

     identity se-style-desired {
       base session-attributes-flags;
       description
         "Shared explicit style, to allow the LSP to be established
          and share resources with the old LSP.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
     }

     identity local-recording-desired {
       base session-attributes-flags;
       description
         "Label recording is desired.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Section 4.7.1";
     }

     identity bandwidth-protection-desired {
       base session-attributes-flags;
       description
         "Requests FRR bandwidth protection on LSRs, if present.";
       reference
         "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels";
     }

     identity node-protection-desired {
       base session-attributes-flags;
       description
         "Requests FRR node protection on LSRs, if present.";
       reference



Busi, et al.             Expires 25 August 2024                [Page 30]

Internet-Draft            TE Common YANG Types             February 2024


         "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels";
     }

     identity path-reevaluation-request {
       base session-attributes-flags;
       description
         "This flag indicates that a path re-evaluation (of the
          current path in use) is requested.  Note that this does
          not trigger any LSP reroutes but instead just signals a
          request to evaluate whether a preferable path exists.";
       reference
         "RFC 4736: Reoptimization of Multiprotocol Label Switching
          (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched
          Path (LSP)";
     }

     identity soft-preemption-desired {
       base session-attributes-flags;
       description
         "Soft preemption of LSP resources is desired.";
       reference
         "RFC 5712: MPLS Traffic Engineering Soft Preemption";
     }

     identity lsp-attributes-flags {
       description
         "Base identity for LSP attributes flags.";
     }

     identity end-to-end-rerouting-desired {
       base lsp-attributes-flags;
       description
         "Indicates end-to-end rerouting behavior for an LSP
          undergoing establishment.  This MAY also be used to
          specify the behavior of end-to-end LSP recovery for
          established LSPs.";
       reference
         "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
          RSVP-TE
          RFC 5420: Encoding of Attributes for MPLS LSP Establishment
          Using Resource Reservation Protocol Traffic Engineering
          (RSVP-TE)
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity boundary-rerouting-desired {
       base lsp-attributes-flags;



Busi, et al.             Expires 25 August 2024                [Page 31]

Internet-Draft            TE Common YANG Types             February 2024


       description
         "Indicates boundary rerouting behavior for an LSP undergoing
          establishment.  This MAY also be used to specify
          segment-based LSP recovery through nested crankback for
          established LSPs.  The boundary Area Border Router (ABR) /
          Autonomous System Border Router (ASBR) can decide to forward
          the PathErr message upstream to either an upstream boundary
          ABR/ASBR or the ingress LSR.  Alternatively, it can try to
          select another egress boundary LSR.";
       reference
         "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
          RSVP-TE
          RFC 5420: Encoding of Attributes for MPLS LSP Establishment
          Using Resource Reservation Protocol Traffic Engineering
          (RSVP-TE)
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity segment-based-rerouting-desired {
       base lsp-attributes-flags;
       description
         "Indicates segment-based rerouting behavior for an LSP
          undergoing establishment.  This MAY also be used to specify
          segment-based LSP recovery for established LSPs.";
       reference
         "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
          RSVP-TE
          RFC 5420: Encoding of Attributes for MPLS LSP Establishment
          Using Resource Reservation Protocol Traffic Engineering
          (RSVP-TE)
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity lsp-integrity-required {
       base lsp-attributes-flags;
       description
         "Indicates that LSP integrity is required.";
       reference
         "RFC 4875: Extensions to Resource Reservation Protocol -
          Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE
          Label Switched Paths (LSPs)
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity contiguous-lsp-desired {



Busi, et al.             Expires 25 August 2024                [Page 32]

Internet-Draft            TE Common YANG Types             February 2024


       base lsp-attributes-flags;
       description
         "Indicates that a contiguous LSP is desired.";
       reference
         "RFC 5151: Inter-Domain MPLS and GMPLS Traffic Engineering --
          Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
          Extensions
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity lsp-stitching-desired {
       base lsp-attributes-flags;
       description
         "Indicates that LSP stitching is desired.";
       reference
         "RFC 5150: Label Switched Path Stitching with Generalized
          Multiprotocol Label Switching Traffic Engineering (GMPLS TE)
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity pre-planned-lsp-flag {
       base lsp-attributes-flags;
       description
         "Indicates that the LSP MUST be provisioned in the
          control plane only.";
       reference
         "RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for
          Multi-Layer and Multi-Region Networks (MLN/MRN)
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity non-php-behavior-flag {
       base lsp-attributes-flags;
       description
         "Indicates that non-PHP (non-Penultimate Hop Popping) behavior
          for the LSP is desired.";
       reference
         "RFC 6511: Non-Penultimate Hop Popping Behavior and Out-of-Band
          Mapping for RSVP-TE Label Switched Paths
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity oob-mapping-flag {
       base lsp-attributes-flags;



Busi, et al.             Expires 25 August 2024                [Page 33]

Internet-Draft            TE Common YANG Types             February 2024


       description
         "Indicates that signaling of the egress binding information is
          out of band (e.g., via the Border Gateway Protocol (BGP)).";
       reference
         "RFC 6511: Non-Penultimate Hop Popping Behavior and Out-of-Band
          Mapping for RSVP-TE Label Switched Paths
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity entropy-label-capability {
       base lsp-attributes-flags;
       description
         "Indicates entropy label capability.";
       reference
         "RFC 6790: The Use of Entropy Labels in MPLS Forwarding
          RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)";
     }

     identity oam-mep-entity-desired {
       base lsp-attributes-flags;
       description
         "OAM Maintenance Entity Group End Point (MEP) entities
          desired.";
       reference
         "RFC 7260: GMPLS RSVP-TE Extensions for Operations,
          Administration, and Maintenance (OAM) Configuration";
     }

     identity oam-mip-entity-desired {
       base lsp-attributes-flags;
       description
         "OAM Maintenance Entity Group Intermediate Points (MIP)
          entities desired.";
       reference
         "RFC 7260: GMPLS RSVP-TE Extensions for Operations,
          Administration, and Maintenance (OAM) Configuration";
     }

     identity srlg-collection-desired {
       base lsp-attributes-flags;
       description
         "SRLG collection desired.";
       reference
         "RFC 7570: Label Switched Path (LSP) Attribute in the Explicit
          Route Object (ERO)
          RFC 8001: RSVP-TE Extensions for Collecting Shared Risk



Busi, et al.             Expires 25 August 2024                [Page 34]

Internet-Draft            TE Common YANG Types             February 2024


          Link Group (SRLG) Information";
     }

     identity loopback-desired {
       base lsp-attributes-flags;
       description
         "This flag indicates that a particular node on the LSP is
          required to enter loopback mode.  This can also be
          used to specify the loopback state of the node.";
       reference
         "RFC 7571: GMPLS RSVP-TE Extensions for Lock Instruct and
          Loopback";
     }

     identity p2mp-te-tree-eval-request {
       base lsp-attributes-flags;
       description
         "P2MP-TE tree re-evaluation request.";
       reference
         "RFC 8149: RSVP Extensions for Reoptimization of Loosely Routed
          Point-to-Multipoint Traffic Engineering Label Switched Paths
          (LSPs)";
     }

     identity rtm-set-desired {
       base lsp-attributes-flags;
       description
         "Residence Time Measurement (RTM) attribute flag requested.";
       reference
         "RFC 8169: Residence Time Measurement in MPLS Networks";
     }

     identity link-protection-type {
       description
         "Base identity for the link protection type.";
     }

     identity link-protection-unprotected {
       base link-protection-type;
       description
         "Unprotected link type.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity link-protection-extra-traffic {
       base link-protection-type;



Busi, et al.             Expires 25 August 2024                [Page 35]

Internet-Draft            TE Common YANG Types             February 2024


       description
         "Extra-Traffic protected link type.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity link-protection-shared {
       base link-protection-type;
       description
         "Shared protected link type.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity link-protection-1-for-1 {
       base link-protection-type;
       description
         "One-for-one (1:1) protected link type.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity link-protection-1-plus-1 {
       base link-protection-type;
       description
         "One-plus-one (1+1) protected link type.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity link-protection-enhanced {
       base link-protection-type;
       description
         "A compound link protection type derived from the underlay
          TE tunnel protection configuration supporting the TE link.";
     }

     identity association-type {
       description
         "Base identity for the tunnel association.";
     }

     identity association-type-recovery {
       base association-type;



Busi, et al.             Expires 25 August 2024                [Page 36]

Internet-Draft            TE Common YANG Types             February 2024


       description
         "Association type for recovery, used to associate LSPs of the
          same tunnel for recovery.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery
          RFC 6780: RSVP ASSOCIATION Object Extensions";
     }

     identity association-type-resource-sharing {
       base association-type;
       description
         "Association type for resource sharing, used to enable
          resource sharing during make-before-break.";
       reference
         "RFC 4873: GMPLS Segment Recovery
          RFC 6780: RSVP ASSOCIATION Object Extensions";
     }

     identity association-type-double-sided-bidir {
       base association-type;
       description
         "Association type for double-sided bidirectional LSPs,
          used to associate two LSPs of two tunnels that are
          independently configured on either endpoint.";
       reference
         "RFC 7551: RSVP-TE Extensions for Associated Bidirectional
          Label Switched Paths (LSPs)";
     }

     identity association-type-single-sided-bidir {
       base association-type;
       description
         "Association type for single-sided bidirectional LSPs,
          used to associate two LSPs of two tunnels, where one
          tunnel is configured on one side/endpoint and the other
          tunnel is dynamically created on the other endpoint.";
       reference
         "RFC 6780: RSVP ASSOCIATION Object Extensions
          RFC 7551: RSVP-TE Extensions for Associated Bidirectional
          Label Switched Paths (LSPs)";
     }

     // CHANGE NOTE: The identity association-type-diversity below has
     // been added in this module revision
     // RFC Editor: remove the note above and this note
     identity association-type-diversity {
       base association-type;



Busi, et al.             Expires 25 August 2024                [Page 37]

Internet-Draft            TE Common YANG Types             February 2024


       description
         "Association Type diversity used to associate LSPs whose
         paths are to be diverse from each other.";
       reference
         "RFC 8800: Path Computation Element Communication Protocol
         (PCEP) Extension for Label Switched Path (LSP) Diversity
         Constraint Signaling";
     }

     // CHANGE NOTE: The description of the base identity
     // objective-function-type has been updated
     // in this module revision
     // RFC Editor: remove the note above and this note
     identity objective-function-type {
       description
         "Base identity for path objective function types.";
     }

     identity of-minimize-cost-path {
       base objective-function-type;
       description
         "Objective function for minimizing path cost.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
          Computation Element Communication Protocol (PCEP)";
     }

     identity of-minimize-load-path {
       base objective-function-type;
       description
         "Objective function for minimizing the load on one or more
          paths.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
          Computation Element Communication Protocol (PCEP)";
     }

     identity of-maximize-residual-bandwidth {
       base objective-function-type;
       description
         "Objective function for maximizing residual bandwidth.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
          Computation Element Communication Protocol (PCEP)";
     }

     // CHANGE NOTE: The identity of-minimize-agg-bandwidth-consumption
     // below has been obsoleted in this module revision



Busi, et al.             Expires 25 August 2024                [Page 38]

Internet-Draft            TE Common YANG Types             February 2024


     // RFC Editor: remove the note above and this note
     identity of-minimize-agg-bandwidth-consumption {
       base objective-function-type;
       status obsolete;
       description
         "Objective function for minimizing aggregate bandwidth
         consumption.

         This identity has been obsoleted: the
         'svec-of-minimize-agg-bandwidth-consumption' identity SHOULD
         be used instead.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
         Computation Element Communication Protocol (PCEP)";
     }

     // CHANGE NOTE: The identity of-minimize-load-most-loaded-link
     // below has been obsoleted in this module revision
     // RFC Editor: remove the note above and this note
     identity of-minimize-load-most-loaded-link {
       base objective-function-type;
       status obsolete;
       description
         "Objective function for minimizing the load on the link that
         is carrying the highest load.

         This identity has been obsoleted: the
         'svec-of-minimize-load-most-loaded-link' identity SHOULD
         be used instead.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
         Computation Element Communication Protocol (PCEP)";
     }

     // CHANGE NOTE: The identity of-minimize-cost-path-set
     // below has been obsoleted in this module revision
     // RFC Editor: remove the note above and this note
     identity of-minimize-cost-path-set {
       base objective-function-type;
       status obsolete;
       description
         "Objective function for minimizing the cost on a path set.

         This identity has been obsoleted: the
         'svec-of-minimize-cost-path-set' identity SHOULD
         be used instead.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path



Busi, et al.             Expires 25 August 2024                [Page 39]

Internet-Draft            TE Common YANG Types             February 2024


          Computation Element Communication Protocol (PCEP)";
     }

     identity path-computation-method {
       description
         "Base identity for supported path computation mechanisms.";
     }

     // CHANGE NOTE: The reference of the identity path-locally-computed
     // below has been updated in this module revision
     // RFC Editor: remove the note above and this note
     identity path-locally-computed {
       base path-computation-method;
       description
         "Indicates a constrained-path LSP in which the
          path is computed by the local LER.";
       reference
         "RFC 9522: Overview and Principles of Internet Traffic
         Engineering, Section 4.4";
     }

     // CHANGE NOTE: The reference of the identity
     // path-externally-queried below has been updated
     // in this module revision
     // RFC Editor: remove the note above and this note
     identity path-externally-queried {
       base path-computation-method;
       description
         "Constrained-path LSP in which the path is obtained by
          querying an external source, such as a PCE server.
          In the case that an LSP is defined to be externally queried,
          it may also have associated explicit definitions (provided
          to the external source to aid computation).  The path that is
          returned by the external source may require further local
          computation on the device.";
       reference
         "RFC 9522: Overview and Principles of Internet Traffic
          Engineering

          RFC 4657: Path Computation Element (PCE) Communication
          Protocol Generic Requirements";
     }

     // CHANGE NOTE: The reference of the identity
     // path-explicitly-defined below has been updated
     // in this module revision
     // RFC Editor: remove the note above and this note
     identity path-explicitly-defined {



Busi, et al.             Expires 25 August 2024                [Page 40]

Internet-Draft            TE Common YANG Types             February 2024


       base path-computation-method;
       description
         "Constrained-path LSP in which the path is
          explicitly specified as a collection of strict and/or loose
          hops.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels

          RFC 9522: Overview and Principles of Internet Traffic
          Engineering";
     }

     identity lsp-metric-type {
       description
         "Base identity for the LSP metric specification types.";
     }

     identity lsp-metric-relative {
       base lsp-metric-type;
       description
         "The metric specified for the LSPs to which this identity
          refers is specified as a value relative to the IGP metric
          cost to the LSP's tail end.";
       reference
         "RFC 4657: Path Computation Element (PCE) Communication
          Protocol Generic Requirements";
     }

     identity lsp-metric-absolute {
       base lsp-metric-type;
       description
         "The metric specified for the LSPs to which this identity
          refers is specified as an absolute value.";
       reference
         "RFC 4657: Path Computation Element (PCE) Communication
          Protocol Generic Requirements";
     }

     identity lsp-metric-inherited {
       base lsp-metric-type;
       description
         "The metric for the LSPs to which this identity refers is
          not specified explicitly; rather, it is directly inherited
          from the IGP cost.";
       reference
         "RFC 4657: Path Computation Element (PCE) Communication
          Protocol Generic Requirements";
     }



Busi, et al.             Expires 25 August 2024                [Page 41]

Internet-Draft            TE Common YANG Types             February 2024


     identity te-tunnel-type {
       description
         "Base identity from which specific tunnel types are derived.";
     }

     identity te-tunnel-p2p {
       base te-tunnel-type;
       description
         "TE Point-to-Point (P2P) tunnel type.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
     }

     identity te-tunnel-p2mp {
       base te-tunnel-type;
       description
         "TE P2MP tunnel type.";
       reference
         "RFC 4875: Extensions to Resource Reservation Protocol -
          Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE
          Label Switched Paths (LSPs)";
     }

     identity tunnel-action-type {
       description
         "Base identity from which specific tunnel action types
          are derived.";
     }

     identity tunnel-action-resetup {
       base tunnel-action-type;
       description
         "TE tunnel action that tears down the tunnel's current LSP
          (if any) and attempts to re-establish a new LSP.";
     }

     identity tunnel-action-reoptimize {
       base tunnel-action-type;
       description
         "TE tunnel action that reoptimizes the placement of the
          tunnel LSP(s).";
     }

     identity tunnel-action-switchpath {
       base tunnel-action-type;
       description
         "TE tunnel action that switches the tunnel's LSP to use the
          specified path.";



Busi, et al.             Expires 25 August 2024                [Page 42]

Internet-Draft            TE Common YANG Types             February 2024


     }

     identity te-action-result {
       description
         "Base identity from which specific TE action results
          are derived.";
     }

     identity te-action-success {
       base te-action-result;
       description
         "TE action was successful.";
     }

     identity te-action-fail {
       base te-action-result;
       description
         "TE action failed.";
     }

     identity tunnel-action-inprogress {
       base te-action-result;
       description
         "TE action is in progress.";
     }

     identity tunnel-admin-state-type {
       description
         "Base identity for TE tunnel administrative states.";
     }

     identity tunnel-admin-state-up {
       base tunnel-admin-state-type;
       description
         "Tunnel's administrative state is up.";
     }

     identity tunnel-admin-state-down {
       base tunnel-admin-state-type;
       description
         "Tunnel's administrative state is down.";
     }

     // CHANGE NOTE: The identity tunnel-admin-state-auto below
     // has been added in this module revision
     // RFC Editor: remove the note above and this note
     identity tunnel-admin-state-auto {
       base tunnel-admin-state-type;



Busi, et al.             Expires 25 August 2024                [Page 43]

Internet-Draft            TE Common YANG Types             February 2024


       description
         "Tunnel administrative auto state. The administrative status
         in state datastore transitions to 'tunnel-admin-up' when the
         tunnel used by the client layer, and to 'tunnel-admin-down'
         when it is not used by the client layer.";
     }

     identity tunnel-state-type {
       description
         "Base identity for TE tunnel states.";
     }

     identity tunnel-state-up {
       base tunnel-state-type;
       description
         "Tunnel's state is up.";
     }

     identity tunnel-state-down {
       base tunnel-state-type;
       description
         "Tunnel's state is down.";
     }

     identity lsp-state-type {
       description
         "Base identity for TE LSP states.";
     }

     identity lsp-path-computing {
       base lsp-state-type;
       description
         "State path computation is in progress.";
     }

     identity lsp-path-computation-ok {
       base lsp-state-type;
       description
         "State path computation was successful.";
     }

     identity lsp-path-computation-failed {
       base lsp-state-type;
       description
         "State path computation failed.";
     }

     identity lsp-state-setting-up {



Busi, et al.             Expires 25 August 2024                [Page 44]

Internet-Draft            TE Common YANG Types             February 2024


       base lsp-state-type;
       description
         "State is being set up.";
     }

     identity lsp-state-setup-ok {
       base lsp-state-type;
       description
         "State setup was successful.";
     }

     identity lsp-state-setup-failed {
       base lsp-state-type;
       description
         "State setup failed.";
     }

     identity lsp-state-up {
       base lsp-state-type;
       description
         "State is up.";
     }

     identity lsp-state-tearing-down {
       base lsp-state-type;
       description
         "State is being torn down.";
     }

     identity lsp-state-down {
       base lsp-state-type;
       description
         "State is down.";
     }

     identity path-invalidation-action-type {
       description
         "Base identity for TE path invalidation action types.";
     }

     identity path-invalidation-action-drop {
       base path-invalidation-action-type;
       description
         "Upon invalidation of the TE tunnel path, the tunnel remains
          valid, but any packet mapped over the tunnel is dropped.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Section 2.5";



Busi, et al.             Expires 25 August 2024                [Page 45]

Internet-Draft            TE Common YANG Types             February 2024


     }

     identity path-invalidation-action-teardown {
       base path-invalidation-action-type;
       description
         "TE path invalidation action teardown.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
          Section 2.5";
     }

     identity lsp-restoration-type {
       description
         "Base identity from which LSP restoration types are derived.";
     }

       // CHANGE NOTE: The identity lsp-restoration-restore-none
       // below has been added in this module revision
       // RFC Editor: remove the note above and this note
       identity lsp-restoration-restore-none {
         base lsp-restoration-type;
         description
           "No LSP affected by a failure is restored.";
       }

     identity lsp-restoration-restore-any {
       base lsp-restoration-type;
       description
         "Any LSP affected by a failure is restored.";
     }

     identity lsp-restoration-restore-all {
       base lsp-restoration-type;
       description
         "Affected LSPs are restored after all LSPs of the tunnel are
          broken.";
     }

     identity restoration-scheme-type {
       description
         "Base identity for LSP restoration schemes.";
     }

       // CHANGE NOTE: The identity restoration-scheme-rerouting
       // below has been added in this module revision
       // RFC Editor: remove the note above and this note
       identity restoration-scheme-rerouting {
         base restoration-scheme-type;



Busi, et al.             Expires 25 August 2024                [Page 46]

Internet-Draft            TE Common YANG Types             February 2024


         description
           "Restoration LSP is computed after the failure detection.

           This restoration scheme is also known as
           'Full LSP Re-routing.'";
         reference
           "RFC 4427: Recovery (Protection and Restoration) Terminology
           for Generalized Multi-Protocol Label Switching (GMPLS)";
       }

     identity restoration-scheme-preconfigured {
       base restoration-scheme-type;
       description
         "Restoration LSP is preconfigured prior to the failure.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity restoration-scheme-precomputed {
       base restoration-scheme-type;
       description
         "Restoration LSP is precomputed prior to the failure.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity restoration-scheme-presignaled {
       base restoration-scheme-type;
       description
         "Restoration LSP is presignaled prior to the failure.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity lsp-protection-type {
       description
         "Base identity from which LSP protection types are derived.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity lsp-protection-unprotected {
       base lsp-protection-type;
       description



Busi, et al.             Expires 25 August 2024                [Page 47]

Internet-Draft            TE Common YANG Types             February 2024


         "'Unprotected' LSP protection type.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     // CHANGE NOTE: The identity lsp-protection-reroute-extra
     // below has been obsoleted in this module revision
     // RFC Editor: remove the note above and this note
     identity lsp-protection-reroute-extra {
       base lsp-protection-type;
       status obsolete;
       description
         "'(Full) Rerouting' LSP protection type.

         This identity has been obsoleted: the
         'restoration-scheme-rerouting' identity SHOULD be used
         instead.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     // CHANGE NOTE: The identity lsp-protection-reroute
     // below has been obsoleted in this module revision
     // RFC Editor: remove the note above and this note
     identity lsp-protection-reroute {
       base lsp-protection-type;
       status obsolete;
       description
         "'Rerouting without Extra-Traffic' LSP protection type.

         This identity has been obsoleted: the
         'restoration-scheme-rerouting' identity SHOULD be used
         instead.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity lsp-protection-1-for-n {
       base lsp-protection-type;
       description
         "'1:N Protection with Extra-Traffic' LSP protection type.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }



Busi, et al.             Expires 25 August 2024                [Page 48]

Internet-Draft            TE Common YANG Types             February 2024


     identity lsp-protection-1-for-1 {
       base lsp-protection-type;
       description
         "LSP protection '1:1 Protection Type'.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity lsp-protection-unidir-1-plus-1 {
       base lsp-protection-type;
       description
         "'1+1 Unidirectional Protection' LSP protection type.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity lsp-protection-bidir-1-plus-1 {
       base lsp-protection-type;
       description
         "'1+1 Bidirectional Protection' LSP protection type.";
       reference
         "RFC 4872: RSVP-TE Extensions in Support of End-to-End
          Generalized Multi-Protocol Label Switching (GMPLS) Recovery";
     }

     identity lsp-protection-extra-traffic {
       base lsp-protection-type;
       description
         "Extra-Traffic LSP protection type.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity lsp-protection-state {
       description
         "Base identity of protection states for reporting purposes.";
     }

     identity normal {
       base lsp-protection-state;
       description
         "Normal state.";
     }

     identity signal-fail-of-protection {



Busi, et al.             Expires 25 August 2024                [Page 49]

Internet-Draft            TE Common YANG Types             February 2024


       base lsp-protection-state;
       description
         "The protection transport entity has a signal fail condition
          that is of higher priority than the forced switchover
          command.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity lockout-of-protection {
       base lsp-protection-state;
       description
         "A Loss of Protection (LoP) command is active.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity forced-switch {
       base lsp-protection-state;
       description
         "A forced switchover command is active.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity signal-fail {
       base lsp-protection-state;
       description
         "There is a signal fail condition on either the working path
          or the protection path.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity signal-degrade {
       base lsp-protection-state;
       description
         "There is a signal degrade condition on either the working
          path or the protection path.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }




Busi, et al.             Expires 25 August 2024                [Page 50]

Internet-Draft            TE Common YANG Types             February 2024


     identity manual-switch {
       base lsp-protection-state;
       description
         "A manual switchover command is active.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity wait-to-restore {
       base lsp-protection-state;
       description
         "A WTR timer is running.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity do-not-revert {
       base lsp-protection-state;
       description
         "A Do Not Revert (DNR) condition is active because of
          non-revertive behavior.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity failure-of-protocol {
       base lsp-protection-state;
       description
         "LSP protection is not working because of a protocol failure
          condition.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity protection-external-commands {
       description
         "Base identity from which protection-related external commands
          used for troubleshooting purposes are derived.";
     }

     identity action-freeze {
       base protection-external-commands;
       description
         "A temporary configuration action initiated by an operator



Busi, et al.             Expires 25 August 2024                [Page 51]

Internet-Draft            TE Common YANG Types             February 2024


          command that prevents any switchover action from being taken
          and, as such, freezes the current state.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity clear-freeze {
       base protection-external-commands;
       description
         "An action that clears the active freeze state.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity action-lockout-of-normal {
       base protection-external-commands;
       description
         "A temporary configuration action initiated by an operator
          command to ensure that the normal traffic is not allowed
          to use the protection transport entity.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity clear-lockout-of-normal {
       base protection-external-commands;
       description
         "An action that clears the active lockout of the
          normal state.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity action-lockout-of-protection {
       base protection-external-commands;
       description
         "A temporary configuration action initiated by an operator
          command to ensure that the protection transport entity is
          temporarily not available to transport a traffic signal
          (either normal or Extra-Traffic).";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }



Busi, et al.             Expires 25 August 2024                [Page 52]

Internet-Draft            TE Common YANG Types             February 2024


     identity action-forced-switch {
       base protection-external-commands;
       description
         "A switchover action initiated by an operator command to switch
          the Extra-Traffic signal, the normal traffic signal, or the
          null signal to the protection transport entity, unless a
          switchover command of equal or higher priority is in effect.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity action-manual-switch {
       base protection-external-commands;
       description
         "A switchover action initiated by an operator command to switch
          the Extra-Traffic signal, the normal traffic signal, or
          the null signal to the protection transport entity, unless
          a fault condition exists on other transport entities or a
          switchover command of equal or higher priority is in effect.";
       reference
         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     // CHANGE NOTE: The description and reference of the
     // identity action-exercise have been updated in this module
     // revision
     // RFC Editor: remove the note above and this note
     identity action-exercise {
       base protection-external-commands;
       description
         "An action that starts testing whether or not Automatic
          Protection Switching (APS) communication is operating
          correctly.  It is of lower priority than any
          other state or command.";
       reference
         "ITU-T G.808.1 v4.0 (05/2014): Generic protection switching -
         Linear trail and subnetwork protection";
     }

     identity clear {
       base protection-external-commands;
       description
         "An action that clears the active near-end lockout of a
          protection, forced switchover, manual switchover, WTR state,
          or exercise command.";
       reference



Busi, et al.             Expires 25 August 2024                [Page 53]

Internet-Draft            TE Common YANG Types             February 2024


         "RFC 4427: Recovery (Protection and Restoration) Terminology
          for Generalized Multi-Protocol Label Switching (GMPLS)";
     }

     identity switching-capabilities {
       description
         "Base identity for interface switching capabilities.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity switching-psc1 {
       base switching-capabilities;
       description
         "Packet-Switch Capable-1 (PSC-1).";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity switching-evpl {
       base switching-capabilities;
       description
         "Ethernet Virtual Private Line (EVPL).";
       reference
         "RFC 6004: Generalized MPLS (GMPLS) Support for Metro Ethernet
          Forum and G.8011 Ethernet Service Switching";
     }

     identity switching-l2sc {
       base switching-capabilities;
       description
         "Layer-2 Switch Capable (L2SC).";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity switching-tdm {
       base switching-capabilities;
       description
         "Time-Division-Multiplex Capable (TDM).";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }




Busi, et al.             Expires 25 August 2024                [Page 54]

Internet-Draft            TE Common YANG Types             February 2024


     identity switching-otn {
       base switching-capabilities;
       description
         "OTN-TDM capable.";
       reference
         "RFC 7138: Traffic Engineering Extensions to OSPF for GMPLS
          Control of Evolving G.709 Optical Transport Networks";
     }

     identity switching-dcsc {
       base switching-capabilities;
       description
         "Data Channel Switching Capable (DCSC).";
       reference
         "RFC 6002: Generalized MPLS (GMPLS) Data Channel
          Switching Capable (DCSC) and Channel Set Label Extensions";
     }

     identity switching-lsc {
       base switching-capabilities;
       description
         "Lambda-Switch Capable (LSC).";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity switching-fsc {
       base switching-capabilities;
       description
         "Fiber-Switch Capable (FSC).";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-types {
       description
         "Base identity for encoding types.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-packet {
       base lsp-encoding-types;
       description
         "Packet LSP encoding.";



Busi, et al.             Expires 25 August 2024                [Page 55]

Internet-Draft            TE Common YANG Types             February 2024


       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-ethernet {
       base lsp-encoding-types;
       description
         "Ethernet LSP encoding.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-pdh {
       base lsp-encoding-types;
       description
         "ANSI/ETSI PDH LSP encoding.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-sdh {
       base lsp-encoding-types;
       description
         "SDH ITU-T G.707 / SONET ANSI T1.105 LSP encoding.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-digital-wrapper {
       base lsp-encoding-types;
       description
         "Digital Wrapper LSP encoding.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-lambda {
       base lsp-encoding-types;
       description
         "Lambda (photonic) LSP encoding.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";



Busi, et al.             Expires 25 August 2024                [Page 56]

Internet-Draft            TE Common YANG Types             February 2024


     }

     identity lsp-encoding-fiber {
       base lsp-encoding-types;
       description
         "Fiber LSP encoding.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-fiber-channel {
       base lsp-encoding-types;
       description
         "FiberChannel LSP encoding.";
       reference
         "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Functional Description";
     }

     identity lsp-encoding-oduk {
       base lsp-encoding-types;
       description
         "G.709 ODUk (Digital Path) LSP encoding.";
       reference
         "RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Extensions for G.709 Optical Transport Networks
          Control";
     }

     identity lsp-encoding-optical-channel {
       base lsp-encoding-types;
       description
         "G.709 Optical Channel LSP encoding.";
       reference
         "RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS)
          Signaling Extensions for G.709 Optical Transport Networks
          Control";
     }

     identity lsp-encoding-line {
       base lsp-encoding-types;
       description
         "Line (e.g., 8B/10B) LSP encoding.";
       reference
         "RFC 6004: Generalized MPLS (GMPLS) Support for Metro
          Ethernet Forum and G.8011 Ethernet Service Switching";
     }



Busi, et al.             Expires 25 August 2024                [Page 57]

Internet-Draft            TE Common YANG Types             February 2024


     identity path-signaling-type {
       description
         "Base identity from which specific LSP path setup types
          are derived.";
     }

     identity path-setup-static {
       base path-signaling-type;
       description
         "Static LSP provisioning path setup.";
     }

     identity path-setup-rsvp {
       base path-signaling-type;
       description
         "RSVP-TE signaling path setup.";
       reference
         "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
     }

     identity path-setup-sr {
       base path-signaling-type;
       description
         "Segment-routing path setup.";
     }

     identity path-scope-type {
       description
         "Base identity from which specific path scope types are
          derived.";
     }

     identity path-scope-segment {
       base path-scope-type;
       description
         "Path scope segment.";
       reference
         "RFC 4873: GMPLS Segment Recovery";
     }

     identity path-scope-end-to-end {
       base path-scope-type;
       description
         "Path scope end to end.";
       reference
         "RFC 4873: GMPLS Segment Recovery";
     }




Busi, et al.             Expires 25 August 2024                [Page 58]

Internet-Draft            TE Common YANG Types             February 2024


     identity route-usage-type {
       description
         "Base identity for route usage.";
     }

     identity route-include-object {
       base route-usage-type;
       description
         "'Include route' object.";
     }

     identity route-exclude-object {
       base route-usage-type;
       description
         "'Exclude route' object.";
       reference
         "RFC 4874: Exclude Routes - Extension to Resource ReserVation
          Protocol-Traffic Engineering (RSVP-TE)";
     }

     identity route-exclude-srlg {
       base route-usage-type;
       description
         "Excludes SRLGs.";
       reference
         "RFC 4874: Exclude Routes - Extension to Resource ReserVation
          Protocol-Traffic Engineering (RSVP-TE)";
     }

     // CHANGE NOTE: The path-metric-optimization-type base identity
     // has been added in this module revision
     // RFC Editor: remove the note above and this note
     identity path-metric-optimization-type {
       description
         "Base identity used to define the path metric optimization
         types.";
     }

     // CHANGE NOTE: The link-path-metric-type base identity
     // has been added in this module revision
     // RFC Editor: remove the note above and this note
     identity link-path-metric-type {
       description
         "Base identity used to define the link and the path metric
         types.

         The unit of the path metric value is interpreted in the
         context of the path metric type and the derived identities



Busi, et al.             Expires 25 August 2024                [Page 59]

Internet-Draft            TE Common YANG Types             February 2024


         SHOULD describe the unit of the path metric types they
         define.";
     }

       // CHANGE NOTE: The link-metric-type base identity
       // and its derived identities
       // have been added in this module revision
       // RFC Editor: remove the note above and this note
       identity link-metric-type {
         base link-path-metric-type;
         description
           "Base identity for the link metric types.";
       }

         identity link-metric-te {
           base link-metric-type;
           description
             "Traffic Engineering (TE) Link Metric.";
           reference
             "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
             Version 2, section 2.5.5

             RFC 5305: IS-IS Extensions for Traffic Engineering,
             section 3.7";
         }

         identity link-metric-igp {
           base link-metric-type;
           description
             "Interior Gateway Protocol (IGP) Link Metric.";
           reference
             "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric
             as a second MPLS Traffic Engineering (TE) Metric";
         }

         identity link-metric-delay-average {
           base link-metric-type;
           description
             "Unidirectional Link Delay, measured in units of
             microseconds.";
           reference
             "RFC 7471: OSPF Traffic Engineering (TE) Metric
             Extensions, section 4.1

             RFC 8570: IS-IS Traffic Engineering (TE) Metric
             Extensions, section 4.1";
         }




Busi, et al.             Expires 25 August 2024                [Page 60]

Internet-Draft            TE Common YANG Types             February 2024


         identity link-metric-delay-minimum {
           base link-metric-type;
           description
             "Minimum unidirectional Link Delay, measured in units of
             microseconds.";
           reference
             "RFC 7471: OSPF Traffic Engineering (TE) Metric
             Extensions, section 4.2

             RFC 8570: IS-IS Traffic Engineering (TE) Metric
             Extensions, section 4.2";
         }

         identity link-metric-delay-maximum {
           base link-metric-type;
           description
             "Maximum unidirectional Link Delay, measured in units of
             microseconds.";
           reference
             "RFC 7471: OSPF Traffic Engineering (TE) Metric
             Extensions, section 4.2

             RFC 8570: IS-IS Traffic Engineering (TE) Metric
             Extensions, section 4.2";
         }

         identity link-metric-residual-bandwidth {
           base link-metric-type;
           description
             "Unidirectional Residual Bandwidth, measured in units of
             bytes per second.

             It is defined to be Maximum Bandwidth minus the bandwidth
             currently allocated to LSPs.";
           reference
             "RFC 7471: OSPF Traffic Engineering (TE) Metric
             Extensions, section 4.5

             RFC 8570: IS-IS Traffic Engineering (TE) Metric
             Extensions, section 4.5";
         }

       // CHANGE NOTE: The base and the description of the
       // path-metric-type identity
       // has been updated in this module revision
       // RFC Editor: remove the note above and this note
       identity path-metric-type {
         base link-path-metric-type;



Busi, et al.             Expires 25 August 2024                [Page 61]

Internet-Draft            TE Common YANG Types             February 2024


         base path-metric-optimization-type;
         description
           "Base identity for the path metric types.";
       }

         // CHANGE NOTE: The description and the reference of the
         // path-metric-te identity have been updated
         // in this module revision
         // RFC Editor: remove the note above and this note
         identity path-metric-te {
           base path-metric-type;
           description
             "Traffic Engineering (TE) Path Metric.";
           reference
             "RFC 5440: Path Computation Element (PCE) Communication
             Protocol (PCEP), section 7.8";
         }

         // CHANGE NOTE: The description and the reference of the
         // path-metric-igp identity have been updated
         // in this module revision
         // RFC Editor: remove the note above and this note
         identity path-metric-igp {
           base path-metric-type;
           description
             "Interior Gateway Protocol (IGP) Path Metric.";
           reference
             "RFC 5440: Path Computation Element (PCE) Communication
             Protocol (PCEP), section 7.8";
         }

         // CHANGE NOTE: The description and the reference of the
         // path-metric-hop identity have been updated
         // in this module revision
         // RFC Editor: remove the note above and this note
         identity path-metric-hop {
           base path-metric-type;
           description
             "Hop Count Path Metric.";
           reference
             "RFC 5440: Path Computation Element (PCE) Communication
             Protocol (PCEP), section 7.8";
         }

         // CHANGE NOTE: The description and the reference of the
         // path-metric-delay-average identity have been updated
         // in this module revision
         // RFC Editor: remove the note above and this note



Busi, et al.             Expires 25 August 2024                [Page 62]

Internet-Draft            TE Common YANG Types             February 2024


         identity path-metric-delay-average {
           base path-metric-type;
           description
             "The Path Delay Metric, measured in units of
             microseconds.";
           reference
             "RFC8233: Extensions to the Path Computation Element
             Communication Protocol (PCEP) to Compute Service-Aware
             Label Switched Paths (LSPs), section 3.1.1";
         }

         // CHANGE NOTE: The description and the reference of the
         // path-metric-delay-minimum identity have been updated
         // in this module revision
         // RFC Editor: remove the note above and this note
         identity path-metric-delay-minimum {
           base path-metric-type;
           description
             "The Path Min Delay Metric, measured in units of
             microseconds.";
           reference
             "I-D.ietf-pce-sid-algo: Carrying SR-Algorithm information
             in PCE-based Networks, section 3.5.1";
         }

         // CHANGE NOTE: The description and the reference of the
         // path-metric-residual-bandwidth identity have been updated
         // in this module revision
         // RFC Editor: remove the note above and this note
         identity path-metric-residual-bandwidth {
           base path-metric-type;
           description
             "The Path Residual Bandwidth, defined as the minimum Link
             Residual Bandwidth all the links along the path.

             The Path Residual Bandwidth can be seen as the path
             metric associated with the Maximum residual Bandwidth Path
             (MBP) objective function.";
           reference
             "RFC 5541: Encoding of Objective Functions in the Path
             Computation Element Communication Protocol (PCEP)";
         }

       // CHANGE NOTE: The base of the path-metric-optimize-includes
       // identity has been updated in this module revision
       // RFC Editor: remove the note above and this note
       identity path-metric-optimize-includes {
         base path-metric-optimization-type;



Busi, et al.             Expires 25 August 2024                [Page 63]

Internet-Draft            TE Common YANG Types             February 2024


         description
           "A metric that optimizes the number of included resources
           specified in a set.";
       }

       // CHANGE NOTE: The base of the path-metric-optimize-excludes
       // identity has been updated in this module revision
       // RFC Editor: remove the note above and this note
       identity path-metric-optimize-excludes {
         base path-metric-optimization-type;
         description
           "A metric that optimizes to a maximum the number of excluded
           resources specified in a set.";
       }

     identity path-tiebreaker-type {
       description
         "Base identity for the path tiebreaker type.";
     }

     identity path-tiebreaker-minfill {
       base path-tiebreaker-type;
       description
         "Min-Fill LSP path placement.";
     }

     identity path-tiebreaker-maxfill {
       base path-tiebreaker-type;
       description
         "Max-Fill LSP path placement.";
     }

     identity path-tiebreaker-random {
       base path-tiebreaker-type;
       description
         "Random LSP path placement.";
     }

     identity resource-affinities-type {
       description
         "Base identity for resource class affinities.";
       reference
         "RFC 2702: Requirements for Traffic Engineering Over MPLS";
     }

     identity resource-aff-include-all {
       base resource-affinities-type;
       description



Busi, et al.             Expires 25 August 2024                [Page 64]

Internet-Draft            TE Common YANG Types             February 2024


         "The set of attribute filters associated with a
          tunnel, all of which must be present for a link
          to be acceptable.";
       reference
         "RFC 2702: Requirements for Traffic Engineering Over MPLS
          RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
     }

     identity resource-aff-include-any {
       base resource-affinities-type;
       description
         "The set of attribute filters associated with a
          tunnel, any of which must be present for a link
          to be acceptable.";
       reference
         "RFC 2702: Requirements for Traffic Engineering Over MPLS
          RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
     }

     identity resource-aff-exclude-any {
       base resource-affinities-type;
       description
         "The set of attribute filters associated with a
          tunnel, any of which renders a link unacceptable.";
       reference
         "RFC 2702: Requirements for Traffic Engineering Over MPLS
          RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
     }

     // CHANGE NOTE: The reference of the identity
     // te-optimization-criterion below has been updated
     // in this module revision
     // RFC Editor: remove the note above and this note
     identity te-optimization-criterion {
       description
         "Base identity for the TE optimization criteria.";
       reference
         "RFC 9522: Overview and Principles of Internet Traffic
          Engineering";
     }

     identity not-optimized {
       base te-optimization-criterion;
       description
         "Optimization is not applied.";
     }

     identity cost {



Busi, et al.             Expires 25 August 2024                [Page 65]

Internet-Draft            TE Common YANG Types             February 2024


       base te-optimization-criterion;
       description
         "Optimized on cost.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
          Computation Element Communication Protocol (PCEP)";
     }

     identity delay {
       base te-optimization-criterion;
       description
         "Optimized on delay.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
          Computation Element Communication Protocol (PCEP)";
     }

     identity path-computation-srlg-type {
       description
         "Base identity for SRLG path computation.";
     }

     identity srlg-ignore {
       base path-computation-srlg-type;
       description
         "Ignores SRLGs in the path computation.";
     }

     identity srlg-strict {
       base path-computation-srlg-type;
       description
         "Includes a strict SRLG check in the path computation.";
     }

     identity srlg-preferred {
       base path-computation-srlg-type;
       description
         "Includes a preferred SRLG check in the path computation.";
     }

     identity srlg-weighted {
       base path-computation-srlg-type;
       description
         "Includes a weighted SRLG check in the path computation.";
     }

     // CHANGE NOTE: The base identity path-computation-error-reason
     // and its derived identities below have been



Busi, et al.             Expires 25 August 2024                [Page 66]

Internet-Draft            TE Common YANG Types             February 2024


     // added in this module revision
     // RFC Editor: remove the note above and this note
     identity path-computation-error-reason {
       description
         "Base identity for path computation error reasons.";
     }

       identity path-computation-error-path-not-found {
         base path-computation-error-reason;
         description
           "Path computation has failed because of an unspecified
           reason.";
         reference
           "RFC 5440: Path Computation Element (PCE) Communication
           Protocol (PCEP), section 7.5";
       }

       identity path-computation-error-no-topology {
         base path-computation-error-reason;
         description
           "Path computation has failed because there is no topology
           with the provided topology-identifier.";
       }

       identity path-computation-error-no-dependent-server {
         base path-computation-error-reason;
         description
           "Path computation has failed because one or more dependent
           path computation servers are unavailable.

           The dependent path computation server could be
           a Backward-Recursive Path Computation (BRPC) downstream
           PCE or a child PCE.";
         reference
           "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC)
           Procedure to Compute Shortest Constrained Inter-Domain
           Traffic Engineering Label Switched Paths

           RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture";
       }

       identity path-computation-error-pce-unavailable {
         base path-computation-error-reason;
         description
           "Path computation has failed because PCE is not available.




Busi, et al.             Expires 25 August 2024                [Page 67]

Internet-Draft            TE Common YANG Types             February 2024


           It corresponds to bit 31 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 5440: Path Computation Element (PCE) Communication
           Protocol (PCEP)

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-no-inclusion-hop {
         base path-computation-error-reason;
         description
           "Path computation has failed because there is no
           node or link provided by one or more inclusion hops.";
       }

       identity path-computation-error-destination-unknown-in-domain {
         base path-computation-error-reason;
         description
           "Path computation has failed because the destination node is
           unknown in indicated destination domain.

           It corresponds to bit 19 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-no-resource {
         base path-computation-error-reason;
         description
           "Path computation has failed because there is no
           available resource in one or more domains.

           It corresponds to bit 20 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture

           https://www.iana.org/assignments/pcep



Busi, et al.             Expires 25 August 2024                [Page 68]

Internet-Draft            TE Common YANG Types             February 2024


           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-child-pce-unresponsive {
         base path-computation-error-no-dependent-server;
         description
           "Path computation has failed because child PCE is not
           responsive.

           It corresponds to bit 21 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-destination-domain-unknown {
         base path-computation-error-reason;
         description
           "Path computation has failed because the destination domain
           was unknown.

           It corresponds to bit 22 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-p2mp {
         base path-computation-error-reason;
         description
           "Path computation has failed because of P2MP reachability
           problem.

           It corresponds to bit 24 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 8306: Extensions to the Path Computation Element
           Communication Protocol (PCEP) for Point-to-Multipoint



Busi, et al.             Expires 25 August 2024                [Page 69]

Internet-Draft            TE Common YANG Types             February 2024


           Traffic Engineering Label Switched Paths

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-no-gco-migration {
         base path-computation-error-reason;
         description
           "Path computation has failed because of no Global Concurrent
           Optimization (GCO) migration path found.

           It corresponds to bit 26 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 5557: Path Computation Element Communication Protocol
           (PCEP) Requirements and Protocol Extensions in Support of
           Global Concurrent Optimization

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-no-gco-solution {
         base path-computation-error-reason;
         description
           "Path computation has failed because of no GCO solution
           found.

           It corresponds to bit 25 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 5557: Path Computation Element Communication Protocol
           (PCEP) Requirements and Protocol Extensions in Support of
           Global Concurrent Optimization

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-pks-expansion {
         base path-computation-error-reason;
         description
           "Path computation has failed because of Path-Key Subobject
           (PKS)  expansion failure.

           It corresponds to bit 27 of the Flags field of the
           NO-PATH-VECTOR TLV.";



Busi, et al.             Expires 25 August 2024                [Page 70]

Internet-Draft            TE Common YANG Types             February 2024


         reference
           "RFC 5520: Preserving Topology Confidentiality in
           Inter-Domain Path Computation Using a Path-Key-Based
           Mechanism

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-brpc-chain-unavailable {
         base path-computation-error-no-dependent-server;
         description
           "Path computation has failed because PCE BRPC chain
           unavailable.

           It corresponds to bit 28 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC)
           Procedure to Compute Shortest Constrained Inter-Domain
           Traffic Engineering Label Switched Paths

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-source-unknown {
         base path-computation-error-reason;
         description
           "Path computation has failed because source node is
           unknown.

           It corresponds to bit 29 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 5440: Path Computation Element (PCE) Communication
           Protocol (PCEP);

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-destination-unknown {
         base path-computation-error-reason;
         description
           "Path computation has failed because destination node is
           unknown.




Busi, et al.             Expires 25 August 2024                [Page 71]

Internet-Draft            TE Common YANG Types             February 2024


           It corresponds to bit 30 of the Flags field of the
           NO-PATH-VECTOR TLV.";
         reference
           "RFC 5440: Path Computation Element (PCE) Communication
           Protocol (PCEP);

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

       identity path-computation-error-no-server {
         base path-computation-error-reason;
         description
           "Path computation has failed because path computation
           server is unavailable.";
         reference
           "RFC 5440: Path Computation Element (PCE) Communication
           Protocol (PCEP);

           https://www.iana.org/assignments/pcep
           /pcep.xhtml#no-path-vector-tlv";
       }

     // CHANGE NOTE: The base identity protocol-origin-type and
     // its derived identities below have been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     identity protocol-origin-type {
       description
         "Base identity for protocol origin type.";
     }

       identity protocol-origin-api {
         base protocol-origin-type;
         description
           "Protocol origin is via Application Programmable Interface
           (API).";
       }

       identity protocol-origin-pcep {
         base protocol-origin-type;
         description
           "Protocol origin is Path Computation Engine Protocol
           (PCEP).";
         reference
           "RFC 5440: Path Computation Element (PCE) Communication
           Protocol (PCEP)";
       }



Busi, et al.             Expires 25 August 2024                [Page 72]

Internet-Draft            TE Common YANG Types             February 2024


       identity protocol-origin-bgp {
         base protocol-origin-type;
         description
           "Protocol origin is Border Gateway Protocol (BGP).";
         reference "RFC 9012";
       }

     // CHANGE NOTE: The base identity svec-objective-function-type
     // and its derived identities below have been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     identity svec-objective-function-type {
       description
         "Base identity for SVEC objective function type.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
          Computation Element Communication Protocol (PCEP)";
     }

       identity svec-of-minimize-agg-bandwidth-consumption {
         base svec-objective-function-type;
         description
           "Objective function for minimizing aggregate bandwidth
           consumption (MBC).";
         reference
           "RFC 5541: Encoding of Objective Functions in the Path
           Computation Element Communication Protocol (PCEP)";
       }

       identity svec-of-minimize-load-most-loaded-link {
         base svec-objective-function-type;
         description
           "Objective function for minimizing the load on the link that
           is carrying the highest load (MLL).";
         reference
           "RFC 5541: Encoding of Objective Functions in the Path
           Computation Element Communication Protocol (PCEP)";
       }

       identity svec-of-minimize-cost-path-set {
         base svec-objective-function-type;
         description
           "Objective function for minimizing the cost on a path set
           (MCC).";
         reference
           "RFC 5541: Encoding of Objective Functions in the Path
           Computation Element Communication Protocol (PCEP)";
       }



Busi, et al.             Expires 25 August 2024                [Page 73]

Internet-Draft            TE Common YANG Types             February 2024


       identity svec-of-minimize-common-transit-domain {
         base svec-objective-function-type;
         description
           "Objective function for minimizing the number of common
           transit domains (MCTD).";
         reference
           "RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture";
       }

       identity svec-of-minimize-shared-link {
         base svec-objective-function-type;
         description
           "Objective function for minimizing the number of shared
           links (MSL).";
         reference
           "RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture.";
       }

       identity svec-of-minimize-shared-srlg {
         base svec-objective-function-type;
         description
           "Objective function for minimizing the number of shared
           Shared Risk Link Groups (SRLG) (MSS).";
         reference
           "RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture.";
       }

       identity svec-of-minimize-shared-nodes {
         base svec-objective-function-type;
         description
           "Objective function for minimizing the number of shared
           nodes (MSN).";
         reference
           "RFC 8685: Path Computation Element Communication Protocol
           (PCEP) Extensions for the Hierarchical Path Computation
           Element (H-PCE) Architecture.";
       }

     // CHANGE NOTE: The base identity svec-metric-type and
     // its derived identities below have been
     // added in this module revision
     // RFC Editor: remove the note above and this note



Busi, et al.             Expires 25 August 2024                [Page 74]

Internet-Draft            TE Common YANG Types             February 2024


     identity svec-metric-type {
       description
         "Base identity for SVEC metric type.";
       reference
         "RFC 5541: Encoding of Objective Functions in the Path
          Computation Element Communication Protocol (PCEP)";
     }

       identity svec-metric-cumulative-te {
         base svec-metric-type;
         description
           "Cumulative TE cost.";
         reference
           "RFC 5541: Encoding of Objective Functions in the Path
           Computation Element Communication Protocol (PCEP)";
       }

       identity svec-metric-cumulative-igp {
         base svec-metric-type;
         description
           "Cumulative IGP cost.";
         reference
           "RFC 5541: Encoding of Objective Functions in the Path
           Computation Element Communication Protocol (PCEP)";
       }

       identity svec-metric-cumulative-hop {
         base svec-metric-type;
         description
           "Cumulative Hop path metric.";
         reference
           "RFC 5541: Encoding of Objective Functions in the Path
           Computation Element Communication Protocol (PCEP)";
       }

       identity svec-metric-aggregate-bandwidth-consumption {
         base svec-metric-type;
         description
           "Aggregate bandwidth consumption.";
         reference
           "RFC 5541: Encoding of Objective Functions in the Path
           Computation Element Communication Protocol (PCEP)";
       }

       identity svec-metric-load-of-the-most-loaded-link {
         base svec-metric-type;
         description
           "Load of the most loaded link.";



Busi, et al.             Expires 25 August 2024                [Page 75]

Internet-Draft            TE Common YANG Types             February 2024


         reference
           "RFC 5541: Encoding of Objective Functions in the Path
           Computation Element Communication Protocol (PCEP)";
       }

     /**
      * TE bandwidth groupings
      **/

     grouping te-bandwidth {
       description
         "This grouping defines the generic TE bandwidth.
          For some known data-plane technologies, specific modeling
          structures are specified.  The string-encoded 'te-bandwidth'
          type is used for unspecified technologies.
          The modeling structure can be augmented later for other
          technologies.";
       container te-bandwidth {
         description
           "Container that specifies TE bandwidth.  The choices
            can be augmented for specific data-plane technologies.";
         choice technology {
           default "generic";
           description
             "Data-plane technology type.";
           case generic {
             leaf generic {
               type te-bandwidth;
               description
                 "Bandwidth specified in a generic format.";
             }
           }
         }
       }
     }

     /**
      * TE label groupings
      **/

     grouping te-label {
       description
         "This grouping defines the generic TE label.
          The modeling structure can be augmented for each technology.
          For unspecified technologies, 'rt-types:generalized-label'
          is used.";
       container te-label {
         description



Busi, et al.             Expires 25 August 2024                [Page 76]

Internet-Draft            TE Common YANG Types             February 2024


           "Container that specifies the TE label.  The choices can
            be augmented for specific data-plane technologies.";
         choice technology {
           default "generic";
           description
             "Data-plane technology type.";
           case generic {
             leaf generic {
               type rt-types:generalized-label;
               description
                 "TE label specified in a generic format.";
             }
           }
         }
         leaf direction {
           type te-label-direction;
           default "forward";
           description
             "Label direction.";
         }
       }
     }

     grouping te-topology-identifier {
       description
         "Augmentation for a TE topology.";
       container te-topology-identifier {
         description
           "TE topology identifier container.";
         leaf provider-id {
           type te-global-id;
           default "0";
           description
             "An identifier to uniquely identify a provider.
              If omitted, it assumes that the topology provider ID
              value = 0 (the default).";
         }
         leaf client-id {
           type te-global-id;
           default "0";
           description
             "An identifier to uniquely identify a client.
              If omitted, it assumes that the topology client ID
              value = 0 (the default).";
         }
         leaf topology-id {
           type te-topology-id;
           default "";



Busi, et al.             Expires 25 August 2024                [Page 77]

Internet-Draft            TE Common YANG Types             February 2024


           description
             "When the datastore contains several topologies,
              'topology-id' distinguishes between them.  If omitted,
              the default (empty) string for this leaf is assumed.";
         }
       }
     }

     /**
      * TE performance metrics groupings
      **/

     grouping performance-metrics-one-way-delay-loss {
       description
         "Performance Metrics (PM) information in real time that can
          be applicable to links or connections.  PM defined in this
          grouping are applicable to generic TE PM as well as packet TE
          PM.";
       reference
         "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions

         RFC 7823: Performance-Based Path Selection for Explicitly
         Routed Label Switched Paths (LSPs) Using TE Metric
         Extensions

         RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
       leaf one-way-delay {
         type uint32 {
           range "0..16777215";
         }
         description
           "One-way delay or latency in microseconds.";
       }
       leaf one-way-delay-normality {
         type te-types:performance-metrics-normality;
         description
           "One-way delay normality.";
       }
     }

     grouping performance-metrics-two-way-delay-loss {
       description
         "PM information in real time that can be applicable to links or
          connections.  PM defined in this grouping are applicable to
          generic TE PM as well as packet TE PM.";
       reference
         "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
          RFC 7823: Performance-Based Path Selection for Explicitly



Busi, et al.             Expires 25 August 2024                [Page 78]

Internet-Draft            TE Common YANG Types             February 2024


          Routed Label Switched Paths (LSPs) Using TE Metric
          Extensions
          RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
       leaf two-way-delay {
         type uint32 {
           range "0..16777215";
         }
         description
           "Two-way delay or latency in microseconds.";
       }
       leaf two-way-delay-normality {
         type te-types:performance-metrics-normality;
         description
           "Two-way delay normality.";
       }
     }

     grouping performance-metrics-one-way-bandwidth {
       description
         "PM information in real time that can be applicable to links.
          PM defined in this grouping are applicable to generic TE PM
          as well as packet TE PM.";
       reference
         "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
          RFC 7823: Performance-Based Path Selection for Explicitly
          Routed Label Switched Paths (LSPs) Using TE Metric
          Extensions
          RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
       leaf one-way-residual-bandwidth {
         type rt-types:bandwidth-ieee-float32;
         units "bytes per second";
         default "0x0p0";
         description
           "Residual bandwidth that subtracts tunnel reservations from
            Maximum Bandwidth (or link capacity) (RFC 3630) and
            provides an aggregated remainder across QoS classes.";
         reference
           "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
            Version 2";
       }
       leaf one-way-residual-bandwidth-normality {
         type te-types:performance-metrics-normality;
         default "normal";
         description
           "Residual bandwidth normality.";
       }
       leaf one-way-available-bandwidth {
         type rt-types:bandwidth-ieee-float32;



Busi, et al.             Expires 25 August 2024                [Page 79]

Internet-Draft            TE Common YANG Types             February 2024


         units "bytes per second";
         default "0x0p0";
         description
           "Available bandwidth that is defined to be residual
            bandwidth minus the measured bandwidth used for the
            actual forwarding of non-RSVP-TE LSP packets.  For a
            bundled link, available bandwidth is defined to be the
            sum of the component link available bandwidths.";
       }
       leaf one-way-available-bandwidth-normality {
         type te-types:performance-metrics-normality;
         default "normal";
         description
           "Available bandwidth normality.";
       }
       leaf one-way-utilized-bandwidth {
         type rt-types:bandwidth-ieee-float32;
         units "bytes per second";
         default "0x0p0";
         description
           "Bandwidth utilization that represents the actual
            utilization of the link (i.e., as measured in the router).
            For a bundled link, bandwidth utilization is defined to
            be the sum of the component link bandwidth utilizations.";
       }
       leaf one-way-utilized-bandwidth-normality {
         type te-types:performance-metrics-normality;
         default "normal";
         description
           "Bandwidth utilization normality.";
       }
     }

     grouping one-way-performance-metrics {
       description
         "One-way PM throttle grouping.";
       leaf one-way-delay {
         type uint32 {
           range "0..16777215";
         }
         default "0";
         description
           "One-way delay or latency in microseconds.";
       }
       leaf one-way-residual-bandwidth {
         type rt-types:bandwidth-ieee-float32;
         units "bytes per second";
         default "0x0p0";



Busi, et al.             Expires 25 August 2024                [Page 80]

Internet-Draft            TE Common YANG Types             February 2024


         description
           "Residual bandwidth that subtracts tunnel reservations from
            Maximum Bandwidth (or link capacity) (RFC 3630) and
            provides an aggregated remainder across QoS classes.";
         reference
           "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
            Version 2";
       }
       leaf one-way-available-bandwidth {
         type rt-types:bandwidth-ieee-float32;
         units "bytes per second";
         default "0x0p0";
         description
           "Available bandwidth that is defined to be residual
            bandwidth minus the measured bandwidth used for the
            actual forwarding of non-RSVP-TE LSP packets.  For a
            bundled link, available bandwidth is defined to be the
            sum of the component link available bandwidths.";
       }
       leaf one-way-utilized-bandwidth {
         type rt-types:bandwidth-ieee-float32;
         units "bytes per second";
         default "0x0p0";
         description
           "Bandwidth utilization that represents the actual
            utilization of the link (i.e., as measured in the router).
            For a bundled link, bandwidth utilization is defined to
            be the sum of the component link bandwidth utilizations.";
       }
     }

     grouping two-way-performance-metrics {
       description
         "Two-way PM throttle grouping.";
       leaf two-way-delay {
         type uint32 {
           range "0..16777215";
         }
         default "0";
         description
           "Two-way delay or latency in microseconds.";
       }
     }

     grouping performance-metrics-thresholds {
       description
         "Grouping for configurable thresholds for measured
          attributes.";



Busi, et al.             Expires 25 August 2024                [Page 81]

Internet-Draft            TE Common YANG Types             February 2024


       uses one-way-performance-metrics;
       uses two-way-performance-metrics;
     }

     grouping performance-metrics-attributes {
       description
         "Contains PM attributes.";
       container performance-metrics-one-way {
         description
           "One-way link performance information in real time.";
         reference
           "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
            RFC 7823: Performance-Based Path Selection for Explicitly
            Routed Label Switched Paths (LSPs) Using TE Metric
            Extensions
            RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
         uses performance-metrics-one-way-delay-loss;
         uses performance-metrics-one-way-bandwidth;
       }
       container performance-metrics-two-way {
         description
           "Two-way link performance information in real time.";
         reference
           "RFC 6374: Packet Loss and Delay Measurement for MPLS
            Networks";
         uses performance-metrics-two-way-delay-loss;
       }
     }

     grouping performance-metrics-throttle-container {
       description
         "Controls PM throttling.";
       container throttle {
         must 'suppression-interval >= measure-interval' {
           error-message "'suppression-interval' cannot be less than "
                       + "'measure-interval'.";
           description
             "Constraint on 'suppression-interval' and
              'measure-interval'.";
         }
         description
           "Link performance information in real time.";
         reference
           "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
            RFC 7823: Performance-Based Path Selection for Explicitly
            Routed Label Switched Paths (LSPs) Using TE Metric
            Extensions
            RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";



Busi, et al.             Expires 25 August 2024                [Page 82]

Internet-Draft            TE Common YANG Types             February 2024


         leaf one-way-delay-offset {
           type uint32 {
             range "0..16777215";
           }
           default "0";
           description
             "Offset value to be added to the measured delay value.";
         }
         leaf measure-interval {
           type uint32;
           default "30";
           description
             "Interval, in seconds, to measure the extended metric
              values.";
         }
         leaf advertisement-interval {
           type uint32;
           default "0";
           description
             "Interval, in seconds, to advertise the extended metric
              values.";
         }
         leaf suppression-interval {
           type uint32 {
             range "1..max";
           }
           default "120";
           description
             "Interval, in seconds, to suppress advertisement of the
              extended metric values.";
           reference
             "RFC 8570: IS-IS Traffic Engineering (TE) Metric
              Extensions, Section 6";
         }
         container threshold-out {
           uses performance-metrics-thresholds;
           description
             "If the measured parameter falls outside an upper bound
              for all but the minimum-delay metric (or a lower bound
              for the minimum-delay metric only) and the advertised
              value is not already outside that bound, an 'anomalous'
              announcement (anomalous bit set) will be triggered.";
         }
         container threshold-in {
           uses performance-metrics-thresholds;
           description
             "If the measured parameter falls inside an upper bound
              for all but the minimum-delay metric (or a lower bound



Busi, et al.             Expires 25 August 2024                [Page 83]

Internet-Draft            TE Common YANG Types             February 2024


              for the minimum-delay metric only) and the advertised
              value is not already inside that bound, a 'normal'
              announcement (anomalous bit cleared) will be triggered.";
         }
         container threshold-accelerated-advertisement {
           description
             "When the difference between the last advertised value and
              the current measured value exceeds this threshold, an
              'anomalous' announcement (anomalous bit set) will be
              triggered.";
           uses performance-metrics-thresholds;
         }
       }
     }

     /**
      * TE tunnel generic groupings
      **/

     // CHANGE NOTE: The explicit-route-hop grouping below has been
     // updated in this module revision
     // RFC Editor: remove the note above and this note
     grouping explicit-route-hop {
       description
         "The explicit route entry grouping.";
       choice type {
         description
           "The explicit route entry type.";
         case numbered-node-hop {
           container numbered-node-hop {
             must "node-id-uri or node-id" {
               description
                 "At least one node identifier MUST be present.";
             }
             leaf node-id-uri {
               type nw:node-id;
               description
                 "The identifier of a node in the topology.";
             }
             leaf node-id {
               type te-node-id;
               description
                 "The identifier of a node in the TE topology.";
             }
             leaf hop-type {
               type te-hop-type;
               default "strict";
               description



Busi, et al.             Expires 25 August 2024                [Page 84]

Internet-Draft            TE Common YANG Types             February 2024


                 "Strict or loose hop.";
             }
             description
               "Numbered node route hop.";
             reference
               "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                Section 4.3, EXPLICIT_ROUTE in RSVP-TE
                RFC 3477: Signalling Unnumbered Links in Resource
                ReSerVation Protocol - Traffic Engineering (RSVP-TE)";
           }
         }
         case numbered-link-hop {
           container numbered-link-hop {
             leaf link-tp-id {
               type te-tp-id;
               mandatory true;
               description
                 "TE Link Termination Point (LTP) identifier.";
             }
             leaf hop-type {
               type te-hop-type;
               default "strict";
               description
                 "Strict or loose hop.";
             }
             leaf direction {
               type te-link-direction;
               default "outgoing";
               description
                 "Link route object direction.";
             }
             description
               "Numbered link explicit route hop.";
             reference
               "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                Section 4.3, EXPLICIT_ROUTE in RSVP-TE
                RFC 3477: Signalling Unnumbered Links in Resource
                ReSerVation Protocol - Traffic Engineering (RSVP-TE)";
           }
         }
         case unnumbered-link-hop {
           container unnumbered-link-hop {
             must "(link-tp-id-uri or link-tp-id) and " +
                   "(node-id-uri or node-id)" {
               description
                 "At least one node identifier and at least one Link
                 Termination Point (LTP) identifier MUST be present.";
             }



Busi, et al.             Expires 25 August 2024                [Page 85]

Internet-Draft            TE Common YANG Types             February 2024


             leaf link-tp-id-uri {
               type nt:tp-id;
               description
                 "Link Termination Point (LTP) identifier.";
             }
             leaf link-tp-id {
               type te-tp-id;
               description
                 "TE LTP identifier.  The combination of the TE link ID
                  and the TE node ID is used to identify an unnumbered
                  TE link.";
             }
             leaf node-id-uri {
               type nw:node-id;
               description
                 "The identifier of a node in the topology.";
             }
             leaf node-id {
               type te-node-id;
               description
                 "The identifier of a node in the TE topology.";
             }
             leaf hop-type {
               type te-hop-type;
               default "strict";
               description
                 "Strict or loose hop.";
             }
             leaf direction {
               type te-link-direction;
               default "outgoing";
               description
                 "Link route object direction.";
             }
             description
               "Unnumbered link explicit route hop.";
             reference
               "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                Section 4.3, EXPLICIT_ROUTE in RSVP-TE
                RFC 3477: Signalling Unnumbered Links in Resource
                ReSerVation Protocol - Traffic Engineering (RSVP-TE)";
           }
         }
         case as-number {
           container as-number-hop {
             leaf as-number {
               type inet:as-number;
               mandatory true;



Busi, et al.             Expires 25 August 2024                [Page 86]

Internet-Draft            TE Common YANG Types             February 2024


               description
                 "The Autonomous System (AS) number.";
             }
             leaf hop-type {
               type te-hop-type;
               default "strict";
               description
                 "Strict or loose hop.";
             }
             description
               "AS explicit route hop.";
           }
         }
         case label {
           container label-hop {
             description
               "Label hop type.";
             uses te-label;
           }
           description
             "The label explicit route hop type.";
         }
       }
     }

     // CHANGE NOTE: The explicit-route-hop grouping below has been
     // updated in this module revision
     // RFC Editor: remove the note above and this note
     grouping record-route-state {
       description
         "The Record Route grouping.";
       leaf index {
         type uint32;
         description
           "Record Route hop index.  The index is used to
            identify an entry in the list.  The order of entries
            is defined by the user without relying on key values.";
       }
       choice type {
         description
           "The Record Route entry type.";
         case numbered-node-hop {
           container numbered-node-hop {
             must "node-id-uri or node-id" {
               description
                 "At least one node identifier MUST be present.";
             }
             description



Busi, et al.             Expires 25 August 2024                [Page 87]

Internet-Draft            TE Common YANG Types             February 2024


               "Numbered node route hop container.";
             leaf node-id-uri {
               type nw:node-id;
               description
                 "The identifier of a node in the topology.";
             }
             leaf node-id {
               type te-node-id;
               description
                 "The identifier of a node in the TE topology.";
             }
             leaf-list flags {
               type path-attribute-flags;
               description
                 "Path attributes flags.";
               reference
                 "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
                  RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                  Tunnels
                  RFC 4561: Definition of a Record Route Object (RRO)
                  Node-Id Sub-Object";
             }
           }
           description
             "Numbered node route hop.";
         }
         case numbered-link-hop {
           container numbered-link-hop {
             description
               "Numbered link route hop container.";
             leaf link-tp-id {
               type te-tp-id;
               mandatory true;
               description
                 "Numbered TE LTP identifier.";
             }
             leaf-list flags {
               type path-attribute-flags;
               description
                 "Path attributes flags.";
               reference
                 "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
                  RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                  Tunnels
                  RFC 4561: Definition of a Record Route Object (RRO)
                  Node-Id Sub-Object";
             }
           }



Busi, et al.             Expires 25 August 2024                [Page 88]

Internet-Draft            TE Common YANG Types             February 2024


           description
             "Numbered link route hop.";
         }
         case unnumbered-link-hop {
           container unnumbered-link-hop {
             must "(link-tp-id-uri or link-tp-id) and " +
                 "(node-id-uri or node-id)" {
               description
                 "At least one node identifier and at least one Link
                 Termination Point (LTP) identifier MUST be present.";
             }
             leaf link-tp-id-uri {
               type nt:tp-id;
               description
                 "Link Termination Point (LTP) identifier.";
             }
             leaf link-tp-id {
               type te-tp-id;
               description
                 "TE LTP identifier.  The combination of the TE link ID
                  and the TE node ID is used to identify an unnumbered
                  TE link.";
             }
             leaf node-id-uri {
               type nw:node-id;
               description
                 "The identifier of a node in the topology.";
             }
             leaf node-id {
               type te-node-id;
               description
                 "The identifier of a node in the TE topology.";
             }
             leaf-list flags {
               type path-attribute-flags;
               description
                 "Path attributes flags.";
               reference
                 "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
                  RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                  Tunnels
                  RFC 4561: Definition of a Record Route Object (RRO)
                  Node-Id Sub-Object";
             }
             description
               "Unnumbered link Record Route hop.";
             reference
               "RFC 3477: Signalling Unnumbered Links in Resource



Busi, et al.             Expires 25 August 2024                [Page 89]

Internet-Draft            TE Common YANG Types             February 2024


                ReSerVation Protocol - Traffic Engineering (RSVP-TE)";
           }
           description
             "Unnumbered link route hop.";
         }
         case label {
           container label-hop {
             description
               "Label route hop type.";
             uses te-label;
             leaf-list flags {
               type path-attribute-flags;
               description
                 "Path attributes flags.";
               reference
                 "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
                  RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                  Tunnels
                  RFC 4561: Definition of a Record Route Object (RRO)
                  Node-Id Sub-Object";
             }
           }
           description
             "The label Record Route entry types.";
         }
       }
     }

     grouping label-restriction-info {
       description
         "Label set item information.";
       leaf restriction {
         type enumeration {
           enum inclusive {
             description
               "The label or label range is inclusive.";
           }
           enum exclusive {
             description
               "The label or label range is exclusive.";
           }
         }
         default "inclusive";
         description
           "Indicates whether the list item is inclusive or exclusive.";
       }
       leaf index {
         type uint32;



Busi, et al.             Expires 25 August 2024                [Page 90]

Internet-Draft            TE Common YANG Types             February 2024


         description
           "The index of the label restriction list entry.";
       }
       container label-start {
         must "(not(../label-end/te-label/direction) and"
            + " not(te-label/direction))"
            + " or "
            + "(../label-end/te-label/direction = te-label/direction)"
            + " or "
            + "(not(te-label/direction) and"
            + " (../label-end/te-label/direction = 'forward'))"
            + " or "
            + "(not(../label-end/te-label/direction) and"
            + " (te-label/direction = 'forward'))" {
           error-message "'label-start' and 'label-end' must have the "
                       + "same direction.";
         }
         description
           "This is the starting label if a label range is specified.
            This is the label value if a single label is specified,
            in which case the 'label-end' attribute is not set.";
         uses te-label;
       }
       container label-end {
         must "(not(../label-start/te-label/direction) and"
            + " not(te-label/direction))"
            + " or "
            + "(../label-start/te-label/direction = te-label/direction)"
            + " or "
            + "(not(te-label/direction) and"
            + " (../label-start/te-label/direction = 'forward'))"
            + " or "
            + "(not(../label-start/te-label/direction) and"
            + " (te-label/direction = 'forward'))" {
           error-message "'label-start' and 'label-end' must have the "
                       + "same direction.";
         }
         description
           "This is the ending label if a label range is specified.
            This attribute is not set if a single label is specified.";
         uses te-label;
       }
       container label-step {
         description
           "The step increment between labels in the label range.
            The label start/end values will have to be consistent
            with the sign of label step.  For example,
            'label-start' < 'label-end' enforces 'label-step' > 0



Busi, et al.             Expires 25 August 2024                [Page 91]

Internet-Draft            TE Common YANG Types             February 2024


            'label-start' > 'label-end' enforces 'label-step' < 0.";
         choice technology {
           default "generic";
           description
             "Data-plane technology type.";
           case generic {
             leaf generic {
               type int32;
               default "1";
               description
                 "Label range step.";
             }
           }
         }
       }
       leaf range-bitmap {
         type yang:hex-string;
         description
           "When there are gaps between 'label-start' and 'label-end',
            this attribute is used to specify the positions
            of the used labels.  This is represented in big endian as
            'hex-string'.
            The most significant byte in the hex-string is the farthest
            to the left in the byte sequence.  Leading zero bytes in the
            configured value may be omitted for brevity.
            Each bit position in the 'range-bitmap' 'hex-string' maps
            to a label in the range derived from 'label-start'.

            For example, assuming that 'label-start' = 16000 and
            'range-bitmap' = 0x01000001, then:

            - bit position (0) is set, and the corresponding mapped
              label from the range is 16000 + (0 * 'label-step') or
              16000 for default 'label-step' = 1.
            - bit position (24) is set, and the corresponding mapped
              label from the range is 16000 + (24 * 'label-step') or
              16024 for default 'label-step' = 1.";
       }
     }

     grouping label-set-info {
       description
         "Grouping for the list of label restrictions specifying what
          labels may or may not be used.";
       container label-restrictions {
         description
           "The label restrictions container.";
         list label-restriction {



Busi, et al.             Expires 25 August 2024                [Page 92]

Internet-Draft            TE Common YANG Types             February 2024


           key "index";
           description
             "The absence of the label restrictions container implies
              that all labels are acceptable; otherwise, only restricted
              labels are available.";
           reference
             "RFC 7579: General Network Element Constraint Encoding
              for GMPLS-Controlled Networks";
           uses label-restriction-info;
         }
       }
     }

     // CHANGE NOTE: The grouping optimization-metric-entry below has
     // been updated in this module revision
     // RFC Editor: remove the note above and this note
     grouping optimization-metric-entry {
       description
         "Optimization metrics configuration grouping.";
       leaf metric-type {
         type identityref {
           base path-metric-optimization-type;
         }
         description
           "Identifies the 'metric-type' that the path computation
            process uses for optimization.";
       }
       leaf weight {
         type uint8;
         default "1";
         description
           "TE path metric normalization weight.";
       }
       container explicit-route-exclude-objects {
         when "../metric-type = "
            + "'te-types:path-metric-optimize-excludes'";
         description
           "Container for the 'exclude route' object list.";
         uses path-route-exclude-objects;
       }
       container explicit-route-include-objects {
         when "../metric-type = "
            + "'te-types:path-metric-optimize-includes'";
         description
           "Container for the 'include route' object list.";
         uses path-route-include-objects;
       }
     }



Busi, et al.             Expires 25 August 2024                [Page 93]

Internet-Draft            TE Common YANG Types             February 2024


     grouping common-constraints {
       description
         "Common constraints grouping that can be set on
          a constraint set or directly on the tunnel.";
       uses te-bandwidth {
         description
           "A requested bandwidth to use for path computation.";
       }
       leaf link-protection {
         type identityref {
           base link-protection-type;
         }
         default "te-types:link-protection-unprotected";
         description
           "Link protection type required for the links included
            in the computed path.";
         reference
           "RFC 4202: Routing Extensions in Support of
            Generalized Multi-Protocol Label Switching (GMPLS)";
       }
       leaf setup-priority {
         type uint8 {
           range "0..7";
         }
         default "7";
         description
           "TE LSP requested setup priority.";
         reference
           "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
       }
       leaf hold-priority {
         type uint8 {
           range "0..7";
         }
         default "7";
         description
           "TE LSP requested hold priority.";
         reference
           "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
       }
       leaf signaling-type {
         type identityref {
           base path-signaling-type;
         }
         default "te-types:path-setup-rsvp";
         description
           "TE tunnel path signaling type.";
       }



Busi, et al.             Expires 25 August 2024                [Page 94]

Internet-Draft            TE Common YANG Types             February 2024


     }

     // CHANGE NOTE: The grouping tunnel-constraints below has
     // been updated in this module revision
     // RFC Editor: remove the note above and this note
     grouping tunnel-constraints {
       description
         "Tunnel constraints grouping that can be set on
          a constraint set or directly on the tunnel.";
       leaf network-id {
         type nw:network-id;
         description
           "The network topology identifier.";
       }
       uses te-topology-identifier;
       uses common-constraints;
     }

     // CHANGE NOTE: The grouping path-constraints-route-objects below
     // has been updated in this module revision
     // RFC Editor: remove the note above and this note
     grouping path-constraints-route-objects {
       description
         "List of route entries to be included or excluded when
          performing the path computation.";
       container explicit-route-objects {
         description
           "Container for the explicit route object lists.";
         list route-object-exclude-always {
           key "index";
           ordered-by user;
           description
             "List of route objects to always exclude from the path
              computation.";
           leaf index {
             type uint32;
             description
               "Explicit Route Object index.  The index is used to
                identify an entry in the list.  The order of entries
                is defined by the user without relying on key values.";
           }
           uses explicit-route-hop;
         }
         list route-object-include-exclude {
           key "index";
           ordered-by user;
           description
             "List of route objects to include or exclude in the path



Busi, et al.             Expires 25 August 2024                [Page 95]

Internet-Draft            TE Common YANG Types             February 2024


              computation.";
           leaf explicit-route-usage {
             type identityref {
               base route-usage-type;
             }
             default "te-types:route-include-object";
             description
               "Indicates whether to include or exclude the
                route object.  The default is to include it.";
           }
           leaf index {
             type uint32;
             description
               "Route object include-exclude index.  The index is used
                to identify an entry in the list.  The order of entries
                is defined by the user without relying on key values.";
           }
           uses explicit-route-hop {
             augment "type" {
               case srlg {
                 container srlg {
                   description
                     "SRLG container.";
                   leaf srlg {
                     type uint32;
                     description
                       "SRLG value.";
                   }
                 }
                 description
                   "An SRLG value to be included or excluded.";
               }
               description
                 "Augmentation for a generic explicit route for SRLG
                  exclusion.";
             }
           }
         }
       }
     }

     grouping path-route-include-objects {
       description
         "List of route objects to be included when performing
          the path computation.";
       list route-object-include-object {
         key "index";
         ordered-by user;



Busi, et al.             Expires 25 August 2024                [Page 96]

Internet-Draft            TE Common YANG Types             February 2024


         description
           "List of Explicit Route Objects to be included in the
            path computation.";
         leaf index {
           type uint32;
           description
             "Route object entry index.  The index is used to
              identify an entry in the list.  The order of entries
              is defined by the user without relying on key values.";
         }
         uses explicit-route-hop;
       }
     }

     grouping path-route-exclude-objects {
       description
         "List of route objects to be excluded when performing
          the path computation.";
       list route-object-exclude-object {
         key "index";
         ordered-by user;
         description
           "List of Explicit Route Objects to be excluded in the
            path computation.";
         leaf index {
           type uint32;
           description
             "Route object entry index.  The index is used to
              identify an entry in the list.  The order of entries
              is defined by the user without relying on key values.";
         }
         uses explicit-route-hop {
           augment "type" {
             case srlg {
               container srlg {
                 description
                   "SRLG container.";
                 leaf srlg {
                   type uint32;
                   description
                     "SRLG value.";
                 }
               }
               description
                 "An SRLG value to be included or excluded.";
             }
             description
               "Augmentation for a generic explicit route for SRLG



Busi, et al.             Expires 25 August 2024                [Page 97]

Internet-Draft            TE Common YANG Types             February 2024


                exclusion.";
           }
         }
       }
     }

     // CHANGE NOTE: The grouping generic-path-metric-bounds below
     // has been updated in this module revision
     // RFC Editor: remove the note above and this note
     grouping generic-path-metric-bounds {
       description
         "TE path metric bounds grouping.";
       container path-metric-bounds {
         description
           "Top-level container for the list of path metric bounds.";
         list path-metric-bound {
           key "metric-type";
           description
             "List of path metric bounds, which can apply to link and
             path metrics.

             TE paths which have at least one path metric which
             exceeds the specified bounds MUST NOT be selected.

             TE paths that traverse TE links which have at least one
             link metric which exceeds the specified bounds MUST NOT
             be selected.";
           leaf metric-type {
             type identityref {
               base link-path-metric-type;
             }
             description
               "Identifies an entry in the list of 'metric-type' items
                bound for the TE path.";
           }
           leaf upper-bound {
             type uint64;
             default "0";
             description
               "Upper bound on the specified 'metric-type'.

               A zero indicates an unbounded upper limit for the
               specificied 'metric-type'.

               The unit of is interpreted in the context of the
               'metric-type' identity.";
           }
         }



Busi, et al.             Expires 25 August 2024                [Page 98]

Internet-Draft            TE Common YANG Types             February 2024


       }
     }

     // CHANGE NOTE: The grouping generic-path-metric-bounds below
     // has been updated in this module revision
     // RFC Editor: remove the note above and this note
     grouping generic-path-optimization {
       description
         "TE generic path optimization grouping.";
       container optimizations {
         description
           "The objective function container that includes
            attributes to impose when computing a TE path.";
         choice algorithm {
           description
             "Optimizations algorithm.";
           case metric {
             if-feature "path-optimization-metric";
             /* Optimize by metric */
             list optimization-metric {
               key "metric-type";
               description
                 "TE path metric type.";
               uses optimization-metric-entry;
             }
             /* Tiebreakers */
             container tiebreakers {
               status deprecated;
               description
                 "Container for the list of tiebreakers.

                 This container has been obsoleted by the tiebreaker
                 leaf.";
               list tiebreaker {
                 key "tiebreaker-type";
                 description
                   "The list of tiebreaker criteria to apply on an
                    equally favored set of paths, in order to pick
                    the best.";
                 leaf tiebreaker-type {
                   type identityref {
                     base path-metric-type;
                   }
                   description
                     "Identifies an entry in the list of tiebreakers.";
                 }
               }
             }



Busi, et al.             Expires 25 August 2024                [Page 99]

Internet-Draft            TE Common YANG Types             February 2024


           }
           case objective-function {
             if-feature "path-optimization-objective-function";
             /* Objective functions */
             container objective-function {
               description
                 "The objective function container that includes
                  attributes to impose when computing a TE path.";
               leaf objective-function-type {
                 type identityref {
                   base objective-function-type;
                 }
                 default "te-types:of-minimize-cost-path";
                 description
                   "Objective function entry.";
               }
             }
           }
         }
       }
       leaf tiebreaker {
         type identityref {
           base path-tiebreaker-type;
         }
         default "te-types:path-tiebreaker-random";
         description
           "The tiebreaker criteria to apply on an equally favored set
           of paths, in order to pick the best.";
       }
     }

     grouping generic-path-affinities {
       description
         "Path affinities grouping.";
       container path-affinities-values {
         description
           "Path affinities represented as values.";
         list path-affinities-value {
           key "usage";
           description
             "List of named affinity constraints.";
           leaf usage {
             type identityref {
               base resource-affinities-type;
             }
             description
               "Identifies an entry in the list of value affinity
                constraints.";



Busi, et al.             Expires 25 August 2024               [Page 100]

Internet-Draft            TE Common YANG Types             February 2024


           }
           leaf value {
             type admin-groups;
             default "";
             description
               "The affinity value.  The default is empty.";
           }
         }
       }
       container path-affinity-names {
         description
           "Path affinities represented as names.";
         list path-affinity-name {
           key "usage";
           description
             "List of named affinity constraints.";
           leaf usage {
             type identityref {
               base resource-affinities-type;
             }
             description
               "Identifies an entry in the list of named affinity
                constraints.";
           }
           list affinity-name {
             key "name";
             leaf name {
               type string;
               description
                 "Identifies a named affinity entry.";
             }
             description
               "List of named affinities.";
           }
         }
       }
     }

     grouping generic-path-srlgs {
       description
         "Path SRLG grouping.";
       container path-srlgs-lists {
         description
           "Path SRLG properties container.";
         list path-srlgs-list {
           key "usage";
           description
             "List of SRLG values to be included or excluded.";



Busi, et al.             Expires 25 August 2024               [Page 101]

Internet-Draft            TE Common YANG Types             February 2024


           leaf usage {
             type identityref {
               base route-usage-type;
             }
             description
               "Identifies an entry in a list of SRLGs to either
                include or exclude.";
           }
           leaf-list values {
             type srlg;
             description
               "List of SRLG values.";
           }
         }
       }
       container path-srlgs-names {
         description
           "Container for the list of named SRLGs.";
         list path-srlgs-name {
           key "usage";
           description
             "List of named SRLGs to be included or excluded.";
           leaf usage {
             type identityref {
               base route-usage-type;
             }
             description
               "Identifies an entry in a list of named SRLGs to either
                include or exclude.";
           }
           leaf-list names {
             type string;
             description
               "List of named SRLGs.";
           }
         }
       }
     }

     grouping generic-path-disjointness {
       description
         "Path disjointness grouping.";
       leaf disjointness {
         type te-path-disjointness;
         description
           "The type of resource disjointness.
            When configured for a primary path, the disjointness level
            applies to all secondary LSPs.  When configured for a



Busi, et al.             Expires 25 August 2024               [Page 102]

Internet-Draft            TE Common YANG Types             February 2024


            secondary path, the disjointness level overrides the level
            configured for the primary path.";
       }
     }

     grouping common-path-constraints-attributes {
       description
         "Common path constraints configuration grouping.";
       uses common-constraints;
       uses generic-path-metric-bounds;
       uses generic-path-affinities;
       uses generic-path-srlgs;
     }

     grouping generic-path-constraints {
       description
         "Global named path constraints configuration grouping.";
       container path-constraints {
         description
           "TE named path constraints container.";
         uses common-path-constraints-attributes;
         uses generic-path-disjointness;
       }
     }

     grouping generic-path-properties {
       description
         "TE generic path properties grouping.";
       container path-properties {
         config false;
         description
           "The TE path properties.";
         list path-metric {
           key "metric-type";
           description
             "TE path metric type.";
           leaf metric-type {
             type identityref {
               base path-metric-type;
             }
             description
               "TE path metric type.";
           }
           leaf accumulative-value {
             type uint64;
             description
               "TE path metric accumulative value.";
           }



Busi, et al.             Expires 25 August 2024               [Page 103]

Internet-Draft            TE Common YANG Types             February 2024


         }
         uses generic-path-affinities;
         uses generic-path-srlgs;
         container path-route-objects {
           description
             "Container for the list of route objects either returned by
              the computation engine or actually used by an LSP.";
           list path-route-object {
             key "index";
             ordered-by user;
             description
               "List of route objects either returned by the computation
                engine or actually used by an LSP.";
             leaf index {
               type uint32;
               description
                 "Route object entry index.  The index is used to
                  identify an entry in the list.  The order of entries
                  is defined by the user without relying on key
                  values.";
             }
             uses explicit-route-hop;
           }
         }
       }
     }

     // NOTE: The grouping encoding-and-switching-type below has been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     grouping encoding-and-switching-type {
       description
         "Common grouping to define the LSP encoding and
         switching types";
       leaf encoding {
         type identityref {
           base te-types:lsp-encoding-types;
         }
         description
           "LSP encoding type.";
         reference
           "RFC 3945";
       }
       leaf switching-type {
         type identityref {
           base te-types:switching-capabilities;
         }
         description



Busi, et al.             Expires 25 August 2024               [Page 104]

Internet-Draft            TE Common YANG Types             February 2024


           "LSP switching type.";
         reference
           "RFC 3945";
       }
     }

     // CHANGE NOTE: The typedef te-gen-node-id below has been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     grouping te-generic-node-id {
       description
         "A reusable grouping for a TE generic node identifier.";
       leaf id {
         type te-gen-node-id;
         description
           "The identifier of the node. Can be represented as IP
            address or dotted quad address or as an URI.";
       }
       leaf type {
         type enumeration {
           enum ip {
             description
               "IP address representation of the node identifier.";
           }
           enum te-id {
             description
               "TE identifier of the node";
           }
           enum node-id {
             description
               "URI representation of the node identifier.";
           }
         }
         description
           "Type of node identifier representation.";
       }
     }
   }
   <CODE ENDS>

                       Figure 1: TE Types YANG module

5.  Packet TE Types YANG Module

   The "ietf-te-packet-types" module imports from the "ietf-te-types"
   module defined in Section 4 of this document.





Busi, et al.             Expires 25 August 2024               [Page 105]

Internet-Draft            TE Common YANG Types             February 2024


   CHANGE NOTE: Please focus your review only on the updates to the YANG
   model: see also Appendix A.1.

   RFC Editor: remove the CHANGE NOTE above and this note

   <CODE BEGINS> file "ietf-te-packet-types@2024-01-25.yang"
   module ietf-te-packet-types {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-te-packet-types";
     prefix te-packet-types;

     /* Import TE generic types */

     import ietf-te-types {
       prefix te-types;
       reference
         "RFCXXXX: Common YANG Data Types for Traffic Engineering";
     }
     // RFC Editor: replace XXXX with actual RFC number
     // and remove this note

     organization
       "IETF Traffic Engineering Architecture and Signaling (TEAS)
        Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/teas/>
        WG List:  <mailto:teas@ietf.org>

        Editor:   Tarek Saad
                  <mailto:tsaad.net@gmail.com>

        Editor:   Rakesh Gandhi
                  <mailto:rgandhi@cisco.com>

        Editor:   Vishnu Pavan Beeram
                  <mailto:vbeeram@juniper.net>

        Editor:   Xufeng Liu
                  <mailto:xufeng.liu.ietf@gmail.com>

        Editor:   Igor Bryskin
                  <mailto:i_bryskin@yahoo.com>";
     description
       "This YANG module contains a collection of generally useful YANG
        data type definitions specific to Packet Traffic Enginnering
        (TE).

        The model fully conforms to the Network Management Datastore



Busi, et al.             Expires 25 August 2024               [Page 106]

Internet-Draft            TE Common YANG Types             February 2024


        Architecture (NMDA).

        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
        'MAY', and 'OPTIONAL' in this document are to be interpreted as
        described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
        they appear in all capitals, as shown here.

        Copyright (c) 2024 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Revised BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC XXXX
        (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
        for full legal notices.";
     revision 2024-02-16 {
       description
         "This revision adds the following new identities:
          - bandwidth-profile-type;
          - link-metric-delay-variation;
          - link-metric-loss;
          - path-metric-delay-variation;
          - path-metric-loss.

         This revision adds the following new groupings:
          - te-packet-path-bandwidth;
          - te-packet-link-bandwidth.

         This revision provides also few editorial changes.";
       reference
         "RFC XXXX: Common YANG Data Types for Traffic Engineering";
     }
     // RFC Editor: replace XXXX with actual RFC number, update date
     // information and remove this note

     revision 2020-06-10 {
       description
         "Latest revision of TE MPLS types.";
       reference
         "RFC 8776: Common YANG Data Types for Traffic Engineering";
     }




Busi, et al.             Expires 25 August 2024               [Page 107]

Internet-Draft            TE Common YANG Types             February 2024


     /*
      * Identities
      */

     // CHANGE NOTE: The base identity bandwidth-profile-type and
     // its derived identities below have been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     identity bandwidth-profile-type {
       description
         "Bandwidth Profile Types";
     }

       identity mef-10-bwp {
         base bandwidth-profile-type;
         description
           "MEF 10 Bandwidth Profile";
         reference
           "MEF 10.3: Ethernet Services Attributes Phase 3";
       }

       identity rfc-2697-bwp {
         base bandwidth-profile-type;
         description
           "RFC 2697 Bandwidth Profile";
         reference
           "RFC2697: A Single Rate Three Color Marker";
       }

       identity rfc-2698-bwp {
         base bandwidth-profile-type;
         description
           "RFC 2698 Bandwidth Profile";
         reference
           "RFC2698: A Two Rate Three Color Marker";
       }

       identity rfc-4115-bwp {
         base bandwidth-profile-type;
         description
           "RFC 4115 Bandwidth Profile";
         reference
           "RFC4115: A Differentiated Service Two-Rate, Three-Color
           Marker with Efficient Handling of in-Profile Traffic";
       }

       // CHANGE NOTE: The identity link-metric-delay-variation
       // below has been added in this module revision



Busi, et al.             Expires 25 August 2024               [Page 108]

Internet-Draft            TE Common YANG Types             February 2024


       // RFC Editor: remove the note above and this note
       identity link-metric-delay-variation {
         base te-types:link-metric-type;
         description
           "The Unidirectional Delay Variation Metric,
           measured in units of microseconds.";
         reference
           "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions,
           section 4.3

           RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions,
           section 4.3";
       }

       // CHANGE NOTE: The identity link-metric-loss below has
       // been added in this module revision
       // RFC Editor: remove the note above and this note
       identity link-metric-loss {
         base te-types:link-metric-type;
         description
           "The Unidirectional Link Loss Metric,
           measured in units of 0.000003%.";
         reference
           "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions,
           section 4.4

           RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions,
           section 4.4";
       }

       // CHANGE NOTE: The identity path-metric-delay-variation
       // below has been added in this module revision
       // RFC Editor: remove the note above and this note
       identity path-metric-delay-variation {
         base te-types:path-metric-type;
         description
           "The Path Delay Variation Metric,
           measured in units of microseconds.";
         reference
           "RFC8233: Extensions to the Path Computation Element
           Communication Protocol (PCEP) to Compute Service-Aware Label
           Switched Paths (LSPs), section 3.1.2";
       }

       // CHANGE NOTE: The identity path-metric-loss below has
       // been added in this module revision
       // RFC Editor: remove the note above and this note
       identity path-metric-loss {



Busi, et al.             Expires 25 August 2024               [Page 109]

Internet-Draft            TE Common YANG Types             February 2024


         base te-types:path-metric-type;
         description
           "The Path Loss Metric, measured in units of 0.000003%.";
         reference
           "RFC8233: Extensions to the Path Computation Element
           Communication Protocol (PCEP) to Compute Service-Aware Label
           Switched Paths (LSPs), section 3.1.3";
       }

     /*
      * Typedefs
      */

     typedef te-bandwidth-requested-type {
       type enumeration {
         enum specified {
           description
             "Bandwidth is explicitly specified.";
         }
         enum auto {
           description
             "Bandwidth is automatically computed.";
         }
       }
       description
         "Enumerated type for specifying whether bandwidth is
          explicitly specified or automatically computed.";
     }

     typedef te-class-type {
       type uint8;
       description
         "Diffserv-TE Class-Type.  Defines a set of Traffic Trunks
          crossing a link that is governed by a specific set of
          bandwidth constraints.  Class-Type is used for the purposes
          of link bandwidth allocation, constraint-based routing, and
          admission control.";
       reference
         "RFC 4124: Protocol Extensions for Support of Diffserv-aware
          MPLS Traffic Engineering";
     }

     typedef bc-type {
       type uint8 {
         range "0..7";
       }
       description
         "Diffserv-TE bandwidth constraints as defined in RFC 4124.";



Busi, et al.             Expires 25 August 2024               [Page 110]

Internet-Draft            TE Common YANG Types             February 2024


       reference
         "RFC 4124: Protocol Extensions for Support of Diffserv-aware
          MPLS Traffic Engineering";
     }

     typedef bandwidth-kbps {
       type uint64;
       units "Kbps";
       description
         "Bandwidth values, expressed in kilobits per second.";
     }

     typedef bandwidth-mbps {
       type uint64;
       units "Mbps";
       description
         "Bandwidth values, expressed in megabits per second.";
     }

     typedef bandwidth-gbps {
       type uint64;
       units "Gbps";
       description
         "Bandwidth values, expressed in gigabits per second.";
     }

     identity backup-protection-type {
       description
         "Base identity for the backup protection type.";
     }

     identity backup-protection-link {
       base backup-protection-type;
       description
         "Backup provides link protection only.";
     }

     identity backup-protection-node-link {
       base backup-protection-type;
       description
         "Backup offers node (preferred) or link protection.";
     }

     identity bc-model-type {
       description
         "Base identity for the Diffserv-TE Bandwidth Constraints
          Model type.";
       reference



Busi, et al.             Expires 25 August 2024               [Page 111]

Internet-Draft            TE Common YANG Types             February 2024


         "RFC 4124: Protocol Extensions for Support of Diffserv-aware
          MPLS Traffic Engineering";
     }

     identity bc-model-rdm {
       base bc-model-type;
       description
         "Russian Dolls Bandwidth Constraints Model type.";
       reference
         "RFC 4127: Russian Dolls Bandwidth Constraints Model for
                    Diffserv-aware MPLS Traffic Engineering";
     }

     identity bc-model-mam {
       base bc-model-type;
       description
         "Maximum Allocation Bandwidth Constraints Model type.";
       reference
         "RFC 4125: Maximum Allocation Bandwidth Constraints Model for
                    Diffserv-aware MPLS Traffic Engineering";
     }

     identity bc-model-mar {
       base bc-model-type;
       description
         "Maximum Allocation with Reservation Bandwidth Constraints
          Model type.";
       reference
         "RFC 4126: Max Allocation with Reservation Bandwidth
          Constraints Model for Diffserv-aware MPLS Traffic Engineering
          & Performance Comparisons";
     }

     /*
      * Groupings
      */

     grouping performance-metrics-attributes-packet {
       description
         "Contains PM attributes.";
       uses te-types:performance-metrics-attributes {
         augment "performance-metrics-one-way" {
           leaf one-way-min-delay {
             type uint32 {
               range "0..16777215";
             }
             description
               "One-way minimum delay or latency in microseconds.";



Busi, et al.             Expires 25 August 2024               [Page 112]

Internet-Draft            TE Common YANG Types             February 2024


           }
           leaf one-way-min-delay-normality {
             type te-types:performance-metrics-normality;
             default "normal";
             description
               "One-way minimum delay or latency normality.";
           }
           leaf one-way-max-delay {
             type uint32 {
               range "0..16777215";
             }
             description
               "One-way maximum delay or latency in microseconds.";
           }
           leaf one-way-max-delay-normality {
             type te-types:performance-metrics-normality;
             default "normal";
             description
               "One-way maximum delay or latency normality.";
           }
           leaf one-way-delay-variation {
             type uint32 {
               range "0..16777215";
             }
             description
               "One-way delay variation in microseconds.";
             reference
               "RFC 5481: Packet Delay Variation Applicability
                Statement, Section 4.2";
           }
           leaf one-way-delay-variation-normality {
             type te-types:performance-metrics-normality;
             default "normal";
             description
               "One-way delay variation normality.";
             reference
               "RFC 7471: OSPF Traffic Engineering (TE) Metric
                Extensions
                RFC 7823: Performance-Based Path Selection for
                Explicitly Routed Label Switched Paths (LSPs) Using
                TE Metric Extensions
                RFC 8570: IS-IS Traffic Engineering (TE) Metric
                Extensions";
           }
           leaf one-way-packet-loss {
             type decimal64 {
               fraction-digits 6;
               range "0..50.331642";



Busi, et al.             Expires 25 August 2024               [Page 113]

Internet-Draft            TE Common YANG Types             February 2024


             }
             description
               "One-way packet loss as a percentage of the total traffic
                sent over a configurable interval.  The finest precision
                is 0.000003%, where the maximum is 50.331642%.";
             reference
               "RFC 8570: IS-IS Traffic Engineering (TE) Metric
                Extensions, Section 4.4";
           }
           leaf one-way-packet-loss-normality {
             type te-types:performance-metrics-normality;
             default "normal";
             description
               "Packet loss normality.";
             reference
               "RFC 7471: OSPF Traffic Engineering (TE) Metric
                Extensions
                RFC 7823: Performance-Based Path Selection for
                Explicitly Routed Label Switched Paths (LSPs) Using
                TE Metric Extensions
                RFC 8570: IS-IS Traffic Engineering (TE) Metric
                Extensions";
           }
           description
             "PM one-way packet-specific augmentation for a generic PM
              grouping.";
         }
         augment "performance-metrics-two-way" {
           leaf two-way-min-delay {
             type uint32 {
               range "0..16777215";
             }
             default "0";
             description
               "Two-way minimum delay or latency in microseconds.";
           }
           leaf two-way-min-delay-normality {
             type te-types:performance-metrics-normality;
             default "normal";
             description
               "Two-way minimum delay or latency normality.";
             reference
               "RFC 7471: OSPF Traffic Engineering (TE) Metric
                Extensions
                RFC 7823: Performance-Based Path Selection for
                Explicitly Routed Label Switched Paths (LSPs) Using
                TE Metric Extensions
                RFC 8570: IS-IS Traffic Engineering (TE) Metric



Busi, et al.             Expires 25 August 2024               [Page 114]

Internet-Draft            TE Common YANG Types             February 2024


                Extensions";
           }
           leaf two-way-max-delay {
             type uint32 {
               range "0..16777215";
             }
             default "0";
             description
               "Two-way maximum delay or latency in microseconds.";
           }
           leaf two-way-max-delay-normality {
             type te-types:performance-metrics-normality;
             default "normal";
             description
               "Two-way maximum delay or latency normality.";
             reference
               "RFC 7471: OSPF Traffic Engineering (TE) Metric
                Extensions
                RFC 7823: Performance-Based Path Selection for
                Explicitly Routed Label Switched Paths (LSPs) Using
                TE Metric Extensions
                RFC 8570: IS-IS Traffic Engineering (TE) Metric
                Extensions";
           }
           leaf two-way-delay-variation {
             type uint32 {
               range "0..16777215";
             }
             default "0";
             description
               "Two-way delay variation in microseconds.";
             reference
               "RFC 5481: Packet Delay Variation Applicability
                Statement, Section 4.2";
           }
           leaf two-way-delay-variation-normality {
             type te-types:performance-metrics-normality;
             default "normal";
             description
               "Two-way delay variation normality.";
             reference
               "RFC 7471: OSPF Traffic Engineering (TE) Metric
                Extensions
                RFC 7823: Performance-Based Path Selection for
                Explicitly Routed Label Switched Paths (LSPs) Using
                TE Metric Extensions
                RFC 8570: IS-IS Traffic Engineering (TE) Metric
                Extensions";



Busi, et al.             Expires 25 August 2024               [Page 115]

Internet-Draft            TE Common YANG Types             February 2024


           }
           leaf two-way-packet-loss {
             type decimal64 {
               fraction-digits 6;
               range "0..50.331642";
             }
             default "0";
             description
               "Two-way packet loss as a percentage of the total traffic
                sent over a configurable interval.  The finest precision
                is 0.000003%.";
           }
           leaf two-way-packet-loss-normality {
             type te-types:performance-metrics-normality;
             default "normal";
             description
               "Two-way packet loss normality.";
           }
           description
             "PM two-way packet-specific augmentation for a generic PM
              grouping.";
           reference
             "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
              RFC 7823: Performance-Based Path Selection for
              Explicitly Routed Label Switched Paths (LSPs) Using
              TE Metric Extensions
              RFC 8570: IS-IS Traffic Engineering (TE) Metric
              Extensions";
         }
       }
     }

     grouping one-way-performance-metrics-packet {
       description
         "One-way packet PM throttle grouping.";
       leaf one-way-min-delay {
         type uint32 {
           range "0..16777215";
         }
         default "0";
         description
           "One-way minimum delay or latency in microseconds.";
       }
       leaf one-way-max-delay {
         type uint32 {
           range "0..16777215";
         }
         default "0";



Busi, et al.             Expires 25 August 2024               [Page 116]

Internet-Draft            TE Common YANG Types             February 2024


         description
           "One-way maximum delay or latency in microseconds.";
       }
       leaf one-way-delay-variation {
         type uint32 {
           range "0..16777215";
         }
         default "0";
         description
           "One-way delay variation in microseconds.";
       }
       leaf one-way-packet-loss {
         type decimal64 {
           fraction-digits 6;
           range "0..50.331642";
         }
         default "0";
         description
           "One-way packet loss as a percentage of the total traffic
            sent over a configurable interval.  The finest precision is
            0.000003%.";
       }
     }

     grouping two-way-performance-metrics-packet {
       description
         "Two-way packet PM throttle grouping.";
       leaf two-way-min-delay {
         type uint32 {
           range "0..16777215";
         }
         default "0";
         description
           "Two-way minimum delay or latency in microseconds.";
       }
       leaf two-way-max-delay {
         type uint32 {
           range "0..16777215";
         }
         default "0";
         description
           "Two-way maximum delay or latency in microseconds.";
       }
       leaf two-way-delay-variation {
         type uint32 {
           range "0..16777215";
         }
         default "0";



Busi, et al.             Expires 25 August 2024               [Page 117]

Internet-Draft            TE Common YANG Types             February 2024


         description
           "Two-way delay variation in microseconds.";
       }
       leaf two-way-packet-loss {
         type decimal64 {
           fraction-digits 6;
           range "0..50.331642";
         }
         default "0";
         description
           "Two-way packet loss as a percentage of the total traffic
            sent over a configurable interval.  The finest precision is
            0.000003%.";
       }
     }

     grouping performance-metrics-throttle-container-packet {
       description
         "Packet PM threshold grouping.";
       uses te-types:performance-metrics-throttle-container {
         augment "throttle/threshold-out" {
           uses one-way-performance-metrics-packet;
           uses two-way-performance-metrics-packet;
           description
             "PM threshold-out packet augmentation for a
              generic grouping.";
         }
         augment "throttle/threshold-in" {
           uses one-way-performance-metrics-packet;
           uses two-way-performance-metrics-packet;
           description
             "PM threshold-in packet augmentation for a
              generic grouping.";
         }
         augment "throttle/threshold-accelerated-advertisement" {
           uses one-way-performance-metrics-packet;
           uses two-way-performance-metrics-packet;
           description
             "PM accelerated advertisement packet augmentation for a
              generic grouping.";
         }
       }
     }

     // CHANGE NOTE: The te-packet-path-bandwidth below has been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     grouping te-packet-path-bandwidth {



Busi, et al.             Expires 25 August 2024               [Page 118]

Internet-Draft            TE Common YANG Types             February 2024


       description
         "Path bandwidth for Packet. ";
       leaf bandwidth-profile-name {
         type string;
         description "Name of Bandwidth Profile.";
       }
       leaf bandwidth-profile-type {
         type identityref {
           base bandwidth-profile-type;
         }
         description "Type of Bandwidth Profile.";
       }
       leaf cir {
         type uint64;
         units "bits/second";
         mandatory true;
         description
           "Committed Information Rate (CIR).";
       }
       leaf cbs {
         type uint64;
         units "bits/second";
         mandatory true;
         description
           "Committed Burst Size (CBS).";
       }
       leaf eir {
         type uint64;
         units "bits/second";
         description
           "Excess Information Rate (EIR).";
       }
       leaf ebs {
         type uint64;
         units "bytes";
         description
           "Excess Burst Size (EBS).";
       }
       leaf pir {
         type uint64;
         units "bits/second";
         description
           "Peak Information Rate (PIR).";
       }
       leaf pbs {
         type uint64;
         units "bytes";
         description



Busi, et al.             Expires 25 August 2024               [Page 119]

Internet-Draft            TE Common YANG Types             February 2024


           "Peak Burst Size (PBS).";
       }
     }

     // CHANGE NOTE: The te-packet-path-bandwidth below has been
     // added in this module revision
     // RFC Editor: remove the note above and this note
     grouping te-packet-link-bandwidth {
       description
         "Link Bandwidth for Packet. ";
       leaf packet-bandwidth {
         type uint64;
         units "bits/second";
         description
           "Available bandwith value.";
       }
     }
   }
   <CODE ENDS>

                   Figure 2: Packet TE Types YANG module

6.  IANA Considerations

   For the following URIs in the "IETF XML Registry" [RFC3688], IANA has
   updated the reference field to refer to this document:

         URI: urn:ietf:params:xml:ns:yang:ietf-te-types
         Registrant Contact:  The IESG.
         XML: N/A, the requested URI is an XML namespace.

         URI: urn:ietf:params:xml:ns:yang:ietf-te-packet-types
         Registrant Contact:  The IESG.
         XML: N/A, the requested URI is an XML namespace.

   This document also adds updated YANG modules to the "YANG Module
   Names" registry [RFC7950]:

         name:      ietf-te-types
         namespace: urn:ietf:params:xml:ns:yang:ietf-te-types
         prefix:    te-types
         reference: RFC XXXX

         name:      ietf-te-packet-types
         namespace: urn:ietf:params:xml:ns:yang:ietf-te-packet-types
         prefix:    te-packet-types
         reference: RFC XXXX




Busi, et al.             Expires 25 August 2024               [Page 120]

Internet-Draft            TE Common YANG Types             February 2024


   RFC Editor: Please replace XXXX with the RFC number assigned to this
   document.

7.  Security Considerations

   The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

   The YANG module in this document defines common TE type definitions
   (e.g., typedef, identity, and grouping statements) in YANG data
   modeling language to be imported and used by other TE modules.  When
   imported and used, the resultant schema will have data nodes that can
   be writable or readable.  Access to such data nodes may be considered
   sensitive or vulnerable in some network environments.  Write
   operations (e.g., edit-config) to these data nodes without proper
   protection can have a negative effect on network operations.

   The security considerations spelled out in the YANG 1.1 specification
   [RFC7950] apply for this document as well.

8.  References

8.1.  Normative References

   [ITU_G.808.1]
              ITU-T Recommendation G.808.1, "Generic protection
              switching - Linear trail and subnetwork protection", ITU-T
              G.808.1 , May 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.



Busi, et al.             Expires 25 August 2024               [Page 121]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", RFC 5441,
              DOI 10.17487/RFC5441, April 2009,
              <https://www.rfc-editor.org/info/rfc5441>.

   [RFC5520]  Bradford, R., Ed., Vasseur, JP., and A. Farrel,
              "Preserving Topology Confidentiality in Inter-Domain Path
              Computation Using a Path-Key-Based Mechanism", RFC 5520,
              DOI 10.17487/RFC5520, April 2009,
              <https://www.rfc-editor.org/info/rfc5520>.

   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in the Path Computation Element
              Communication Protocol (PCEP)", RFC 5541,
              DOI 10.17487/RFC5541, June 2009,
              <https://www.rfc-editor.org/info/rfc5541>.

   [RFC5557]  Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
              Computation Element Communication Protocol (PCEP)
              Requirements and Protocol Extensions in Support of Global
              Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557,
              July 2009, <https://www.rfc-editor.org/info/rfc5557>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.





Busi, et al.             Expires 25 August 2024               [Page 122]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8294]  Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
              "Common YANG Data Types for the Routing Area", RFC 8294,
              DOI 10.17487/RFC8294, December 2017,
              <https://www.rfc-editor.org/info/rfc8294>.

   [RFC8306]  Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
              "Extensions to the Path Computation Element Communication
              Protocol (PCEP) for Point-to-Multipoint Traffic
              Engineering Label Switched Paths", RFC 8306,
              DOI 10.17487/RFC8306, November 2017,
              <https://www.rfc-editor.org/info/rfc8306>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
              Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
              Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
              2018, <https://www.rfc-editor.org/info/rfc8345>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8685]  Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
              and D. King, "Path Computation Element Communication
              Protocol (PCEP) Extensions for the Hierarchical Path
              Computation Element (H-PCE) Architecture", RFC 8685,
              DOI 10.17487/RFC8685, December 2019,
              <https://www.rfc-editor.org/info/rfc8685>.

   [RFC8776]  Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
              "Common YANG Data Types for Traffic Engineering",
              RFC 8776, DOI 10.17487/RFC8776, June 2020,
              <https://www.rfc-editor.org/info/rfc8776>.






Busi, et al.             Expires 25 August 2024               [Page 123]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC8800]  Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
              "Path Computation Element Communication Protocol (PCEP)
              Extension for Label Switched Path (LSP) Diversity
              Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,
              July 2020, <https://www.rfc-editor.org/info/rfc8800>.

   [RFC9012]  Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
              "The BGP Tunnel Encapsulation Attribute", RFC 9012,
              DOI 10.17487/RFC9012, April 2021,
              <https://www.rfc-editor.org/info/rfc9012>.

8.2.  Informative References

   [I-D.ietf-teas-yang-te-mpls]
              Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
              Bryskin, "A YANG Data Model for MPLS Traffic Engineering
              Tunnels", Work in Progress, Internet-Draft, draft-ietf-
              teas-yang-te-mpls-04, 26 May 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              yang-te-mpls-04>.

   [ITU-T_G.709]
              International Telecommunication Union, "Interfaces for the
              optical transport network", ITU-T G.709 , June 2020.

   [MEF_10.3] MEF, "Ethernet Services Attributes Phase 3", MEF 10.3 ,
              October 2013.

   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
              Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
              <https://www.rfc-editor.org/info/rfc2697>.

   [RFC2698]  Heinanen, J. and R. Guerin, "A Two Rate Three Color
              Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
              <https://www.rfc-editor.org/info/rfc2698>.

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, DOI 10.17487/RFC2702, September 1999,
              <https://www.rfc-editor.org/info/rfc2702>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.






Busi, et al.             Expires 25 August 2024               [Page 124]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Functional Description",
              RFC 3471, DOI 10.17487/RFC3471, January 2003,
              <https://www.rfc-editor.org/info/rfc3471>.

   [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
              in Resource ReSerVation Protocol - Traffic Engineering
              (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
              <https://www.rfc-editor.org/info/rfc3477>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC3785]  Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and
              T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric
              as a second MPLS Traffic Engineering (TE) Metric", BCP 87,
              RFC 3785, DOI 10.17487/RFC3785, May 2004,
              <https://www.rfc-editor.org/info/rfc3785>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <https://www.rfc-editor.org/info/rfc4090>.

   [RFC4115]  Aboul-Magd, O. and S. Rabie, "A Differentiated Service
              Two-Rate, Three-Color Marker with Efficient Handling of
              in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July
              2005, <https://www.rfc-editor.org/info/rfc4115>.

   [RFC4124]  Le Faucheur, F., Ed., "Protocol Extensions for Support of
              Diffserv-aware MPLS Traffic Engineering", RFC 4124,
              DOI 10.17487/RFC4124, June 2005,
              <https://www.rfc-editor.org/info/rfc4124>.

   [RFC4125]  Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
              Constraints Model for Diffserv-aware MPLS Traffic
              Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005,
              <https://www.rfc-editor.org/info/rfc4125>.







Busi, et al.             Expires 25 August 2024               [Page 125]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC4126]  Ash, J., "Max Allocation with Reservation Bandwidth
              Constraints Model for Diffserv-aware MPLS Traffic
              Engineering & Performance Comparisons", RFC 4126,
              DOI 10.17487/RFC4126, June 2005,
              <https://www.rfc-editor.org/info/rfc4126>.

   [RFC4127]  Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints
              Model for Diffserv-aware MPLS Traffic Engineering",
              RFC 4127, DOI 10.17487/RFC4127, June 2005,
              <https://www.rfc-editor.org/info/rfc4127>.

   [RFC4202]  Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
              in Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
              <https://www.rfc-editor.org/info/rfc4202>.

   [RFC4203]  Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
              Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
              <https://www.rfc-editor.org/info/rfc4203>.

   [RFC4328]  Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Extensions for G.709 Optical
              Transport Networks Control", RFC 4328,
              DOI 10.17487/RFC4328, January 2006,
              <https://www.rfc-editor.org/info/rfc4328>.

   [RFC4427]  Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
              (Protection and Restoration) Terminology for Generalized
              Multi-Protocol Label Switching (GMPLS)", RFC 4427,
              DOI 10.17487/RFC4427, March 2006,
              <https://www.rfc-editor.org/info/rfc4427>.

   [RFC4561]  Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan,
              "Definition of a Record Route Object (RRO) Node-Id Sub-
              Object", RFC 4561, DOI 10.17487/RFC4561, June 2006,
              <https://www.rfc-editor.org/info/rfc4561>.

   [RFC4657]  Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol Generic
              Requirements", RFC 4657, DOI 10.17487/RFC4657, September
              2006, <https://www.rfc-editor.org/info/rfc4657>.

   [RFC4736]  Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
              "Reoptimization of Multiprotocol Label Switching (MPLS)
              Traffic Engineering (TE) Loosely Routed Label Switched
              Path (LSP)", RFC 4736, DOI 10.17487/RFC4736, November
              2006, <https://www.rfc-editor.org/info/rfc4736>.



Busi, et al.             Expires 25 August 2024               [Page 126]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC4872]  Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
              Ed., "RSVP-TE Extensions in Support of End-to-End
              Generalized Multi-Protocol Label Switching (GMPLS)
              Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
              <https://www.rfc-editor.org/info/rfc4872>.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
              May 2007, <https://www.rfc-editor.org/info/rfc4873>.

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007,
              <https://www.rfc-editor.org/info/rfc4875>.

   [RFC4920]  Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N.,
              and G. Ash, "Crankback Signaling Extensions for MPLS and
              GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007,
              <https://www.rfc-editor.org/info/rfc4920>.

   [RFC5003]  Metz, C., Martini, L., Balus, F., and J. Sugimoto,
              "Attachment Individual Identifier (AII) Types for
              Aggregation", RFC 5003, DOI 10.17487/RFC5003, September
              2007, <https://www.rfc-editor.org/info/rfc5003>.

   [RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
              "Label Switched Path Stitching with Generalized
              Multiprotocol Label Switching Traffic Engineering (GMPLS
              TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
              <https://www.rfc-editor.org/info/rfc5150>.

   [RFC5151]  Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
              Domain MPLS and GMPLS Traffic Engineering -- Resource
              Reservation Protocol-Traffic Engineering (RSVP-TE)
              Extensions", RFC 5151, DOI 10.17487/RFC5151, February
              2008, <https://www.rfc-editor.org/info/rfc5151>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5307]  Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
              in Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
              <https://www.rfc-editor.org/info/rfc5307>.




Busi, et al.             Expires 25 August 2024               [Page 127]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC5420]  Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangar, "Encoding of Attributes for MPLS LSP
              Establishment Using Resource Reservation Protocol Traffic
              Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
              February 2009, <https://www.rfc-editor.org/info/rfc5420>.

   [RFC5712]  Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic
              Engineering Soft Preemption", RFC 5712,
              DOI 10.17487/RFC5712, January 2010,
              <https://www.rfc-editor.org/info/rfc5712>.

   [RFC6001]  Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
              D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
              Extensions for Multi-Layer and Multi-Region Networks (MLN/
              MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010,
              <https://www.rfc-editor.org/info/rfc6001>.

   [RFC6004]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support
              for Metro Ethernet Forum and G.8011 Ethernet Service
              Switching", RFC 6004, DOI 10.17487/RFC6004, October 2010,
              <https://www.rfc-editor.org/info/rfc6004>.

   [RFC6119]  Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
              Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
              February 2011, <https://www.rfc-editor.org/info/rfc6119>.

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370,
              DOI 10.17487/RFC6370, September 2011,
              <https://www.rfc-editor.org/info/rfc6370>.

   [RFC6378]  Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
              N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
              TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
              October 2011, <https://www.rfc-editor.org/info/rfc6378>.

   [RFC6511]  Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
              Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
              Label Switched Paths", RFC 6511, DOI 10.17487/RFC6511,
              February 2012, <https://www.rfc-editor.org/info/rfc6511>.

   [RFC6780]  Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
              ASSOCIATION Object Extensions", RFC 6780,
              DOI 10.17487/RFC6780, October 2012,
              <https://www.rfc-editor.org/info/rfc6780>.






Busi, et al.             Expires 25 August 2024               [Page 128]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

   [RFC6827]  Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou,
              Ed., "Automatically Switched Optical Network (ASON)
              Routing for OSPFv2 Protocols", RFC 6827,
              DOI 10.17487/RFC6827, January 2013,
              <https://www.rfc-editor.org/info/rfc6827>.

   [RFC7139]  Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
              and K. Pithewan, "GMPLS Signaling Extensions for Control
              of Evolving G.709 Optical Transport Networks", RFC 7139,
              DOI 10.17487/RFC7139, March 2014,
              <https://www.rfc-editor.org/info/rfc7139>.

   [RFC7260]  Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
              Extensions for Operations, Administration, and Maintenance
              (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June
              2014, <https://www.rfc-editor.org/info/rfc7260>.

   [RFC7308]  Osborne, E., "Extended Administrative Groups in MPLS
              Traffic Engineering (MPLS-TE)", RFC 7308,
              DOI 10.17487/RFC7308, July 2014,
              <https://www.rfc-editor.org/info/rfc7308>.

   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <https://www.rfc-editor.org/info/rfc7471>.

   [RFC7551]  Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
              Extensions for Associated Bidirectional Label Switched
              Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
              <https://www.rfc-editor.org/info/rfc7551>.

   [RFC7570]  Margaria, C., Ed., Martinelli, G., Balls, S., and B.
              Wright, "Label Switched Path (LSP) Attribute in the
              Explicit Route Object (ERO)", RFC 7570,
              DOI 10.17487/RFC7570, July 2015,
              <https://www.rfc-editor.org/info/rfc7570>.

   [RFC7571]  Dong, J., Chen, M., Li, Z., and D. Ceccarelli, "GMPLS
              RSVP-TE Extensions for Lock Instruct and Loopback",
              RFC 7571, DOI 10.17487/RFC7571, July 2015,
              <https://www.rfc-editor.org/info/rfc7571>.




Busi, et al.             Expires 25 August 2024               [Page 129]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC7579]  Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and
              J. Han, "General Network Element Constraint Encoding for
              GMPLS-Controlled Networks", RFC 7579,
              DOI 10.17487/RFC7579, June 2015,
              <https://www.rfc-editor.org/info/rfc7579>.

   [RFC7823]  Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
              "Performance-Based Path Selection for Explicitly Routed
              Label Switched Paths (LSPs) Using TE Metric Extensions",
              RFC 7823, DOI 10.17487/RFC7823, May 2016,
              <https://www.rfc-editor.org/info/rfc7823>.

   [RFC8001]  Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C.,
              Hartley, M., and Z. Ali, "RSVP-TE Extensions for
              Collecting Shared Risk Link Group (SRLG) Information",
              RFC 8001, DOI 10.17487/RFC8001, January 2017,
              <https://www.rfc-editor.org/info/rfc8001>.

   [RFC8149]  Saad, T., Ed., Gandhi, R., Ed., Ali, Z., Venator, R., and
              Y. Kamite, "RSVP Extensions for Reoptimization of Loosely
              Routed Point-to-Multipoint Traffic Engineering Label
              Switched Paths (LSPs)", RFC 8149, DOI 10.17487/RFC8149,
              April 2017, <https://www.rfc-editor.org/info/rfc8149>.

   [RFC8169]  Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
              and A. Vainshtein, "Residence Time Measurement in MPLS
              Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017,
              <https://www.rfc-editor.org/info/rfc8169>.

   [RFC8233]  Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
              "Extensions to the Path Computation Element Communication
              Protocol (PCEP) to Compute Service-Aware Label Switched
              Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
              2017, <https://www.rfc-editor.org/info/rfc8233>.

   [RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
              D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
              2019, <https://www.rfc-editor.org/info/rfc8570>.

   [RFC9314]  Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed.,
              Pallagatti, S., and G. Mirsky, "YANG Data Model for
              Bidirectional Forwarding Detection (BFD)", RFC 9314,
              DOI 10.17487/RFC9314, September 2022,
              <https://www.rfc-editor.org/info/rfc9314>.






Busi, et al.             Expires 25 August 2024               [Page 130]

Internet-Draft            TE Common YANG Types             February 2024


   [RFC9522]  Farrel, A., Ed., "Overview and Principles of Internet
              Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
              January 2024, <https://www.rfc-editor.org/info/rfc9522>.

Appendix A.  Changes from RFC 8776

   This version adds new common data types, identities, and groupings to
   the YANG modules.  It also updates some of the existing data types,
   identities, and groupings in the YANG modules and fixes few bugs in
   [RFC8776].

   The following new identities have been added to the 'ietf-te-types'
   module:

   *  lsp-provisioning-error-reason;

   *  association-type-diversity;

   *  tunnel-admin-state-auto;

   *  lsp-restoration-restore-none;

   *  restoration-scheme-rerouting;

   *  path-metric-optimization-type;

   *  link-path-metric-type;

   *  link-metric-type and its derived identities;

   *  path-computation-error-reason and its derived identities;

   *  protocol-origin-type and its derived identities;

   *  svec-objective-function-type and its derived identities;

   *  svec-metric-type and its derived identities.

   The following new data types have been added to the 'ietf-te-types'
   module:

   *  path-type;

   *  te-gen-node-id.

   The following new groupings have been added to the 'ietf-te-types'
   module:




Busi, et al.             Expires 25 August 2024               [Page 131]

Internet-Draft            TE Common YANG Types             February 2024


   *  encoding-and-switching-type;

   *  te-generic-node-id.

   The following new identities have been added to the 'ietf-te-packet-
   types' module:

   *  bandwidth-profile-type;

   *  link-metric-delay-variation;

   *  link-metric-loss;

   *  path-metric-delay-variation;

   *  path-metric-loss.

   The following new groupings have been added to the 'ietf-te-packet-
   types' module:

   *  te-packet-path-bandwidth;

   *  te-packet-link-bandwidth.

   The following identities, already defined in [RFC8776], have been
   updated in the 'ietf-te-types' module:

   *  objective-function-type (editorial);

   *  action-exercise (bug fix);

   *  path-metric-type:

      new base identities have been added;

   *  path-metric-te (bug fix);

   *  path-metric-igp (bug fix);

   *  path-metric-hop (bug fix);

   *  path-metric-delay-average (bug fix);

   *  path-metric-delay-minimum (bug fix);

   *  path-metric-residual-bandwidth (bug fix);

   *  path-metric-optimize-includes (bug fix);



Busi, et al.             Expires 25 August 2024               [Page 132]

Internet-Draft            TE Common YANG Types             February 2024


   *  path-metric-optimize-excludes (bug fix);

   *  te-optimization-criterion (editorial).

   The following data type, already defined in [RFC8776], has been
   updated in the 'ietf-te-types' module:

   *  te-node-id;

      The data type has been changed to be a union.

   The following groupings, already defined in [RFC8776], have been
   updated in the 'ietf-te-types' module:

   *  explicit-route-hop

      The following new leaves have been added to the 'explicit-route-
      hop' grouping:

      -  node-id-uri;

      -  link-tp-id-uri;

      The following leaves, already defined in [RFC8776], have been
      updated in the 'explicit-route-hop':

      -  node-id;

      -  link-tp-id.

         The mandatory true statements for the node-id and link-tp-id
         have been replaced by must statements that requires at least
         the presence of:

         o  node-id or node-id-uri;

         o  link-tp-id or link-tp-id-uri.

   *  explicit-route-hop

      The following new leaves have been added to the 'explicit-route-
      hop' grouping:

      -  node-id-uri;

      -  link-tp-id-uri;





Busi, et al.             Expires 25 August 2024               [Page 133]

Internet-Draft            TE Common YANG Types             February 2024


      The following leaves, already defined in [RFC8776], have been
      updated in the 'explicit-route-hop':

      -  node-id;

      -  link-tp-id.

         The mandatory true statements for the node-id and link-tp-id
         have been replaced by must statements that requires at least
         the presence of:

         o  node-id or node-id-uri;

         o  link-tp-id or link-tp-id-uri.

   *  optimization-metric-entry:

      The following leaves, already defined in [RFC8776], have been
      updated in the 'optimization-metric-entry':

      -  metric-type;

         The base identity has been updated without impacting the set of
         derived identities that are allowed.

   *  tunnel-constraints;

      The following new leaf have been added to the 'tunnel-constraints'
      grouping:

      -  network-id;

   *  path-constraints-route-objects:

      The following container, already defined in [RFC8776], has been
      updated in the 'path-constraints-route-objects':

      -  explicit-route-objects-always;

         The container has been renamed as 'explicit-route-objects'.
         This change is not affecting any IETF standard YANG models
         since this grouping has not yet been used by any YANG model
         defined in existing IETF RFCs.

   *  generic-path-metric-bounds:

      The following leaves, already defined in [RFC8776], have been
      updated in the 'optimization-metric-entry':



Busi, et al.             Expires 25 August 2024               [Page 134]

Internet-Draft            TE Common YANG Types             February 2024


      -  metric-type;

         The base identity has been updated to:

         o  increase the set of derived identities that are allowed and;

         o  remove from this set the 'path-metric-optimize-includes' and
            the 'path-metric-optimize-excludes' identities (bug fixing)

   *  generic-path-optimization

      The following new leaf have been added to the 'generic-path-
      optimization' grouping:

      -  tiebreaker;

      The following container, already defined in [RFC8776], has been
      deprecated:

      -  tiebreakers.

   The following identities, already defined in [RFC8776], have been
   obsoletes in the 'ietf-te-types' module for bug fixing:

   *  of-minimize-agg-bandwidth-consumption;

   *  of-minimize-load-most-loaded-link;

   *  of-minimize-cost-path-set;

   *  lsp-protection-reroute-extra;

   *  lsp-protection-reroute.

A.1.  TE Types YANG Diffs

   RFC Editor: please remove this appendix before publication.

   This section provides the diff between the YANG module in section 3.1
   of [RFC8776] and the YANG model revision in Section 4.

   The intention of this appendix is to facilitate focusing the review
   of the YANG model in Section 4 to the changes compared with the YANG
   model in [RFC8776].

   This diff has been generated using the following UNIX commands to
   compare the YANG module revisions in section 3.1 of [RFC8776] and in
   Section 4:



Busi, et al.             Expires 25 August 2024               [Page 135]

Internet-Draft            TE Common YANG Types             February 2024


   diff ietf-te-types@2020-06-10.yang ietf-te-types.yang
        > model-diff.txt
   sed 's/^/    /' model-diff.txt > model-diff-spaces.txt
   sed 's/^    >   /    >   /' model-diff-spaces.txt
       > model-updates.txt

   The output (model-updates.txt) is reported here:

 21a22,31
 >   import ietf-network {
 >     prefix "nw";
 >     reference "RFC 8345: A YANG Data Model for Network Topologies";
 >   }
 >
 >   import ietf-network-topology {
 >     prefix "nt";
 >     reference "RFC 8345: A YANG Data Model for Network Topologies";
 >   }
 >
 30c40
 <                <mailto:tsaad@juniper.net>
 ---
 >                <mailto:tsaad.net@gmail.com>
 55c65
 <      Copyright (c) 2020 IETF Trust and the persons identified as
 ---
 >      Copyright (c) 2024 IETF Trust and the persons identified as
 60c70
 <      the license terms contained in, the Simplified BSD License set
 ---
 >      the license terms contained in, the Revised BSD License set
 65,66c75,164
 <      This version of this YANG module is part of RFC 8776; see the
 <      RFC itself for full legal notices.";
 ---
 >      This version of this YANG module is part of RFC XXXX
 >      (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
 >      for full legal notices.";
 >   revision 2024-02-22 {
 >     description
 >       "This revision adds the following new identities:
 >       - lsp-provisioning-error-reason;
 >       - association-type-diversity;
 >       - tunnel-admin-state-auto;
 >       - lsp-restoration-restore-none;
 >       - restoration-scheme-rerouting;
 >       - path-metric-optimization-type;
 >       - link-path-metric-type;



Busi, et al.             Expires 25 August 2024               [Page 136]

Internet-Draft            TE Common YANG Types             February 2024


 >       - link-metric-type and its derived identities;
 >       - path-computation-error-reason and its derived identities;
 >       - protocol-origin-type and its derived identities;
 >       - svec-objective-function-type and its derived identities;
 >       - svec-metric-type and its derived identities.
 >
 >       This revision adds the following new data types:
 >       - path-type;
 >       - te-gen-node-id.
 >
 >       This revision adds the following new groupings:
 >       - encoding-and-switching-type;
 >       - te-generic-node-id.
 >
 >       This revision updates the following identities:
 >       - objective-function-type;
 >       - action-exercise;
 >       - path-metric-type;
 >       - path-metric-te;
 >       - path-metric-igp;
 >       - path-metric-hop;
 >       - path-metric-delay-average;
 >       - path-metric-delay-minimum;
 >       - path-metric-residual-bandwidth;
 >       - path-metric-optimize-includes;
 >       - path-metric-optimize-excludes;
 >       - te-optimization-criterion.
 >
 >       This revision updates the following data types:
 >       - te-node-id.
 >
 >       This revision updates the following groupings:
 >       - explicit-route-hop:
 >         - adds the following leaves:
 >           - node-id-uri;
 >           - link-tp-id-uri;
 >         - updates the following leaves:
 >           - node-id;
 >           - link-tp-id;
 >       - record-route-state:
 >         - adds the following leaves:
 >           - node-id-uri;
 >           - link-tp-id-uri;
 >         - updates the following leaves:
 >           - node-id;
 >           - link-tp-id;
 >       - optimization-metric-entry:
 >         - updates the following leaves:



Busi, et al.             Expires 25 August 2024               [Page 137]

Internet-Draft            TE Common YANG Types             February 2024


 >           - metric-type;
 >       - tunnel-constraints;
 >         - adds the following leaves:
 >           - network-id;
 >       - path-constraints-route-objects:
 >         - updates the following containers:
 >           - explicit-route-objects-always;
 >       - generic-path-metric-bounds:
 >         - updates the following leaves:
 >           - metric-type;
 >       - generic-path-optimization
 >         - adds the following leaves:
 >           - tiebreaker;
 >         - deprecate the following containers:
 >           - tiebreakers.
 >
 >       This revision obsoletes the following identities:
 >       - of-minimize-agg-bandwidth-consumption;
 >       - of-minimize-load-most-loaded-link;
 >       - of-minimize-cost-path-set;
 >       - lsp-protection-reroute-extra;
 >       - lsp-protection-reroute.
 >
 >       This revision provides also few editorial changes.";
 >     reference
 >       "RFC XXXX: Common YANG Data Types for Traffic Engineering";
 >   }
 >   // RFC Editor: replace XXXX with actual RFC number, update date
 >   // information and remove this note
 70c168
 <       "Latest revision of TE types.";
 ---
 >       "Initial Version of TE types.";
 86a185
 >
 92a192
 >
 93a194
 >
 111a213
 >
 155a258
 >
 158a262
 >
 263a368
 >
 264a370



Busi, et al.             Expires 25 August 2024               [Page 138]

Internet-Draft            TE Common YANG Types             February 2024


 >
 269a376
 >
 351a459,461
 >   // CHANGE NOTE: The typedef te-node-id below has been
 >   // updated in this module revision
 >   // RFC Editor: remove the note above and this note
 353c463,466
 <     type yang:dotted-quad;
 ---
 >     type union {
 >       type yang:dotted-quad;
 >       type inet:ipv6-address-no-zone;
 >     }
 357,358c470,474
 <        The identifier is represented as 4 octets in dotted-quad
 <        notation.
 ---
 >
 >        The identifier is represented either as 4 octets in
 >        dotted-quad notation or 16 octets in full, mixed, shortened,
 >        or shortened-mixed IPv6 address notation.
 >
 362,363c478,481
 <        Router ID TLV described in Section 4.3 of RFC 5305, or the
 <        TE Router ID TLV described in Section 3.2.1 of RFC 6119.
 ---
 >        Router ID TLV described in Section 4.3 of RFC 5305, the TE
 >        Router ID TLV described in Section 3.2.1 of RFC 6119, or the
 >        IPv6 TE Router ID TLV described in Section 4.1 of RFC 6119.
 >
 368a487
 >
 370a490
 >
 371a492
 >
 519a641
 >
 537a660
 >
 545a669,709
 >   // CHANGE NOTE: The typedef path-type below has been
 >   // added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   typedef path-type {
 >     type enumeration {
 >       enum primary-path {



Busi, et al.             Expires 25 August 2024               [Page 139]

Internet-Draft            TE Common YANG Types             February 2024


 >         description
 >           "Indicates that the TE path is a primary path.";
 >       }
 >       enum secondary-path {
 >         description
 >           "Indicates that the TE path is a secondary path.";
 >       }
 >       enum primary-reverse-path {
 >         description
 >           "Indicates that the TE path is a primary reverse path.";
 >       }
 >       enum secondary-reverse-path {
 >         description
 >           "Indicates that the TE path is a secondary reverse path.";
 >       }
 >     }
 >     description
 >       "The type of TE path, indicating whether a path is a primary,
 >       or a reverse primary, or a secondary, or a reverse secondary
 >       path.";
 >   }
 >
 >   // CHANGE NOTE: The typedef te-gen-node-id below has been
 >   // added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   typedef te-gen-node-id {
 >     type union {
 >       type te-node-id;
 >       type inet:ip-address;
 >       type nw:node-id;
 >     }
 >     description
 >       "Generic type that identifies a node in a TE topology.";
 >   }
 >
 606a771,778
 >   // CHANGE NOTE: The base identity lsp-provisioning-error-reason
 >   // has been added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   identity lsp-provisioning-error-reason {
 >     description
 >       "Base identity for LSP provisioning errors.";
 >   }
 >
 982a1155,1172
 >   // CHANGE NOTE: The identity association-type-diversity below has
 >   // been added in this module revision
 >   // RFC Editor: remove the note above and this note



Busi, et al.             Expires 25 August 2024               [Page 140]

Internet-Draft            TE Common YANG Types             February 2024


 >   identity association-type-diversity {
 >     base association-type;
 >     description
 >       "Association Type diversity used to associate LSPs whose
 >       paths are to be diverse from each other.";
 >     reference
 >       "RFC 8800: Path Computation Element Communication Protocol
 >       (PCEP) Extension for Label Switched Path (LSP) Diversity
 >       Constraint Signaling";
 >   }
 >
 >   // CHANGE NOTE: The description of the base identity
 >   // objective-function-type has been updated
 >   // in this module revision
 >   // RFC Editor: remove the note above and this note
 985c1175
 <       "Base objective function type.";
 ---
 >       "Base identity for path objective function types.";
 1015a1206,1208
 >   // CHANGE NOTE: The identity of-minimize-agg-bandwidth-consumption
 >   // below has been obsoleted in this module revision
 >   // RFC Editor: remove the note above and this note
 1017a1211
 >     status obsolete;
 1020c1214,1218
 <        consumption.";
 ---
 >       consumption.
 >
 >       This identity has been obsoleted: the
 >       'svec-of-minimize-agg-bandwidth-consumption' identity SHOULD
 >       be used instead.";
 1023c1221
 <        Computation Element Communication Protocol (PCEP)";
 ---
 >       Computation Element Communication Protocol (PCEP)";
 1025a1224,1226
 >   // CHANGE NOTE: The identity of-minimize-load-most-loaded-link
 >   // below has been obsoleted in this module revision
 >   // RFC Editor: remove the note above and this note
 1027a1229
 >     status obsolete;
 1030c1232,1236
 <        is carrying the highest load.";
 ---
 >       is carrying the highest load.
 >



Busi, et al.             Expires 25 August 2024               [Page 141]

Internet-Draft            TE Common YANG Types             February 2024


 >       This identity has been obsoleted: the
 >       'svec-of-minimize-load-most-loaded-link' identity SHOULD
 >       be used instead.";
 1033c1239
 <        Computation Element Communication Protocol (PCEP)";
 ---
 >       Computation Element Communication Protocol (PCEP)";
 1035a1242,1244
 >   // CHANGE NOTE: The identity of-minimize-cost-path-set
 >   // below has been obsoleted in this module revision
 >   // RFC Editor: remove the note above and this note
 1037a1247
 >     status obsolete;
 1039c1249,1253
 <       "Objective function for minimizing the cost on a path set.";
 ---
 >       "Objective function for minimizing the cost on a path set.
 >
 >       This identity has been obsoleted: the
 >       'svec-of-minimize-cost-path-set' identity SHOULD
 >       be used instead.";
 1049a1264,1266
 >   // CHANGE NOTE: The reference of the identity path-locally-computed
 >   // below has been updated in this module revision
 >   // RFC Editor: remove the note above and this note
 1056,1057c1273,1274
 <       "RFC 3272: Overview and Principles of Internet Traffic
 <        Engineering, Section 5.4";
 ---
 >       "RFC 9522: Overview and Principles of Internet Traffic
 >       Engineering, Section 4.4";
 1059a1277,1280
 >   // CHANGE NOTE: The reference of the identity
 >   // path-externally-queried below has been updated
 >   // in this module revision
 >   // RFC Editor: remove the note above and this note
 1071c1292
 <       "RFC 3272: Overview and Principles of Internet Traffic
 ---
 >       "RFC 9522: Overview and Principles of Internet Traffic
 1072a1294
 >
 1076a1299,1302
 >   // CHANGE NOTE: The reference of the identity
 >   // path-explicitly-defined below has been updated
 >   // in this module revision
 >   // RFC Editor: remove the note above and this note
 1085c1311,1312



Busi, et al.             Expires 25 August 2024               [Page 142]

Internet-Draft            TE Common YANG Types             February 2024


 <        RFC 3272: Overview and Principles of Internet Traffic
 ---
 >
 >        RFC 9522: Overview and Principles of Internet Traffic
 1216a1444,1455
 >   // CHANGE NOTE: The identity tunnel-admin-state-auto below
 >   // has been added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   identity tunnel-admin-state-auto {
 >     base tunnel-admin-state-type;
 >     description
 >       "Tunnel administrative auto state. The administrative status
 >       in state datastore transitions to 'tunnel-admin-up' when the
 >       tunnel used by the client layer, and to 'tunnel-admin-down'
 >       when it is not used by the client layer.";
 >   }
 >
 1321a1561,1569
 >     // CHANGE NOTE: The identity lsp-restoration-restore-none
 >     // below has been added in this module revision
 >     // RFC Editor: remove the note above and this note
 >     identity lsp-restoration-restore-none {
 >       base lsp-restoration-type;
 >       description
 >         "No LSP affected by a failure is restored.";
 >     }
 >
 1339a1588,1602
 >     // CHANGE NOTE: The identity restoration-scheme-rerouting
 >     // below has been added in this module revision
 >     // RFC Editor: remove the note above and this note
 >     identity restoration-scheme-rerouting {
 >       base restoration-scheme-type;
 >       description
 >         "Restoration LSP is computed after the failure detection.
 >
 >         This restoration scheme is also known as
 >         'Full LSP Re-routing.'";
 >       reference
 >         "RFC 4427: Recovery (Protection and Restoration) Terminology
 >         for Generalized Multi-Protocol Label Switching (GMPLS)";
 >     }
 >
 1383a1647,1649
 >   // CHANGE NOTE: The identity lsp-protection-reroute-extra
 >   // below has been obsoleted in this module revision
 >   // RFC Editor: remove the note above and this note
 1385a1652



Busi, et al.             Expires 25 August 2024               [Page 143]

Internet-Draft            TE Common YANG Types             February 2024


 >     status obsolete;
 1387c1654,1658
 <       "'(Full) Rerouting' LSP protection type.";
 ---
 >       "'(Full) Rerouting' LSP protection type.
 >
 >       This identity has been obsoleted: the
 >       'restoration-scheme-rerouting' identity SHOULD be used
 >       instead.";
 1392a1664,1666
 >   // CHANGE NOTE: The identity lsp-protection-reroute
 >   // below has been obsoleted in this module revision
 >   // RFC Editor: remove the note above and this note
 1394a1669
 >     status obsolete;
 1396c1671,1675
 <       "'Rerouting without Extra-Traffic' LSP protection type.";
 ---
 >       "'Rerouting without Extra-Traffic' LSP protection type.
 >
 >       This identity has been obsoleted: the
 >       'restoration-scheme-rerouting' identity SHOULD be used
 >       instead.";
 1628a1908,1911
 >   // CHANGE NOTE: The description and reference of the
 >   // identity action-exercise have been updated in this module
 >   // revision
 >   // RFC Editor: remove the note above and this note
 1632,1633c1915,1917
 <       "An action that starts testing whether or not APS communication
 <        is operating correctly.  It is of lower priority than any
 ---
 >       "An action that starts testing whether or not Automatic
 >        Protection Switching (APS) communication is operating
 >        correctly.  It is of lower priority than any
 1636,1637c1920,1921
 <       "RFC 4427: Recovery (Protection and Restoration) Terminology
 <        for Generalized Multi-Protocol Label Switching (GMPLS)";
 ---
 >       "ITU-T G.808.1 v4.0 (05/2014): Generic protection switching -
 >       Linear trail and subnetwork protection";
 1917c2201,2204
 <   identity path-metric-type {
 ---
 >   // CHANGE NOTE: The path-metric-optimization-type base identity
 >   // has been added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   identity path-metric-optimization-type {



Busi, et al.             Expires 25 August 2024               [Page 144]

Internet-Draft            TE Common YANG Types             February 2024


 1919c2206,2207
 <       "Base identity for the path metric type.";
 ---
 >       "Base identity used to define the path metric optimization
 >       types.";
 1922,1923c2210,2213
 <   identity path-metric-te {
 <     base path-metric-type;
 ---
 >   // CHANGE NOTE: The link-path-metric-type base identity
 >   // has been added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   identity link-path-metric-type {
 1925,1928c2215,2221
 <       "TE path metric.";
 <     reference
 <       "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a
 <        second MPLS Traffic Engineering (TE) Metric";
 ---
 >       "Base identity used to define the link and the path metric
 >       types.
 >
 >       The unit of the path metric value is interpreted in the
 >       context of the path metric type and the derived identities
 >       SHOULD describe the unit of the path metric types they
 >       define.";
 1931,1938c2224,2232
 <   identity path-metric-igp {
 <     base path-metric-type;
 <     description
 <       "IGP path metric.";
 <     reference
 <       "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a
 <        second MPLS Traffic Engineering (TE) Metric";
 <   }
 ---
 >     // CHANGE NOTE: The link-metric-type base identity
 >     // and its derived identities
 >     // have been added in this module revision
 >     // RFC Editor: remove the note above and this note
 >     identity link-metric-type {
 >       base link-path-metric-type;
 >       description
 >         "Base identity for the link metric types.";
 >     }
 1940,1944c2234,2240
 <   identity path-metric-hop {
 <     base path-metric-type;



Busi, et al.             Expires 25 August 2024               [Page 145]

Internet-Draft            TE Common YANG Types             February 2024


 <     description
 <       "Hop path metric.";
 <   }
 ---
 >       identity link-metric-te {
 >         base link-metric-type;
 >         description
 >           "Traffic Engineering (TE) Link Metric.";
 >         reference
 >           "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
 >           Version 2, section 2.5.5
 1946,1952c2242,2244
 <   identity path-metric-delay-average {
 <     base path-metric-type;
 <     description
 <       "Average unidirectional link delay.";
 <     reference
 <       "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions";
 <   }
 ---
 >           RFC 5305: IS-IS Extensions for Traffic Engineering,
 >           section 3.7";
 >       }
 1954,1960c2246,2253
 <   identity path-metric-delay-minimum {
 <     base path-metric-type;
 <     description
 <       "Minimum unidirectional link delay.";
 <     reference
 <       "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions";
 <   }
 ---
 >       identity link-metric-igp {
 >         base link-metric-type;
 >         description
 >           "Interior Gateway Protocol (IGP) Link Metric.";
 >         reference
 >           "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric
 >           as a second MPLS Traffic Engineering (TE) Metric";
 >       }
 1962,1972c2255,2266
 <   identity path-metric-residual-bandwidth {
 <     base path-metric-type;
 <     description
 <       "Unidirectional Residual Bandwidth, which is defined to be
 <        Maximum Bandwidth (RFC 3630) minus the bandwidth currently
 <        allocated to LSPs.";
 <     reference



Busi, et al.             Expires 25 August 2024               [Page 146]

Internet-Draft            TE Common YANG Types             February 2024


 <       "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
 <        Version 2
 <        RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions";
 <   }
 ---
 >       identity link-metric-delay-average {
 >         base link-metric-type;
 >         description
 >           "Unidirectional Link Delay, measured in units of
 >           microseconds.";
 >         reference
 >           "RFC 7471: OSPF Traffic Engineering (TE) Metric
 >           Extensions, section 4.1
 >
 >           RFC 8570: IS-IS Traffic Engineering (TE) Metric
 >           Extensions, section 4.1";
 >       }
 1974,1979c2268,2279
 <   identity path-metric-optimize-includes {
 <     base path-metric-type;
 <     description
 <       "A metric that optimizes the number of included resources
 <        specified in a set.";
 <   }
 ---
 >       identity link-metric-delay-minimum {
 >         base link-metric-type;
 >         description
 >           "Minimum unidirectional Link Delay, measured in units of
 >           microseconds.";
 >         reference
 >           "RFC 7471: OSPF Traffic Engineering (TE) Metric
 >           Extensions, section 4.2
 >
 >           RFC 8570: IS-IS Traffic Engineering (TE) Metric
 >           Extensions, section 4.2";
 >       }
 1981,1986c2281,2425
 <   identity path-metric-optimize-excludes {
 <     base path-metric-type;
 <     description
 <       "A metric that optimizes to a maximum the number of excluded
 <        resources specified in a set.";
 <   }
 ---
 >       identity link-metric-delay-maximum {
 >         base link-metric-type;
 >         description



Busi, et al.             Expires 25 August 2024               [Page 147]

Internet-Draft            TE Common YANG Types             February 2024


 >           "Maximum unidirectional Link Delay, measured in units of
 >           microseconds.";
 >         reference
 >           "RFC 7471: OSPF Traffic Engineering (TE) Metric
 >           Extensions, section 4.2
 >
 >           RFC 8570: IS-IS Traffic Engineering (TE) Metric
 >           Extensions, section 4.2";
 >       }
 >
 >       identity link-metric-residual-bandwidth {
 >         base link-metric-type;
 >         description
 >           "Unidirectional Residual Bandwidth, measured in units of
 >           bytes per second.
 >
 >           It is defined to be Maximum Bandwidth minus the bandwidth
 >           currently allocated to LSPs.";
 >         reference
 >           "RFC 7471: OSPF Traffic Engineering (TE) Metric
 >           Extensions, section 4.5
 >
 >           RFC 8570: IS-IS Traffic Engineering (TE) Metric
 >           Extensions, section 4.5";
 >       }
 >
 >     // CHANGE NOTE: The base and the description of the
 >     // path-metric-type identity
 >     // has been updated in this module revision
 >     // RFC Editor: remove the note above and this note
 >     identity path-metric-type {
 >       base link-path-metric-type;
 >       base path-metric-optimization-type;
 >       description
 >         "Base identity for the path metric types.";
 >     }
 >
 >       // CHANGE NOTE: The description and the reference of the
 >       // path-metric-te identity have been updated
 >       // in this module revision
 >       // RFC Editor: remove the note above and this note
 >       identity path-metric-te {
 >         base path-metric-type;
 >         description
 >           "Traffic Engineering (TE) Path Metric.";
 >         reference
 >           "RFC 5440: Path Computation Element (PCE) Communication
 >           Protocol (PCEP), section 7.8";



Busi, et al.             Expires 25 August 2024               [Page 148]

Internet-Draft            TE Common YANG Types             February 2024


 >       }
 >
 >       // CHANGE NOTE: The description and the reference of the
 >       // path-metric-igp identity have been updated
 >       // in this module revision
 >       // RFC Editor: remove the note above and this note
 >       identity path-metric-igp {
 >         base path-metric-type;
 >         description
 >           "Interior Gateway Protocol (IGP) Path Metric.";
 >         reference
 >           "RFC 5440: Path Computation Element (PCE) Communication
 >           Protocol (PCEP), section 7.8";
 >       }
 >
 >       // CHANGE NOTE: The description and the reference of the
 >       // path-metric-hop identity have been updated
 >       // in this module revision
 >       // RFC Editor: remove the note above and this note
 >       identity path-metric-hop {
 >         base path-metric-type;
 >         description
 >           "Hop Count Path Metric.";
 >         reference
 >           "RFC 5440: Path Computation Element (PCE) Communication
 >           Protocol (PCEP), section 7.8";
 >       }
 >
 >       // CHANGE NOTE: The description and the reference of the
 >       // path-metric-delay-average identity have been updated
 >       // in this module revision
 >       // RFC Editor: remove the note above and this note
 >       identity path-metric-delay-average {
 >         base path-metric-type;
 >         description
 >           "The Path Delay Metric, measured in units of
 >           microseconds.";
 >         reference
 >           "RFC8233: Extensions to the Path Computation Element
 >           Communication Protocol (PCEP) to Compute Service-Aware
 >           Label Switched Paths (LSPs), section 3.1.1";
 >       }
 >
 >       // CHANGE NOTE: The description and the reference of the
 >       // path-metric-delay-minimum identity have been updated
 >       // in this module revision
 >       // RFC Editor: remove the note above and this note
 >       identity path-metric-delay-minimum {



Busi, et al.             Expires 25 August 2024               [Page 149]

Internet-Draft            TE Common YANG Types             February 2024


 >         base path-metric-type;
 >         description
 >           "The Path Min Delay Metric, measured in units of
 >           microseconds.";
 >         reference
 >           "I-D.ietf-pce-sid-algo: Carrying SR-Algorithm information
 >           in PCE-based Networks, section 3.5.1";
 >       }
 >
 >       // CHANGE NOTE: The description and the reference of the
 >       // path-metric-residual-bandwidth identity have been updated
 >       // in this module revision
 >       // RFC Editor: remove the note above and this note
 >       identity path-metric-residual-bandwidth {
 >         base path-metric-type;
 >         description
 >           "The Path Residual Bandwidth, defined as the minimum Link
 >           Residual Bandwidth all the links along the path.
 >
 >           The Path Residual Bandwidth can be seen as the path
 >           metric associated with the Maximum residual Bandwidth Path
 >           (MBP) objective function.";
 >         reference
 >           "RFC 5541: Encoding of Objective Functions in the Path
 >           Computation Element Communication Protocol (PCEP)";
 >       }
 >
 >     // CHANGE NOTE: The base of the path-metric-optimize-includes
 >     // identity has been updated in this module revision
 >     // RFC Editor: remove the note above and this note
 >     identity path-metric-optimize-includes {
 >       base path-metric-optimization-type;
 >       description
 >         "A metric that optimizes the number of included resources
 >         specified in a set.";
 >     }
 >
 >     // CHANGE NOTE: The base of the path-metric-optimize-excludes
 >     // identity has been updated in this module revision
 >     // RFC Editor: remove the note above and this note
 >     identity path-metric-optimize-excludes {
 >       base path-metric-optimization-type;
 >       description
 >         "A metric that optimizes to a maximum the number of excluded
 >         resources specified in a set.";
 >     }
 2049a2489,2492
 >   // CHANGE NOTE: The reference of the identity



Busi, et al.             Expires 25 August 2024               [Page 150]

Internet-Draft            TE Common YANG Types             February 2024


 >   // te-optimization-criterion below has been updated
 >   // in this module revision
 >   // RFC Editor: remove the note above and this note
 2054c2497
 <       "RFC 3272: Overview and Principles of Internet Traffic
 ---
 >       "RFC 9522: Overview and Principles of Internet Traffic
 2110a2554,2994
 >   // CHANGE NOTE: The base identity path-computation-error-reason
 >   // and its derived identities below have been
 >   // added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   identity path-computation-error-reason {
 >     description
 >       "Base identity for path computation error reasons.";
 >   }
 >
 >     identity path-computation-error-path-not-found {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because of an unspecified
 >         reason.";
 >       reference
 >         "RFC 5440: Path Computation Element (PCE) Communication
 >         Protocol (PCEP), section 7.5";
 >     }
 >
 >     identity path-computation-error-no-topology {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because there is no topology
 >         with the provided topology-identifier.";
 >     }
 >
 >     identity path-computation-error-no-dependent-server {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because one or more dependent
 >         path computation servers are unavailable.
 >
 >         The dependent path computation server could be
 >         a Backward-Recursive Path Computation (BRPC) downstream
 >         PCE or a child PCE.";
 >       reference
 >         "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC)
 >         Procedure to Compute Shortest Constrained Inter-Domain
 >         Traffic Engineering Label Switched Paths
 >



Busi, et al.             Expires 25 August 2024               [Page 151]

Internet-Draft            TE Common YANG Types             February 2024


 >         RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture";
 >     }
 >
 >     identity path-computation-error-pce-unavailable {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because PCE is not available.
 >
 >         It corresponds to bit 31 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 5440: Path Computation Element (PCE) Communication
 >         Protocol (PCEP)
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-no-inclusion-hop {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because there is no
 >         node or link provided by one or more inclusion hops.";
 >     }
 >
 >     identity path-computation-error-destination-unknown-in-domain {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because the destination node is
 >         unknown in indicated destination domain.
 >
 >         It corresponds to bit 19 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-no-resource {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because there is no



Busi, et al.             Expires 25 August 2024               [Page 152]

Internet-Draft            TE Common YANG Types             February 2024


 >         available resource in one or more domains.
 >
 >         It corresponds to bit 20 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-child-pce-unresponsive {
 >       base path-computation-error-no-dependent-server;
 >       description
 >         "Path computation has failed because child PCE is not
 >         responsive.
 >
 >         It corresponds to bit 21 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-destination-domain-unknown {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because the destination domain
 >         was unknown.
 >
 >         It corresponds to bit 22 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-p2mp {



Busi, et al.             Expires 25 August 2024               [Page 153]

Internet-Draft            TE Common YANG Types             February 2024


 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because of P2MP reachability
 >         problem.
 >
 >         It corresponds to bit 24 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 8306: Extensions to the Path Computation Element
 >         Communication Protocol (PCEP) for Point-to-Multipoint
 >         Traffic Engineering Label Switched Paths
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-no-gco-migration {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because of no Global Concurrent
 >         Optimization (GCO) migration path found.
 >
 >         It corresponds to bit 26 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 5557: Path Computation Element Communication Protocol
 >         (PCEP) Requirements and Protocol Extensions in Support of
 >         Global Concurrent Optimization
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-no-gco-solution {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because of no GCO solution
 >         found.
 >
 >         It corresponds to bit 25 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 5557: Path Computation Element Communication Protocol
 >         (PCEP) Requirements and Protocol Extensions in Support of
 >         Global Concurrent Optimization
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";



Busi, et al.             Expires 25 August 2024               [Page 154]

Internet-Draft            TE Common YANG Types             February 2024


 >     }
 >
 >     identity path-computation-error-pks-expansion {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because of Path-Key Subobject
 >         (PKS)  expansion failure.
 >
 >         It corresponds to bit 27 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 5520: Preserving Topology Confidentiality in
 >         Inter-Domain Path Computation Using a Path-Key-Based
 >         Mechanism
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-brpc-chain-unavailable {
 >       base path-computation-error-no-dependent-server;
 >       description
 >         "Path computation has failed because PCE BRPC chain
 >         unavailable.
 >
 >         It corresponds to bit 28 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC)
 >         Procedure to Compute Shortest Constrained Inter-Domain
 >         Traffic Engineering Label Switched Paths
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-source-unknown {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because source node is
 >         unknown.
 >
 >         It corresponds to bit 29 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 5440: Path Computation Element (PCE) Communication
 >         Protocol (PCEP);
 >



Busi, et al.             Expires 25 August 2024               [Page 155]

Internet-Draft            TE Common YANG Types             February 2024


 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-destination-unknown {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because destination node is
 >         unknown.
 >
 >         It corresponds to bit 30 of the Flags field of the
 >         NO-PATH-VECTOR TLV.";
 >       reference
 >         "RFC 5440: Path Computation Element (PCE) Communication
 >         Protocol (PCEP);
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >     identity path-computation-error-no-server {
 >       base path-computation-error-reason;
 >       description
 >         "Path computation has failed because path computation
 >         server is unavailable.";
 >       reference
 >         "RFC 5440: Path Computation Element (PCE) Communication
 >         Protocol (PCEP);
 >
 >         https://www.iana.org/assignments/pcep
 >         /pcep.xhtml#no-path-vector-tlv";
 >     }
 >
 >   // CHANGE NOTE: The base identity protocol-origin-type and
 >   // its derived identities below have been
 >   // added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   identity protocol-origin-type {
 >     description
 >       "Base identity for protocol origin type.";
 >   }
 >
 >     identity protocol-origin-api {
 >       base protocol-origin-type;
 >       description
 >         "Protocol origin is via Application Programmable Interface
 >         (API).";
 >     }



Busi, et al.             Expires 25 August 2024               [Page 156]

Internet-Draft            TE Common YANG Types             February 2024


 >
 >     identity protocol-origin-pcep {
 >       base protocol-origin-type;
 >       description
 >         "Protocol origin is Path Computation Engine Protocol
 >         (PCEP).";
 >       reference
 >         "RFC 5440: Path Computation Element (PCE) Communication
 >         Protocol (PCEP)";
 >     }
 >
 >     identity protocol-origin-bgp {
 >       base protocol-origin-type;
 >       description
 >         "Protocol origin is Border Gateway Protocol (BGP).";
 >       reference "RFC 9012";
 >     }
 >
 >   // CHANGE NOTE: The base identity svec-objective-function-type
 >   // and its derived identities below have been
 >   // added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   identity svec-objective-function-type {
 >     description
 >       "Base identity for SVEC objective function type.";
 >     reference
 >       "RFC 5541: Encoding of Objective Functions in the Path
 >        Computation Element Communication Protocol (PCEP)";
 >   }
 >
 >     identity svec-of-minimize-agg-bandwidth-consumption {
 >       base svec-objective-function-type;
 >       description
 >         "Objective function for minimizing aggregate bandwidth
 >         consumption (MBC).";
 >       reference
 >         "RFC 5541: Encoding of Objective Functions in the Path
 >         Computation Element Communication Protocol (PCEP)";
 >     }
 >
 >     identity svec-of-minimize-load-most-loaded-link {
 >       base svec-objective-function-type;
 >       description
 >         "Objective function for minimizing the load on the link that
 >         is carrying the highest load (MLL).";
 >       reference
 >         "RFC 5541: Encoding of Objective Functions in the Path
 >         Computation Element Communication Protocol (PCEP)";



Busi, et al.             Expires 25 August 2024               [Page 157]

Internet-Draft            TE Common YANG Types             February 2024


 >     }
 >
 >     identity svec-of-minimize-cost-path-set {
 >       base svec-objective-function-type;
 >       description
 >         "Objective function for minimizing the cost on a path set
 >         (MCC).";
 >       reference
 >         "RFC 5541: Encoding of Objective Functions in the Path
 >         Computation Element Communication Protocol (PCEP)";
 >     }
 >
 >     identity svec-of-minimize-common-transit-domain {
 >       base svec-objective-function-type;
 >       description
 >         "Objective function for minimizing the number of common
 >         transit domains (MCTD).";
 >       reference
 >         "RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture";
 >     }
 >
 >     identity svec-of-minimize-shared-link {
 >       base svec-objective-function-type;
 >       description
 >         "Objective function for minimizing the number of shared
 >         links (MSL).";
 >       reference
 >         "RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture.";
 >     }
 >
 >     identity svec-of-minimize-shared-srlg {
 >       base svec-objective-function-type;
 >       description
 >         "Objective function for minimizing the number of shared
 >         Shared Risk Link Groups (SRLG) (MSS).";
 >       reference
 >         "RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture.";
 >     }
 >
 >     identity svec-of-minimize-shared-nodes {
 >       base svec-objective-function-type;
 >       description



Busi, et al.             Expires 25 August 2024               [Page 158]

Internet-Draft            TE Common YANG Types             February 2024


 >         "Objective function for minimizing the number of shared
 >         nodes (MSN).";
 >       reference
 >         "RFC 8685: Path Computation Element Communication Protocol
 >         (PCEP) Extensions for the Hierarchical Path Computation
 >         Element (H-PCE) Architecture.";
 >     }
 >
 >   // CHANGE NOTE: The base identity svec-metric-type and
 >   // its derived identities below have been
 >   // added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   identity svec-metric-type {
 >     description
 >       "Base identity for SVEC metric type.";
 >     reference
 >       "RFC 5541: Encoding of Objective Functions in the Path
 >        Computation Element Communication Protocol (PCEP)";
 >   }
 >
 >     identity svec-metric-cumulative-te {
 >       base svec-metric-type;
 >       description
 >         "Cumulative TE cost.";
 >       reference
 >         "RFC 5541: Encoding of Objective Functions in the Path
 >         Computation Element Communication Protocol (PCEP)";
 >     }
 >
 >     identity svec-metric-cumulative-igp {
 >       base svec-metric-type;
 >       description
 >         "Cumulative IGP cost.";
 >       reference
 >         "RFC 5541: Encoding of Objective Functions in the Path
 >         Computation Element Communication Protocol (PCEP)";
 >     }
 >
 >     identity svec-metric-cumulative-hop {
 >       base svec-metric-type;
 >       description
 >         "Cumulative Hop path metric.";
 >       reference
 >         "RFC 5541: Encoding of Objective Functions in the Path
 >         Computation Element Communication Protocol (PCEP)";
 >     }
 >
 >     identity svec-metric-aggregate-bandwidth-consumption {



Busi, et al.             Expires 25 August 2024               [Page 159]

Internet-Draft            TE Common YANG Types             February 2024


 >       base svec-metric-type;
 >       description
 >         "Aggregate bandwidth consumption.";
 >       reference
 >         "RFC 5541: Encoding of Objective Functions in the Path
 >         Computation Element Communication Protocol (PCEP)";
 >     }
 >
 >     identity svec-metric-load-of-the-most-loaded-link {
 >       base svec-metric-type;
 >       description
 >         "Load of the most loaded link.";
 >       reference
 >         "RFC 5541: Encoding of Objective Functions in the Path
 >         Computation Element Communication Protocol (PCEP)";
 >     }
 >
 2222,2225c3106,3111
 <        RFC 7823: Performance-Based Path Selection for Explicitly
 <        Routed Label Switched Paths (LSPs) Using TE Metric
 <        Extensions
 <        RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
 ---
 >
 >       RFC 7823: Performance-Based Path Selection for Explicitly
 >       Routed Label Switched Paths (LSPs) Using TE Metric
 >       Extensions
 >
 >       RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
 2506a3393,3395
 >   // CHANGE NOTE: The explicit-route-hop grouping below has been
 >   // updated in this module revision
 >   // RFC Editor: remove the note above and this note
 2514a3404,3412
 >           must "node-id-uri or node-id" {
 >             description
 >               "At least one node identifier MUST be present.";
 >           }
 >           leaf node-id-uri {
 >             type nw:node-id;
 >             description
 >               "The identifier of a node in the topology.";
 >           }
 2517d3414
 <             mandatory true;
 2566a3464,3474
 >           must "(link-tp-id-uri or link-tp-id) and " +
 >                 "(node-id-uri or node-id)" {



Busi, et al.             Expires 25 August 2024               [Page 160]

Internet-Draft            TE Common YANG Types             February 2024


 >             description
 >               "At least one node identifier and at least one Link
 >               Termination Point (LTP) identifier MUST be present.";
 >           }
 >           leaf link-tp-id-uri {
 >             type nt:tp-id;
 >             description
 >               "Link Termination Point (LTP) identifier.";
 >           }
 2569d3476
 <             mandatory true;
 2574a3482,3486
 >           leaf node-id-uri {
 >             type nw:node-id;
 >             description
 >               "The identifier of a node in the topology.";
 >           }
 2577d3488
 <             mandatory true;
 2631a3543,3545
 >   // CHANGE NOTE: The explicit-route-hop grouping below has been
 >   // updated in this module revision
 >   // RFC Editor: remove the note above and this note
 2646a3561,3564
 >           must "node-id-uri or node-id" {
 >             description
 >               "At least one node identifier MUST be present.";
 >           }
 2648a3567,3571
 >           leaf node-id-uri {
 >             type nw:node-id;
 >             description
 >               "The identifier of a node in the topology.";
 >           }
 2651d3573
 <             mandatory true;
 2696a3619,3629
 >           must "(link-tp-id-uri or link-tp-id) and " +
 >               "(node-id-uri or node-id)" {
 >             description
 >               "At least one node identifier and at least one Link
 >               Termination Point (LTP) identifier MUST be present.";
 >           }
 >           leaf link-tp-id-uri {
 >             type nt:tp-id;
 >             description
 >               "Link Termination Point (LTP) identifier.";
 >           }



Busi, et al.             Expires 25 August 2024               [Page 161]

Internet-Draft            TE Common YANG Types             February 2024


 2699d3631
 <             mandatory true;
 2704a3637,3641
 >           leaf node-id-uri {
 >             type nw:node-id;
 >             description
 >               "The identifier of a node in the topology.";
 >           }
 2881a3819,3821
 >   // CHANGE NOTE: The grouping optimization-metric-entry below has
 >   // been updated in this module revision
 >   // RFC Editor: remove the note above and this note
 2887c3827
 <         base path-metric-type;
 ---
 >         base path-metric-optimization-type;
 2964a3905,3907
 >   // CHANGE NOTE: The grouping tunnel-constraints below has
 >   // been updated in this module revision
 >   // RFC Editor: remove the note above and this note
 2968a3912,3916
 >     leaf network-id {
 >       type nw:network-id;
 >       description
 >         "The network topology identifier.";
 >     }
 2972a3921,3923
 >   // CHANGE NOTE: The grouping path-constraints-route-objects below
 >   // has been updated in this module revision
 >   // RFC Editor: remove the note above and this note
 2977c3928
 <     container explicit-route-objects-always {
 ---
 >     container explicit-route-objects {
 2979c3930
 <         "Container for the 'exclude route' object list.";
 ---
 >         "Container for the explicit route object lists.";
 3101a4053,4055
 >   // CHANGE NOTE: The grouping generic-path-metric-bounds below
 >   // has been updated in this module revision
 >   // RFC Editor: remove the note above and this note
 3107c4061
 <         "TE path metric bounds container.";
 ---
 >         "Top-level container for the list of path metric bounds.";
 3111c4065,4073
 <           "List of TE path metric bounds.";



Busi, et al.             Expires 25 August 2024               [Page 162]

Internet-Draft            TE Common YANG Types             February 2024


 ---
 >           "List of path metric bounds, which can apply to link and
 >           path metrics.
 >
 >           TE paths which have at least one path metric which
 >           exceeds the specified bounds MUST NOT be selected.
 >
 >           TE paths that traverse TE links which have at least one
 >           link metric which exceeds the specified bounds MUST NOT
 >           be selected.";
 3114c4076
 <             base path-metric-type;
 ---
 >             base link-path-metric-type;
 3124,3126c4086,4092
 <             "Upper bound on the end-to-end TE path metric.  A zero
 <              indicates an unbounded upper limit for the specific
 <              'metric-type'.";
 ---
 >             "Upper bound on the specified 'metric-type'.
 >
 >             A zero indicates an unbounded upper limit for the
 >             specificied 'metric-type'.
 >
 >             The unit of is interpreted in the context of the
 >             'metric-type' identity.";
 3131a4098,4100
 >   // CHANGE NOTE: The grouping generic-path-metric-bounds below
 >   // has been updated in this module revision
 >   // RFC Editor: remove the note above and this note
 3152a4122
 >             status deprecated;
 3154c4124,4127
 <               "Container for the list of tiebreakers.";
 ---
 >               "Container for the list of tiebreakers.
 >
 >               This container has been obsoleted by the tiebreaker
 >               leaf.";
 3189a4163,4171
 >     leaf tiebreaker {
 >       type identityref {
 >         base path-tiebreaker-type;
 >       }
 >       default "te-types:path-tiebreaker-random";
 >       description
 >         "The tiebreaker criteria to apply on an equally favored set
 >         of paths, in order to pick the best.";



Busi, et al.             Expires 25 August 2024               [Page 163]

Internet-Draft            TE Common YANG Types             February 2024


 >     }
 3379c4361,4420
 < }
 \ No newline at end of file
 ---
 >
 >   // NOTE: The grouping encoding-and-switching-type below has been
 >   // added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   grouping encoding-and-switching-type {
 >     description
 >       "Common grouping to define the LSP encoding and
 >       switching types";
 >     leaf encoding {
 >       type identityref {
 >         base te-types:lsp-encoding-types;
 >       }
 >       description
 >         "LSP encoding type.";
 >       reference
 >         "RFC 3945";
 >     }
 >     leaf switching-type {
 >       type identityref {
 >         base te-types:switching-capabilities;
 >       }
 >       description
 >         "LSP switching type.";
 >       reference
 >         "RFC 3945";
 >     }
 >   }
 >
 >   // CHANGE NOTE: The typedef te-gen-node-id below has been
 >   // added in this module revision
 >   // RFC Editor: remove the note above and this note
 >   grouping te-generic-node-id {
 >     description
 >       "A reusable grouping for a TE generic node identifier.";
 >     leaf id {
 >       type te-gen-node-id;
 >       description
 >         "The identifier of the node. Can be represented as IP
 >          address or dotted quad address or as an URI.";
 >     }
 >     leaf type {
 >       type enumeration {
 >         enum ip {



Busi, et al.             Expires 25 August 2024               [Page 164]

Internet-Draft            TE Common YANG Types             February 2024


 >           description
 >             "IP address representation of the node identifier.";
 >         }
 >         enum te-id {
 >           description
 >             "TE identifier of the node";
 >         }
 >         enum node-id {
 >           description
 >             "URI representation of the node identifier.";
 >         }
 >       }
 >       description
 >         "Type of node identifier representation.";
 >     }
 >   }
 > }

A.2.  Packet TE Types YANG Diffs

   RFC Editor: please remove this appendix before publication.

   This section provides the diff between the YANG module in section 3.2
   of [RFC8776] and the YANG model revision in Section 5.

   The intention of this appendix is to facilitate focusing the review
   of the YANG model in Section 5 to the changes compared with the YANG
   model in [RFC8776].

   This diff has been generated using the following UNIX commands to
   compare the YANG module revisions in section 3.2 of [RFC8776] and in
   Section 5:

   diff ietf-te-packet-types@2020-06-10.yang ietf-te-packet-types.yang
        > model-diff.txt
   sed 's/^/    /' model-diff.txt > model-diff-spaces.txt
   sed 's/^    >   /    >   /' model-diff-spaces.txt
       > model-updates.txt

   The output (model-updates.txt) is reported here:

  11c11
  <       "RFC 8776: Common YANG Data Types for Traffic Engineering";
  ---
  >       "RFCXXXX: Common YANG Data Types for Traffic Engineering";
  12a13,14
  >   // RFC Editor: replace XXXX with actual RFC number
  >   // and remove this note



Busi, et al.             Expires 25 August 2024               [Page 165]

Internet-Draft            TE Common YANG Types             February 2024


  22c24
  <                <mailto:tsaad@juniper.net>
  ---
  >                <mailto:tsaad.net@gmail.com>
  37,39c39,49
  <      data type definitions specific to MPLS TE.  The model fully
  <      conforms to the Network Management Datastore Architecture
  <      (NMDA).
  ---
  >      data type definitions specific to Packet Traffic Enginnering
  >      (TE).
  >
  >      The model fully conforms to the Network Management Datastore
  >      Architecture (NMDA).
  >
  >      The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
  >      NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
  >      'MAY', and 'OPTIONAL' in this document are to be interpreted as
  >      described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
  >      they appear in all capitals, as shown here.
  41c51
  <      Copyright (c) 2020 IETF Trust and the persons identified as
  ---
  >      Copyright (c) 2024 IETF Trust and the persons identified as
  46c56
  <      the license terms contained in, the Simplified BSD License set
  ---
  >      the license terms contained in, the Revised BSD License set
  51,52c61,82
  <      This version of this YANG module is part of RFC 8776; see the
  <      RFC itself for full legal notices.";
  ---
  >      This version of this YANG module is part of RFC XXXX
  >      (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
  >      for full legal notices.";
  >   revision 2024-02-16 {
  >     description
  >       "This revision adds the following new identities:
  >        - bandwidth-profile-type;
  >        - link-metric-delay-variation;
  >        - link-metric-loss;
  >        - path-metric-delay-variation;
  >        - path-metric-loss.
  >
  >       This revision adds the following new groupings:
  >        - te-packet-path-bandwidth;
  >        - te-packet-link-bandwidth.
  >



Busi, et al.             Expires 25 August 2024               [Page 166]

Internet-Draft            TE Common YANG Types             February 2024


  >       This revision provides also few editorial changes.";
  >     reference
  >       "RFC XXXX: Common YANG Data Types for Traffic Engineering";
  >   }
  >   // RFC Editor: replace XXXX with actual RFC number, update date
  >   // information and remove this note
  61c91,196
  <   /**
  ---
  >   /*
  >    * Identities
  >    */
  >
  >   // CHANGE NOTE: The base identity bandwidth-profile-type and
  >   // its derived identities below have been
  >   // added in this module revision
  >   // RFC Editor: remove the note above and this note
  >   identity bandwidth-profile-type {
  >     description
  >       "Bandwidth Profile Types";
  >   }
  >
  >     identity mef-10-bwp {
  >       base bandwidth-profile-type;
  >       description
  >         "MEF 10 Bandwidth Profile";
  >       reference
  >         "MEF 10.3: Ethernet Services Attributes Phase 3";
  >     }
  >
  >     identity rfc-2697-bwp {
  >       base bandwidth-profile-type;
  >       description
  >         "RFC 2697 Bandwidth Profile";
  >       reference
  >         "RFC2697: A Single Rate Three Color Marker";
  >     }
  >
  >     identity rfc-2698-bwp {
  >       base bandwidth-profile-type;
  >       description
  >         "RFC 2698 Bandwidth Profile";
  >       reference
  >         "RFC2698: A Two Rate Three Color Marker";
  >     }
  >
  >     identity rfc-4115-bwp {
  >       base bandwidth-profile-type;



Busi, et al.             Expires 25 August 2024               [Page 167]

Internet-Draft            TE Common YANG Types             February 2024


  >       description
  >         "RFC 4115 Bandwidth Profile";
  >       reference
  >         "RFC4115: A Differentiated Service Two-Rate, Three-Color
  >         Marker with Efficient Handling of in-Profile Traffic";
  >     }
  >
  >     // CHANGE NOTE: The identity link-metric-delay-variation
  >     // below has been added in this module revision
  >     // RFC Editor: remove the note above and this note
  >     identity link-metric-delay-variation {
  >       base te-types:link-metric-type;
  >       description
  >         "The Unidirectional Delay Variation Metric,
  >         measured in units of microseconds.";
  >       reference
  >         "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions,
  >         section 4.3
  >
  >         RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions,
  >         section 4.3";
  >     }
  >
  >     // CHANGE NOTE: The identity link-metric-loss below has
  >     // been added in this module revision
  >     // RFC Editor: remove the note above and this note
  >     identity link-metric-loss {
  >       base te-types:link-metric-type;
  >       description
  >         "The Unidirectional Link Loss Metric,
  >         measured in units of 0.000003%.";
  >       reference
  >         "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions,
  >         section 4.4
  >
  >         RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions,
  >         section 4.4";
  >     }
  >
  >     // CHANGE NOTE: The identity path-metric-delay-variation
  >     // below has been added in this module revision
  >     // RFC Editor: remove the note above and this note
  >     identity path-metric-delay-variation {
  >       base te-types:path-metric-type;
  >       description
  >         "The Path Delay Variation Metric,
  >         measured in units of microseconds.";
  >       reference



Busi, et al.             Expires 25 August 2024               [Page 168]

Internet-Draft            TE Common YANG Types             February 2024


  >         "RFC8233: Extensions to the Path Computation Element
  >         Communication Protocol (PCEP) to Compute Service-Aware Label
  >         Switched Paths (LSPs), section 3.1.2";
  >     }
  >
  >     // CHANGE NOTE: The identity path-metric-loss below has
  >     // been added in this module revision
  >     // RFC Editor: remove the note above and this note
  >     identity path-metric-loss {
  >       base te-types:path-metric-type;
  >       description
  >         "The Path Loss Metric, measured in units of 0.000003%.";
  >       reference
  >         "RFC8233: Extensions to the Path Computation Element
  >         Communication Protocol (PCEP) to Compute Service-Aware Label
  >         Switched Paths (LSPs), section 3.1.3";
  >     }
  >
  >   /*
  180a316,319
  >   /*
  >    * Groupings
  >    */
  >
  472a612,681
  >     }
  >   }
  >
  >   // CHANGE NOTE: The te-packet-path-bandwidth below has been
  >   // added in this module revision
  >   // RFC Editor: remove the note above and this note
  >   grouping te-packet-path-bandwidth {
  >     description
  >       "Path bandwidth for Packet. ";
  >     leaf bandwidth-profile-name {
  >       type string;
  >       description "Name of Bandwidth Profile.";
  >     }
  >     leaf bandwidth-profile-type {
  >       type identityref {
  >         base bandwidth-profile-type;
  >       }
  >       description "Type of Bandwidth Profile.";
  >     }
  >     leaf cir {
  >       type uint64;
  >       units "bits/second";
  >       mandatory true;



Busi, et al.             Expires 25 August 2024               [Page 169]

Internet-Draft            TE Common YANG Types             February 2024


  >       description
  >         "Committed Information Rate (CIR).";
  >     }
  >     leaf cbs {
  >       type uint64;
  >       units "bits/second";
  >       mandatory true;
  >       description
  >         "Committed Burst Size (CBS).";
  >     }
  >     leaf eir {
  >       type uint64;
  >       units "bits/second";
  >       description
  >         "Excess Information Rate (EIR).";
  >     }
  >     leaf ebs {
  >       type uint64;
  >       units "bytes";
  >       description
  >         "Excess Burst Size (EBS).";
  >     }
  >     leaf pir {
  >       type uint64;
  >       units "bits/second";
  >       description
  >         "Peak Information Rate (PIR).";
  >     }
  >     leaf pbs {
  >       type uint64;
  >       units "bytes";
  >       description
  >         "Peak Burst Size (PBS).";
  >     }
  >   }
  >
  >   // CHANGE NOTE: The te-packet-path-bandwidth below has been
  >   // added in this module revision
  >   // RFC Editor: remove the note above and this note
  >   grouping te-packet-link-bandwidth {
  >     description
  >       "Link Bandwidth for Packet. ";
  >     leaf packet-bandwidth {
  >       type uint64;
  >       units "bits/second";
  >       description
  >         "Available bandwith value.";




Busi, et al.             Expires 25 August 2024               [Page 170]

Internet-Draft            TE Common YANG Types             February 2024


Appendix B.  Option Considered for updating RFC8776

   RFC Editor: please remove this appendix before publication.

   The concern is how to be able to update the ietf-te-types YANG module
   published in [RFC8776] without delaying too much the progress of the
   mature WG documents.

   Three possible options have been identified to address this concern.

   One option is to keep these definitions in the YANG modules where
   they have initially been defined: other YANG modules can still import
   them.  The drawback of this approach is that it defeating the value
   of common YANG modules like ietf-te-types since common definitions
   will be spread around multiple specific YANG modules.

   A second option is to define them in a new common YANG module (e.g.,
   ietf-te-types-ext).  The drawback of this approach is that it will
   increase the number of YANG modules providing tiny updates to the
   ietf-te-types YANG module.

   A third option is to develop a revision of the ietf-te-types YANG
   module within an RFC8776-bis.  The drawback of this approach is that
   the process for developing a big RFC8776-bis just for a tiny update
   is too high.  Moreover, as suggested during IETF 113 Netmod WG
   discussion, a new revision of the ietf-te-packet-types YANG module,
   which is also defined in [RFC8776] but it does not need to be
   revised, needs to be published just to change its reference to
   RFC8776-bis (see [RFC9314]).

   A fourth option, considered in the -00 WG version, was to:

   *  describe within the document only the updates to the ietf-te-types
      YANG module proposed by this document;

   *  include the whole updated YANG model within the main body;

   *  add some notes, to be removed before publication, within updated
      YANG model to focus the review only to the updates to the ietf-te-
      types YANG module proposed by this document.

   Based on the feedbacks from IETF 114 discussion, this version has
   been restructured to become an RFC8776-bis, with some notes, to be
   removed before publication, to focus the review only to the updates
   to the ietf-te-types YANG module proposed by this document.

   During the Netmod WG session at IETF 114, an alternative process has
   been introduced:



Busi, et al.             Expires 25 August 2024               [Page 171]

Internet-Draft            TE Common YANG Types             February 2024


   https://datatracker.ietf.org/meeting/114/materials/slides-114-netmod-
   ad-topic-managing-the-evolution-of-ietf-yang-modules-00.pdf

   Future updates of this document could align with the proposed
   approach.

Acknowledgements

   The authors would like to thank Robert Wilton, Lou Berger, Mahesh
   Jethanandani and Jeff Haas for their valuable input to the discussion
   about the process to follow to provide tiny updates to a YANG module
   already published as an RFC.

   This document was prepared using kramdown.

Contributors

   Vishnu Pavan Beeram
   Juniper Networks
   Email: vbeeram@juniper.net


   Rakesh Gandhi
   Cisco Systems, Inc.
   Email: rgandhi@cisco.com


Authors' Addresses

   Italo Busi
   Huawei
   Email: italo.busi@huawei.com


   Aihua Guo
   Futurewei Technologies
   Email: aihuaguo.ietf@gmail.com


   Xufeng Liu
   Alef Edge
   Email: xufeng.liu.ietf@gmail.com


   Tarek Saad
   Cisco Systems Inc.
   Email: tsaad.net@gmail.com




Busi, et al.             Expires 25 August 2024               [Page 172]

Internet-Draft            TE Common YANG Types             February 2024


   Igor Bryskin
   Individual
   Email: i_bryskin@yahoo.com
















































Busi, et al.             Expires 25 August 2024               [Page 173]