From fa2e4856dc81f91638f9d623223b627c184d1599 Mon Sep 17 00:00:00 2001 From: italobusi Date: Tue, 5 Nov 2024 01:25:30 +0100 Subject: [PATCH] Addressing 2n WG LC comments (#294) * Resolved idnits * Folded YANG trees * Added back change note on typedef te-node-id * Fixing .gitignore issue * Ignoring generated diff files * Ignoring folded trees * Addressing comments from Med * Updated IANA considerations * Removed change notes together with appendix B and C * Indented all derived identities in YANG models --- .gitignore | 10 +- .../draft-ietf-teas-rfc8776-update.md | 194 +- .../draft-ietf-teas-rfc8776-update.txt | 8518 +++++---------- .../draft-ietf-teas-rfc8776-update.xml | 9237 ++++++----------- ietf-te-packet-types.tree.fold | 148 - ietf-te-packet-types.yang | 91 +- ietf-te-types.tree.fold | 690 -- ietf-te-types.yang | 2706 +++-- 8 files changed, 6979 insertions(+), 14615 deletions(-) delete mode 100644 ietf-te-packet-types.tree.fold delete mode 100644 ietf-te-types.tree.fold diff --git a/.gitignore b/.gitignore index baeb0af..d0853fb 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,5 @@ +*.fold *.swp ietf-mpls-static-extended.fxs ietf-mpls-static.fxs @@ -6,7 +7,8 @@ ietf-mpls-static.fxs rsvp_te_model.tree.folded rsvp_te_model.tree.save *.comments -drafts/te-topo-profile/.refcache/*.* -drafts/mpls-te-topology/.refcache/*.* -drafts/te-types-update/.refcache/*.* -drafts/te-types-update/diffs/*.* +drafts/te-topo-profile/.refcache/ +drafts/mpls-te-topology/.refcache/ +drafts/te-types-update/.refcache/ +drafts/te-types-update/diffs/ +*.bash diff --git a/drafts/te-types-update/draft-ietf-teas-rfc8776-update.md b/drafts/te-types-update/draft-ietf-teas-rfc8776-update.md index 1f67fff..9887e6d 100644 --- a/drafts/te-types-update/draft-ietf-teas-rfc8776-update.md +++ b/drafts/te-types-update/draft-ietf-teas-rfc8776-update.md @@ -47,13 +47,15 @@ contributor: email: rgandhi@cisco.com normative: - ITU_G.808.1: - title: Generic protection switching - Linear trail and subnetwork protection + ITU-T_G.709: + title: Interfaces for the optical transport network author: - org: ITU-T Recommendation G.808.1 - date: May 2014 - seriesinfo: ITU-T Recommendation G.808.1 - target: https://www.itu.int/rec/T-REC-G.808.1 + org: International Telecommunication Union + date: June 2020 + seriesinfo: ITU-T G.709 + target: https://www.itu.int/rec/T-REC-G.709 + +informative: MEF_10.3: title: Ethernet Services Attributes Phase 3 author: @@ -61,13 +63,6 @@ normative: date: October 2013 seriesinfo: MEF 10.3 target: https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_10.pdf - ITU-T_G.709: - title: Interfaces for the optical transport network - author: - org: International Telecommunication Union - date: June 2020 - seriesinfo: ITU-T G.709 - target: https://www.itu.int/rec/T-REC-G.709 --- abstract @@ -79,7 +74,7 @@ This document obsoletes RFC 8776. # 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}} or RESTCONF {{!RFC8040}}. The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. +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}} or RESTCONF {{?RFC8040}}. The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. 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 mainly designed to be the common definitions applicable for modeling Traffic Engineering (TE) features in model(s) defined outside of this document. Nevertheless, these common definitions can be used by any other module per the guidance in {{Section 4.12 of ?I-D.ietf-netmod-rfc8407bis}}. @@ -92,8 +87,6 @@ This document adds new common data types, identities, and groupings to both the The terminology for describing YANG data models is found in {{!RFC7950}}. -> RFC Editor: The document uses "CHANGE NOTE" to ease identifying the changes vs. RFC8776. Please remove these notes. - ## Tree Diagrams Tree diagrams used in this document follow the notation defined in {{?RFC8340}}. @@ -178,7 +171,7 @@ 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: -: 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}}. +: 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. @@ -221,34 +214,28 @@ 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}}. +: An enumerated type for the different statuses of a recovery action as defined in {{!RFC6378}} and {{?RFC4427}}. The "ietf-te-types" module contains the following YANG reusable identities: 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}}. +: 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}}. +: A base YANG identity for supported link protection types as defined in {{!RFC4872}}. 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. +: A base YANG identity for supported protection-related external commands used for troubleshooting purposes, as defined in {{!RFC4872}}, {{!RFC6368}}, {{!RFC7271}} and {{?RFC4427}}. 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. - 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. - te-tunnel-type: : A base YANG identity for supported TE tunnel types as defined in {{!RFC3209}} and {{!RFC4875}}. @@ -262,12 +249,10 @@ 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 +: 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 {{!RFC3209}} and {{?RFC2702}}. path-metric-type: -: A base YANG identity for supported path metric types as defined in {{!RFC3630}}, {{!RFC3785}}, {{!RFC5440}}, {{!RFC7471}}, {{!RFC8233}}, {{!RFC8570}} and {{!I-D.ietf-pce-sid-algo}}. +: A base YANG identity for supported path metric types as defined in {{!RFC3630}}, {{!RFC3785}}, {{!RFC5440}}, {{!RFC7471}}, {{!RFC8233}}, {{!RFC8570}} and {{?I-D.ietf-pce-sid-algo-14}}. : 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}}. @@ -277,8 +262,6 @@ explicit-route-hop: te-link-access-type: : An enumerated type for the different TE link access types as defined in {{!RFC3630}}. -> CHANGE NOTE: The module "ietf-te-types" has been updated to add the following YANG identities, types and groupings. - 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. @@ -297,10 +280,6 @@ svec-metric-type: 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. - ### Path Computation Errors {#pc-error} 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}}. @@ -345,7 +324,7 @@ bc-type: : 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}}. +: 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. @@ -353,10 +332,8 @@ te-bandwidth-requested-type: 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. - 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). +: A base YANG identity for various bandwidth profiles specified in {{MEF_10.3}}, {{?RFC2697}} and {{?RFC2698}} that may be used to limit bandwidth utilization of packet flows (e.g., MPLS-TE LSPs). bandwidth-profile-parameters: : A YANG grouping that defines common parameters for bandwidth profiles in packet networks. @@ -378,27 +355,23 @@ The "ietf-te-types" module imports from the following modules: - "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 {{te-yang-diff}}. +{{?RFC9522}}, {{!RFC4090}}, {{!RFC4202}}, {{!RFC4328}}, {{!RFC4561}}, {{?RFC4657}}, {{?RFC4736}}, {{!RFC6004}}, {{!RFC6378}}, {{!RFC6511}}, {{!RFC7139}}, {{!RFC7271}}, {{!RFC7308}}, {{!RFC7551}}, {{!RFC7571}}, {{!RFC7579}}, and {{ITU-T_G.709}}. ~~~~ yang {::include ../../ietf-te-types.yang} ~~~~ {: #fig-te-yang title="TE Types YANG module" -sourcecode-markers="true" sourcecode-name="ietf-te-types@2024-01-29.yang"} +sourcecode-markers="true" sourcecode-name="ietf-te-types@2024-10-24.yang"} # Packet TE Types YANG Module {#pkt-yang-code} The "ietf-te-packet-types" module imports from the "ietf-te-types" module defined in {{te-yang-code}} of this document. -> CHANGE NOTE: Please focus your review only on the updates to the YANG model: see also {{te-yang-diff}}. - ~~~~ yang {::include ../../ietf-te-packet-types.yang} ~~~~ {: #fig-pkt-yang title="Packet TE Types YANG module" -sourcecode-markers="true" sourcecode-name="ietf-te-packet-types@2024-01-25.yang"} +sourcecode-markers="true" sourcecode-name="ietf-te-packet-types@2024-10-17.yang"} # IANA Considerations @@ -414,8 +387,7 @@ This document requests IANA to update the following URIs in the "IETF XML Regist XML: N/A, the requested URI is an XML namespace. ~~~~ -This document also requests IANA to update the following YANG modules to the "YANG Module -Names" registry {{!RFC7950}}: +This document requests IANA to register the following YANG modules in the "YANG Module Names" registry {{!RFC6020}} within the "YANG Parameters" registry group. ~~~~ name: ietf-te-types @@ -433,27 +405,31 @@ Names" registry {{!RFC7950}}: # 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. +This section is modeled after the template described in Section 3.7 +of {{?I-D.ietf-netmod-rfc8407bis}}. + +The "ietf-te-types" and the "ietf-te-packet-types" YANG modules define data models that are +designed to be accessed via YANG-based management protocols, such as +NETCONF {{?RFC6241}} and RESTCONF {{?RFC8040}}. These protocols have to +use a secure transport layer (e.g., SSH {{?RFC4252}}, TLS {{?RFC8446}}, and +QUIC {{?RFC9000}}) and have to use mutual authentication. + +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 modules define a set of identities, types, and +groupings. These nodes are intended to be reused by other YANG +modules. The modules by themselves do not expose any data nodes that +are writable, data nodes that contain read-only state, or RPCs. +As such, there are no additional security issues related to +the YANG module that need to be considered. + +Modules that use the groupings that are defined in this document +should identify the corresponding security considerations. For +example, reusing some of these groupings will expose privacy-related +information (e.g., 'node-example'). --- back @@ -464,6 +440,8 @@ model. See {{?RFC8340}} for an explanation of the symbols used. The data type of every leaf node is shown near the right end of the corresponding line. +> Editors' Note: The YANG trees have been generated by pyang and have some bugs to be fixed before publication. Please manually fix the YANG tree before sending the document to the RFC EDITOR. + ## TE Types Schema Tree ~~~~ ascii-art @@ -668,80 +646,6 @@ The following identities, already defined in {{!RFC8776}}, have been obsoletes i - lsp-protection-reroute. -## TE Types YANG Diffs {#te-yang-diff} - -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 {{te-yang-code}}. - -The intention of this appendix is to facilitate focusing the review of the YANG model in {{te-yang-code}} 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 {{te-yang-code}}: - -~~~~ -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: - -{::include ./diffs/te-types/model-updates.txt} - -## 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 {{pkt-yang-code}}. - -The intention of this appendix is to facilitate focusing the review of the YANG model in {{pkt-yang-code}} 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 {{pkt-yang-code}}: - -~~~~ -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: - -{::include ./diffs/te-pkt-types/model-updates.txt} - -# Option Considered for updating RFC8776 {#options} - -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: - -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. - {: numbered="false"} # Acknowledgements diff --git a/drafts/te-types-update/draft-ietf-teas-rfc8776-update.txt b/drafts/te-types-update/draft-ietf-teas-rfc8776-update.txt index 8f1a7a0..f955636 100644 --- a/drafts/te-types-update/draft-ietf-teas-rfc8776-update.txt +++ b/drafts/te-types-update/draft-ietf-teas-rfc8776-update.txt @@ -6,13 +6,13 @@ TEAS Working Group I. Busi Internet-Draft Huawei Obsoletes: 8776 (if approved) A. Guo Intended status: Standards Track Futurewei Technologies -Expires: 31 March 2025 X. Liu +Expires: 9 May 2025 X. Liu Alef Edge T. Saad Cisco Systems Inc. I. Bryskin Individual - 27 September 2024 + 5 November 2024 Common YANG Data Types for Traffic Engineering @@ -43,7 +43,7 @@ Status of This Memo 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 31 March 2025. + This Internet-Draft will expire on 9 May 2025. Copyright Notice @@ -53,9 +53,9 @@ Copyright Notice -Busi, et al. Expires 31 March 2025 [Page 1] +Busi, et al. Expires 9 May 2025 [Page 1] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 This document is subject to BCP 78 and the IETF Trust's Legal @@ -74,28 +74,25 @@ Table of Contents 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 9 - 3.1.2. Protocol Origin . . . . . . . . . . . . . . . . . . . 10 - 3.2. Packet TE Types Module Contents . . . . . . . . . . . . . 10 - 4. TE Types YANG Module . . . . . . . . . . . . . . . . . . . . 11 - 5. Packet TE Types YANG Module . . . . . . . . . . . . . . . . . 105 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 123 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 124 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 124 - 8.2. Informative References . . . . . . . . . . . . . . . . . 133 - Appendix A. The Complete Schema Trees . . . . . . . . . . . . . 133 - A.1. TE Types Schema Tree . . . . . . . . . . . . . . . . . . 133 - A.2. Packet TE Types Schema Tree . . . . . . . . . . . . . . . 148 - Appendix B. Changes from RFC 8776 . . . . . . . . . . . . . . . 151 - B.1. TE Types YANG Diffs . . . . . . . . . . . . . . . . . . . 156 - B.2. Packet TE Types YANG Diffs . . . . . . . . . . . . . . . 200 - Appendix C. Option Considered for updating RFC8776 . . . . . . . 212 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 213 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 213 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 213 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. TE Types Module Contents . . . . . . . . . . . . . . . . 4 + 3.1.1. Path Computation Errors . . . . . . . . . . . . . . . 8 + 3.1.2. Protocol Origin . . . . . . . . . . . . . . . . . . . 9 + 3.2. Packet TE Types Module Contents . . . . . . . . . . . . . 9 + 4. TE Types YANG Module . . . . . . . . . . . . . . . . . . . . 10 + 5. Packet TE Types YANG Module . . . . . . . . . . . . . . . . . 102 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 119 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 120 + 8.2. Informative References . . . . . . . . . . . . . . . . . 128 + Appendix A. The Complete Schema Trees . . . . . . . . . . . . . 130 + A.1. TE Types Schema Tree . . . . . . . . . . . . . . . . . . 130 + A.2. Packet TE Types Schema Tree . . . . . . . . . . . . . . . 145 + Appendix B. Changes from RFC 8776 . . . . . . . . . . . . . . . 148 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 153 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 153 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 153 1. Introduction @@ -106,17 +103,17 @@ Table of Contents The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. + 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 mainly designed to be the common -Busi, et al. Expires 31 March 2025 [Page 2] +Busi, et al. Expires 9 May 2025 [Page 2] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 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 mainly designed to be the common definitions applicable for modeling Traffic Engineering (TE) features in model(s) defined outside of this document. Nevertheless, these common definitions can be used by any other module per the guidance @@ -138,9 +135,6 @@ Internet-Draft TE Common YANG Types September 2024 The terminology for describing YANG data models is found in [RFC7950]. - RFC Editor: The document uses "CHANGE NOTE" to ease identifying - the changes vs. RFC8776. Please remove these notes. - 1.2. Tree Diagrams Tree diagrams used in this document follow the notation defined in @@ -152,24 +146,6 @@ Internet-Draft TE Common YANG Types September 2024 the standard prefix associated with the corresponding YANG imported modules, as shown in Table 1. - - - - - - - - - - - - - -Busi, et al. Expires 31 March 2025 [Page 3] - -Internet-Draft TE Common YANG Types September 2024 - - +=================+======================+========================+ | Prefix | YANG module | Reference | +=================+======================+========================+ @@ -186,6 +162,14 @@ Internet-Draft TE Common YANG Types September 2024 Table 1: Prefixes and corresponding YANG modules + + + +Busi, et al. Expires 9 May 2025 [Page 3] + +Internet-Draft TE Common YANG Types November 2024 + + RFC Editor: Please replace XXXX through this document with the RFC number assigned to this document. Please remove this note. @@ -219,13 +203,6 @@ Internet-Draft TE Common YANG Types September 2024 TE: Traffic Engineering - - -Busi, et al. Expires 31 March 2025 [Page 4] - -Internet-Draft TE Common YANG Types September 2024 - - WTR: Wait-to-Restore 3. Overview @@ -241,6 +218,14 @@ Internet-Draft TE Common YANG Types September 2024 are independent and agnostic of any specific technology or control- plane instance. + + + +Busi, et al. Expires 9 May 2025 [Page 4] + +Internet-Draft TE Common YANG Types November 2024 + + The "ietf-te-types" module contains the following YANG reusable groupings: @@ -274,14 +259,6 @@ Internet-Draft TE Common YANG Types September 2024 te-hop-type: An enumerated type for specifying that a hop is loose or strict. - - - -Busi, et al. Expires 31 March 2025 [Page 5] - -Internet-Draft TE Common YANG Types September 2024 - - 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 Section 3 of @@ -294,6 +271,17 @@ Internet-Draft TE Common YANG Types September 2024 shortened-mixed IPv6 address notation. This attribute MAY be mapped to the Router Address TLV described + + + + + + +Busi, et al. Expires 9 May 2025 [Page 5] + +Internet-Draft TE Common YANG Types November 2024 + + in Section 2.4.1 of [RFC3630], the TE Router ID described in Section 6.2 of [RFC6827], the Traffic Engineering Router ID TLV described in Section 4.3 of [RFC5305], or the TE Router ID TLV @@ -328,15 +316,7 @@ Internet-Draft TE Common YANG Types September 2024 [RFC3785]. te-recovery-status: An enumerated type for the different statuses of - a recovery action as defined in [RFC4427] and [RFC6378]. - - - - -Busi, et al. Expires 31 March 2025 [Page 6] - -Internet-Draft TE Common YANG Types September 2024 - + a recovery action as defined in [RFC6378] and [RFC4427]. The "ietf-te-types" module contains the following YANG reusable identities: @@ -348,52 +328,37 @@ Internet-Draft TE Common YANG Types September 2024 [RFC8169]. link-protection-type: A base YANG identity for supported link - protection types as defined in [RFC4872] and [RFC4427]. + protection types as defined in [RFC4872]. + + + + +Busi, et al. Expires 9 May 2025 [Page 6] + +Internet-Draft TE Common YANG Types November 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. + purposes, as defined in [RFC4872], [RFC6368], [RFC7271] and + [RFC4427]. 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. - 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. - te-tunnel-type: A base YANG identity for supported TE tunnel types as defined in [RFC3209] and [RFC4875]. lsp-encoding-types: A base YANG identity for supported LSP encoding types as defined in [RFC3471]. - - -Busi, et al. Expires 31 March 2025 [Page 7] - -Internet-Draft TE Common YANG Types September 2024 - - lsp-protection-type: A base YANG identity for supported LSP protection types as defined in [RFC4872] and [RFC4873]. @@ -402,14 +367,11 @@ Internet-Draft TE Common YANG Types September 2024 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 + for a link to be acceptable as defined in [RFC3209] and [RFC2702]. path-metric-type: A base YANG identity for supported path metric types as defined in [RFC3630], [RFC3785], [RFC5440], [RFC7471], - [RFC8233], [RFC8570] and [I-D.ietf-pce-sid-algo]. + [RFC8233], [RFC8570] and [I-D.ietf-pce-sid-algo-14]. The unit of the path metric value is interpreted in the context of the path metric type. The derived identities SHOULD describe the @@ -425,8 +387,12 @@ Internet-Draft TE Common YANG Types September 2024 te-link-access-type: An enumerated type for the different TE link access types as defined in [RFC3630]. - CHANGE NOTE: The module "ietf-te-types" has been updated to add - the following YANG identities, types and groupings. + + +Busi, et al. Expires 9 May 2025 [Page 7] + +Internet-Draft TE Common YANG Types November 2024 + lsp-provisioning-error-reason: A base YANG identity for reporting LSP provisioning error reasons. No standard LPS provisioning @@ -442,31 +408,11 @@ Internet-Draft TE Common YANG Types September 2024 SVEC objective functions as defined in [RFC5541] and [RFC8685]. svec-metric-type: A base YANG identity for supported SVEC objective - - - -Busi, et al. Expires 31 March 2025 [Page 8] - -Internet-Draft TE Common YANG Types September 2024 - - 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. - 3.1.1. Path Computation Errors The "ietf-te-types" module contains the YANG reusable identities for @@ -499,11 +445,9 @@ Internet-Draft TE Common YANG Types September 2024 - - -Busi, et al. Expires 31 March 2025 [Page 9] +Busi, et al. Expires 9 May 2025 [Page 8] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 3. match more than one PCEP numbers in order to hide the details of @@ -550,21 +494,17 @@ Internet-Draft TE Common YANG Types September 2024 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. - bandwidth-profile-type: A base YANG identity for various bandwidth + profiles specified in [MEF_10.3], [RFC2697] and [RFC2698] that may + be used to limit bandwidth utilization of packet flows (e.g., + MPLS-TE LSPs). -Busi, et al. Expires 31 March 2025 [Page 10] +Busi, et al. Expires 9 May 2025 [Page 9] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - 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). bandwidth-profile-parameters: A YANG grouping that defines common parameters for bandwidth profiles in packet networks. @@ -597,27 +537,16 @@ Internet-Draft TE Common YANG Types September 2024 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]. + [RFC4736], [RFC6004], [RFC6378], [RFC6511], [RFC7139], [RFC7271], + [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 B.1. - - file "ietf-te-types@2024-01-29.yang" + file "ietf-te-types@2024-10-24.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 31 March 2025 [Page 11] - -Internet-Draft TE Common YANG Types September 2024 - - prefix inet; reference "RFC 6991: Common YANG Data Types"; @@ -625,6 +554,14 @@ Internet-Draft TE Common YANG Types September 2024 import ietf-yang-types { prefix yang; reference + + + +Busi, et al. Expires 9 May 2025 [Page 10] + +Internet-Draft TE Common YANG Types November 2024 + + "RFC 6991: Common YANG Data Types"; } import ietf-routing-types { @@ -666,14 +603,6 @@ Internet-Draft TE Common YANG Types September 2024 Editor: Igor Bryskin "; - - - -Busi, et al. Expires 31 March 2025 [Page 12] - -Internet-Draft TE Common YANG Types September 2024 - - description "This YANG module contains a collection of generally useful YANG data type definitions specific to TE. The model fully @@ -681,6 +610,14 @@ Internet-Draft TE Common YANG Types September 2024 (NMDA). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL + + + +Busi, et al. Expires 9 May 2025 [Page 11] + +Internet-Draft TE Common YANG Types November 2024 + + 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, @@ -699,7 +636,7 @@ Internet-Draft TE Common YANG Types September 2024 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-09-13 { + revision 2024-10-30 { description "This revision adds the following new identities: - lsp-provisioning-error-reason; @@ -722,14 +659,6 @@ Internet-Draft TE Common YANG Types September 2024 - encoding-and-switching-type; - te-generic-node-id. - - - -Busi, et al. Expires 31 March 2025 [Page 13] - -Internet-Draft TE Common YANG Types September 2024 - - This revision updates the following identities: - objective-function-type; - action-exercise; @@ -737,6 +666,14 @@ Internet-Draft TE Common YANG Types September 2024 - path-metric-te; - path-metric-igp; - path-metric-hop; + + + +Busi, et al. Expires 9 May 2025 [Page 12] + +Internet-Draft TE Common YANG Types November 2024 + + - path-metric-delay-average; - path-metric-delay-minimum; - path-metric-residual-bandwidth; @@ -778,14 +715,6 @@ Internet-Draft TE Common YANG Types September 2024 - adds the following leaves: - tiebreaker; - deprecate the following containers: - - - -Busi, et al. Expires 31 March 2025 [Page 14] - -Internet-Draft TE Common YANG Types September 2024 - - - tiebreakers. This revision obsoletes the following identities: @@ -793,6 +722,14 @@ Internet-Draft TE Common YANG Types September 2024 - of-minimize-load-most-loaded-link; - of-minimize-cost-path-set; - lsp-protection-reroute-extra; + + + +Busi, et al. Expires 9 May 2025 [Page 13] + +Internet-Draft TE Common YANG Types November 2024 + + - lsp-protection-reroute. This revision provides also few editorial changes."; @@ -834,14 +771,6 @@ Internet-Draft TE Common YANG Types September 2024 } typedef admin-groups { - - - -Busi, et al. Expires 31 March 2025 [Page 15] - -Internet-Draft TE Common YANG Types September 2024 - - type union { type admin-group; type extended-admin-group; @@ -850,6 +779,13 @@ Internet-Draft TE Common YANG Types September 2024 "Derived types for TE administrative groups."; } + + +Busi, et al. Expires 9 May 2025 [Page 14] + +Internet-Draft TE Common YANG Types November 2024 + + typedef extended-admin-group { type yang:hex-string; description @@ -890,14 +826,6 @@ Internet-Draft TE Common YANG Types September 2024 "Normal. Indicates that the anomalous bit is not set."; } enum abnormal { - - - -Busi, et al. Expires 31 March 2025 [Page 16] - -Internet-Draft TE Common YANG Types September 2024 - - value 2; description "Abnormal. Indicates that the anomalous bit is set."; @@ -906,6 +834,14 @@ Internet-Draft TE Common YANG Types September 2024 description "Indicates whether a performance metric is normal (anomalous bit not set), abnormal (anomalous bit set), or unknown."; + + + +Busi, et al. Expires 9 May 2025 [Page 15] + +Internet-Draft TE Common YANG Types November 2024 + + reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly @@ -946,14 +882,6 @@ Internet-Draft TE Common YANG Types September 2024 reference "RFC 5817: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks"; - - - -Busi, et al. Expires 31 March 2025 [Page 17] - -Internet-Draft TE Common YANG Types September 2024 - - } enum maintenance { description @@ -962,6 +890,14 @@ Internet-Draft TE Common YANG Types September 2024 } enum unknown { description + + + +Busi, et al. Expires 9 May 2025 [Page 16] + +Internet-Draft TE Common YANG Types November 2024 + + "Status is unknown."; } } @@ -1002,14 +938,6 @@ Internet-Draft TE Common YANG Types September 2024 slot width 2 and a frequency slot 3 with slot width 3. Canonically, the string is represented as all lowercase and in hex, where the prefix '0x' precedes the hex number."; - - - -Busi, et al. Expires 31 March 2025 [Page 18] - -Internet-Draft TE Common YANG Types September 2024 - - reference "RFC 8294: Common YANG Data Types for the Routing Area ITU-T G.709: Interfaces for the optical transport network - @@ -1018,6 +946,14 @@ Internet-Draft TE Common YANG Types September 2024 typedef te-ds-class { type uint8 { + + + +Busi, et al. Expires 9 May 2025 [Page 17] + +Internet-Draft TE Common YANG Types November 2024 + + range "0..7"; } description @@ -1058,14 +994,6 @@ Internet-Draft TE Common YANG Types September 2024 "Enumerated type for specifying loose or strict paths."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, - - - -Busi, et al. Expires 31 March 2025 [Page 19] - -Internet-Draft TE Common YANG Types September 2024 - - Section 4.3.3"; } @@ -1074,6 +1002,14 @@ Internet-Draft TE Common YANG Types September 2024 enum point-to-point { description "The link is point-to-point."; + + + +Busi, et al. Expires 9 May 2025 [Page 18] + +Internet-Draft TE Common YANG Types November 2024 + + } enum multi-access { description @@ -1114,14 +1050,6 @@ Internet-Draft TE Common YANG Types September 2024 description "The explicit route represents an outgoing link on a node."; - - - -Busi, et al. Expires 31 March 2025 [Page 20] - -Internet-Draft TE Common YANG Types September 2024 - - } } description @@ -1130,6 +1058,14 @@ Internet-Draft TE Common YANG Types September 2024 } typedef te-metric { + + + +Busi, et al. Expires 9 May 2025 [Page 19] + +Internet-Draft TE Common YANG Types November 2024 + + type uint32; description "TE metric."; @@ -1138,9 +1074,6 @@ Internet-Draft TE Common YANG Types September 2024 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; @@ -1170,14 +1103,6 @@ Internet-Draft TE Common YANG Types September 2024 Section 4.3 RFC 6119: IPv6 Traffic Engineering in IS-IS, Section 3.2.1 RFC 6827: Automatically Switched Optical Network (ASON) - - - -Busi, et al. Expires 31 March 2025 [Page 21] - -Internet-Draft TE Common YANG Types September 2024 - - Routing for OSPFv2 Protocols, Section 3"; } @@ -1189,6 +1114,14 @@ Internet-Draft TE Common YANG Types September 2024 } typedef te-admin-status { + + + +Busi, et al. Expires 9 May 2025 [Page 20] + +Internet-Draft TE Common YANG Types November 2024 + + type te-common-status; description "Defines a type representing the administrative status of @@ -1226,14 +1159,6 @@ Internet-Draft TE Common YANG Types September 2024 enum normal { description "Both the recovery span and the working span are fully - - - -Busi, et al. Expires 31 March 2025 [Page 22] - -Internet-Draft TE Common YANG Types September 2024 - - allocated and active, data traffic is being transported over (or selected from) the working span, and no trigger events are reported."; @@ -1245,6 +1170,14 @@ Internet-Draft TE Common YANG Types September 2024 enum recovery-succeeded { description "The recovery action has succeeded. The working span has + + + +Busi, et al. Expires 9 May 2025 [Page 21] + +Internet-Draft TE Common YANG Types November 2024 + + reported a failure/degrade condition, and the user traffic is being transported (or selected) on the recovery span."; } @@ -1282,25 +1215,25 @@ Internet-Draft TE Common YANG Types September 2024 the Wait-to-Restore (WTR) timer."; } } - - - -Busi, et al. Expires 31 March 2025 [Page 23] - -Internet-Draft TE Common YANG Types September 2024 - - description "Defines the status of a recovery action."; reference - "RFC 4427: Recovery (Protection and Restoration) Terminology + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching - (GMPLS) - RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection"; + (GMPLS)"; } typedef te-template-name { type string { + + + +Busi, et al. Expires 9 May 2025 [Page 22] + +Internet-Draft TE Common YANG Types November 2024 + + pattern '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*'; } description @@ -1338,14 +1271,6 @@ Internet-Draft TE Common YANG Types September 2024 } type string { pattern '([a-zA-Z0-9\-_.]+:)*' - - - -Busi, et al. Expires 31 March 2025 [Page 24] - -Internet-Draft TE Common YANG Types September 2024 - - + '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*'; } } @@ -1357,7 +1282,15 @@ Internet-Draft TE Common YANG Types September 2024 defined in the 'ietf-network' module in RFC 8345, to help the user better understand the topology before further inquiry is made."; - reference + + + +Busi, et al. Expires 9 May 2025 [Page 23] + +Internet-Draft TE Common YANG Types November 2024 + + + reference "RFC 8345: A YANG Data Model for Network Topologies"; } @@ -1379,9 +1312,6 @@ Internet-Draft TE Common YANG Types September 2024 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 { @@ -1394,14 +1324,6 @@ Internet-Draft TE Common YANG Types September 2024 } enum primary-reverse-path { description - - - -Busi, et al. Expires 31 March 2025 [Page 25] - -Internet-Draft TE Common YANG Types September 2024 - - "Indicates that the TE path is a primary reverse path."; } enum secondary-reverse-path { @@ -1417,6 +1339,13 @@ Internet-Draft TE Common YANG Types September 2024 /* TE features */ + + +Busi, et al. Expires 9 May 2025 [Page 24] + +Internet-Draft TE Common YANG Types November 2024 + + feature p2mp-te { description "Indicates support for Point-to-Multipoint TE (P2MP-TE)."; @@ -1450,14 +1379,6 @@ Internet-Draft TE Common YANG Types September 2024 feature named-extended-admin-groups { description "Indicates support for named extended administrative groups."; - - - -Busi, et al. Expires 31 March 2025 [Page 26] - -Internet-Draft TE Common YANG Types September 2024 - - } feature named-srlg-groups { @@ -1473,6 +1394,14 @@ Internet-Draft TE Common YANG Types September 2024 feature path-optimization-metric { description "Indicates support for path optimization metrics."; + + + +Busi, et al. Expires 9 May 2025 [Page 25] + +Internet-Draft TE Common YANG Types November 2024 + + } feature path-optimization-objective-function { @@ -1484,9 +1413,6 @@ Internet-Draft TE Common YANG Types September 2024 * 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 "Base identity for LSP provisioning errors."; @@ -1497,706 +1423,685 @@ Internet-Draft TE Common YANG Types September 2024 "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 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"; + } -Busi, et al. Expires 31 March 2025 [Page 27] +Busi, et al. Expires 9 May 2025 [Page 26] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - 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 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 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 node-protection-desired { + base session-attributes-flags; + description + "Requests FRR node protection on LSRs, if present."; + reference + "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP + Tunnels"; + } - 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 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 node-protection-desired { - base session-attributes-flags; - description - "Requests FRR node protection on LSRs, if present."; - reference - "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; - } + 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 path-reevaluation-request { - base session-attributes-flags; + identity lsp-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)"; + "Base identity for LSP attributes flags."; } - identity soft-preemption-desired { + identity end-to-end-rerouting-desired { + base lsp-attributes-flags; + description + "Indicates end-to-end rerouting behavior for an LSP -Busi, et al. Expires 31 March 2025 [Page 28] +Busi, et al. Expires 9 May 2025 [Page 27] -Internet-Draft TE Common YANG Types September 2024 - - - base session-attributes-flags; - description - "Soft preemption of LSP resources is desired."; - reference - "RFC 5712: MPLS Traffic Engineering Soft Preemption"; - } +Internet-Draft TE Common YANG Types November 2024 - 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)"; - } + 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; + 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 boundary-rerouting-desired { - base lsp-attributes-flags; - 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)"; -Busi, et al. Expires 31 March 2025 [Page 29] +Busi, et al. Expires 9 May 2025 [Page 28] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - } + } - 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 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 { + 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 contiguous-lsp-desired { - 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 lsp-stitching-desired { - base lsp-attributes-flags; - description - "Indicates that LSP stitching is desired."; - reference - "RFC 5150: Label Switched Path Stitching with Generalized + 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)"; -Busi, et al. Expires 31 March 2025 [Page 30] +Busi, et al. Expires 9 May 2025 [Page 29] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - 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 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; + 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 oob-mapping-flag { - base lsp-attributes-flags; - 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 entropy-label-capability { - base lsp-attributes-flags; - description - "Indicates entropy label capability."; - reference - "RFC 6790: The Use of Entropy Labels in MPLS Forwarding + 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"; -Busi, et al. Expires 31 March 2025 [Page 31] +Busi, et al. Expires 9 May 2025 [Page 30] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - 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 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 + Link Group (SRLG) Information"; + } - 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 - 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 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 -Busi, et al. Expires 31 March 2025 [Page 32] +Busi, et al. Expires 9 May 2025 [Page 31] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - 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"; - } + "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-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; - description - "Extra-Traffic protected link type."; - reference - "RFC 4427: Recovery (Protection and Restoration) Terminology - for Generalized Multi-Protocol Label Switching - (GMPLS)"; - } + identity link-protection-extra-traffic { + base link-protection-type; + description + "Extra-Traffic 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-shared { - base link-protection-type; - description - "Shared protected link type."; - reference + 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"; -Busi, et al. Expires 31 March 2025 [Page 33] +Busi, et al. Expires 9 May 2025 [Page 32] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - "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-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 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; - 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-recovery { + base association-type; + 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; -Busi, et al. Expires 31 March 2025 [Page 34] - -Internet-Draft TE Common YANG Types September 2024 - 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"; - } +Busi, et al. Expires 9 May 2025 [Page 33] + +Internet-Draft TE Common YANG Types November 2024 - 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)"; - } + 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)"; + } + + 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 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; + identity objective-function-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"; + "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)"; + } + -Busi, et al. Expires 31 March 2025 [Page 35] +Busi, et al. Expires 9 May 2025 [Page 34] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - // 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-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-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-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)"; + } - 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-minimize-agg-bandwidth-consumption { + base objective-function-type; + status obsolete; + description + "Objective function for minimizing aggregate bandwidth + consumption. - 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)"; - } + 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-agg-bandwidth-consumption - // below has been obsoleted in this module revision - // 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. + 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 + This identity has been obsoleted: the + 'svec-of-minimize-load-most-loaded-link' identity SHOULD + be used instead."; + reference -Busi, et al. Expires 31 March 2025 [Page 36] +Busi, et al. Expires 9 May 2025 [Page 35] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - '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)"; - } + "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. + 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 - Computation Element Communication Protocol (PCEP)"; - } + 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 + 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 + 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"; + } + + 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 -Busi, et al. Expires 31 March 2025 [Page 37] +Busi, et al. Expires 9 May 2025 [Page 36] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - // 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"; - } + RFC 4657: Path Computation Element (PCE) Communication + Protocol Generic Requirements"; + } - // 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"; - } + identity path-explicitly-defined { + 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"; + } - // 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 { - base path-computation-method; + identity lsp-metric-type { 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"; + "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"; + } -Busi, et al. Expires 31 March 2025 [Page 38] - -Internet-Draft TE Common YANG Types September 2024 + 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."; - 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"; - } +Busi, et al. Expires 9 May 2025 [Page 37] + +Internet-Draft TE Common YANG Types November 2024 - 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"; - } + reference + "RFC 4657: Path Computation Element (PCE) Communication + Protocol Generic Requirements"; + } 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"; - - - -Busi, et al. Expires 31 March 2025 [Page 39] - -Internet-Draft TE Common YANG Types September 2024 - - - } + 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 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 @@ -2204,246 +2109,236 @@ Internet-Draft TE Common YANG Types September 2024 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."; - } - - identity te-action-result { - description - "Base identity from which specific TE action results - 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 te-action-success { - base te-action-result; - description + identity tunnel-action-reoptimize { + base tunnel-action-type; + description + "TE tunnel action that reoptimizes the placement of the + tunnel LSP(s)."; + } -Busi, et al. Expires 31 March 2025 [Page 40] +Busi, et al. Expires 9 May 2025 [Page 38] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - "TE action was successful."; - } + identity tunnel-action-switchpath { + base tunnel-action-type; + description + "TE tunnel action that switches the tunnel's LSP to use the + specified path."; + } - identity te-action-fail { - base te-action-result; + identity te-action-result { description - "TE action failed."; + "Base identity from which specific TE action results + are derived."; } - identity tunnel-action-inprogress { - base te-action-result; - description - "TE action is in progress."; - } + 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."; - } + identity tunnel-admin-state-up { + base tunnel-admin-state-type; + description + "Tunnel's administrative state is up."; + } - // 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."; - } + identity tunnel-admin-state-down { + base tunnel-admin-state-type; + description + "Tunnel's administrative state is down."; + } - identity tunnel-state-type { - description - "Base identity for TE tunnel states."; - } -Busi, et al. Expires 31 March 2025 [Page 41] +Busi, et al. Expires 9 May 2025 [Page 39] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - identity tunnel-state-up { - base tunnel-state-type; - description - "Tunnel's state is up."; - } + 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."; + } - identity tunnel-state-down { - base tunnel-state-type; + identity tunnel-state-type { description - "Tunnel's state is down."; + "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-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-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-path-computation-failed { + base lsp-state-type; + description + "State path computation failed."; + } - identity lsp-state-setting-up { - 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 { +Busi, et al. Expires 9 May 2025 [Page 40] + +Internet-Draft TE Common YANG Types November 2024 + identity lsp-state-setting-up { + base lsp-state-type; + description + "State is being set up."; + } -Busi, et al. Expires 31 March 2025 [Page 42] - -Internet-Draft TE Common YANG Types September 2024 + 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."; + } - base lsp-state-type; - description - "State setup failed."; - } + identity lsp-state-up { + base lsp-state-type; + description + "State is up."; + } - identity lsp-state-up { - base lsp-state-type; + 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 - "State is up."; + "Base identity for TE path invalidation action types."; } - 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"; - } + 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, - 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 { +Busi, et al. Expires 9 May 2025 [Page 41] + +Internet-Draft TE Common YANG Types November 2024 -Busi, et al. Expires 31 March 2025 [Page 43] - -Internet-Draft TE Common YANG Types September 2024 + Section 2.5"; + } + 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-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 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; description @@ -2451,49 +2346,49 @@ Internet-Draft TE Common YANG Types September 2024 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 { - -Busi, et al. Expires 31 March 2025 [Page 44] +Busi, et al. Expires 9 May 2025 [Page 42] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - 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)"; - } + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; + } - 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-preconfigured { + base restoration-scheme-type; + description + "Restoration LSP is preconfigured prior to the failure."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; + } - 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 restoration-scheme-precomputed { + base restoration-scheme-type; + description + "Restoration LSP is precomputed prior to the failure."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; + } + + identity restoration-scheme-presignaled { + base restoration-scheme-type; + description + "Restoration LSP is presignaled prior to the failure."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; + } identity lsp-protection-type { description @@ -2504,247 +2399,259 @@ Internet-Draft TE Common YANG Types September 2024 Recovery"; } - identity lsp-protection-unprotected { - base lsp-protection-type; - description - "'Unprotected' 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-unprotected { + base lsp-protection-type; + description -Busi, et al. Expires 31 March 2025 [Page 45] +Busi, et al. Expires 9 May 2025 [Page 43] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - // 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. + "'Unprotected' LSP protection type."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; + } - 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-reroute-extra { + base lsp-protection-type; + status obsolete; + description + "'(Full) Rerouting' LSP protection type. - // 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"; + } - 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-reroute { + base lsp-protection-type; + status obsolete; + description + "'Rerouting without Extra-Traffic' LSP protection type. - 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"; - } + 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-1 { - base lsp-protection-type; + 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"; + } + identity lsp-protection-1-for-1 { -Busi, et al. Expires 31 March 2025 [Page 46] + +Busi, et al. Expires 9 May 2025 [Page 44] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - 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"; - } + 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-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-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-extra-traffic { + base lsp-protection-type; + description + "Extra-Traffic 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-state { description "Base identity of protection states for reporting purposes."; } - identity normal { - base lsp-protection-state; - description - "Normal state."; - } + identity normal { + base lsp-protection-state; + description + "Normal state."; -Busi, et al. Expires 31 March 2025 [Page 47] +Busi, et al. Expires 9 May 2025 [Page 45] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - identity signal-fail-of-protection { - 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)"; - } + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 signal-fail-of-protection { + 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 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 lockout-of-protection { + base lsp-protection-state; + description + "A Loss of Protection (LoP) command is active."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 forced-switch { + base lsp-protection-state; + description + "A forced switchover command is active."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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."; + identity signal-fail { + base lsp-protection-state; + description + "There is a signal fail condition on either the working path + or the protection path."; + reference -Busi, et al. Expires 31 March 2025 [Page 48] +Busi, et al. Expires 9 May 2025 [Page 46] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - reference - "RFC 4427: Recovery (Protection and Restoration) Terminology - for Generalized Multi-Protocol Label Switching - (GMPLS)"; - } - 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)"; - } + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 signal-degrade { + base lsp-protection-state; + description + "There is a signal degrade condition on either the working + path or the protection path."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 manual-switch { + base lsp-protection-state; + description + "A manual switchover command is active."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 wait-to-restore { + base lsp-protection-state; + description + "A Wait-to-Restore (WTR) timer is running."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + RFC 4427: Recovery (Protection and Restoration) Terminology -Busi, et al. Expires 31 March 2025 [Page 49] +Busi, et al. Expires 9 May 2025 [Page 47] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 + + 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 7271: MPLS Transport Profile (MPLS-TP) Linear Protection + to Match the Operational Expectations of + Synchronous Digital Hierarchy, Optical Transport + Network, and Ethernet Transport Network Operators + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } identity protection-external-commands { description @@ -2752,134 +2659,169 @@ Internet-Draft TE Common YANG Types September 2024 used for troubleshooting purposes are derived."; } - identity action-freeze { - base protection-external-commands; - description - "A temporary configuration action initiated by an operator - 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 action-freeze { + base protection-external-commands; + description + "A temporary configuration action initiated by an operator + command that prevents any switchover action from being taken + and, as such, freezes the current state."; + reference + "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection + to Match the Operational Expectations of + Synchronous Digital Hierarchy, Optical Transport + Network, and Ethernet Transport Network Operators + 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 clear-freeze { + base protection-external-commands; + description + "An action that clears the active freeze state."; + reference + "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection + to Match the Operational Expectations of - 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 +Busi, et al. Expires 9 May 2025 [Page 48] + +Internet-Draft TE Common YANG Types November 2024 -Busi, et al. Expires 31 March 2025 [Page 50] - -Internet-Draft TE Common YANG Types September 2024 + Synchronous Digital Hierarchy, Optical Transport + Network, and Ethernet Transport Network Operators + 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 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - (GMPLS)"; - } + identity clear-lockout-of-normal { + base protection-external-commands; + description + "An action that clears the active lockout of the + normal state."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + 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)"; - } + 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 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + RFC 4427: Recovery (Protection and Restoration) Terminology - 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 { +Busi, et al. Expires 9 May 2025 [Page 49] + +Internet-Draft TE Common YANG Types November 2024 + + + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } + + 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 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + 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 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } + + 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 + "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection -Busi, et al. Expires 31 March 2025 [Page 51] +Busi, et al. Expires 9 May 2025 [Page 50] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - 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: Generic protection switching - Linear trail and - subnetwork protection - Edition 4.0 (05/2014)"; - } + to Match the Operational Expectations of + Synchronous Digital Hierarchy, Optical Transport + Network, and Ethernet Transport Network Operators + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - 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 - "RFC 4427: Recovery (Protection and Restoration) Terminology - for Generalized Multi-Protocol Label Switching - (GMPLS)"; - } + identity clear { + base protection-external-commands; + description + "An action that clears the active near-end lockout of a + protection, forced switchover, manual switchover, + Wait-to-Restore (WTR) state, or exercise command."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } identity switching-capabilities { description @@ -2889,94 +2831,96 @@ Internet-Draft TE Common YANG Types September 2024 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-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-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"; + } -Busi, et al. Expires 31 March 2025 [Page 52] + +Busi, et al. Expires 9 May 2025 [Page 51] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - 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-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"; - } + identity switching-tdm { + base switching-capabilities; + description + "Time-Division-Multiplex Capable (TDM)."; + reference + "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) + Signaling Functional Description"; + } - 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-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-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-lsc { + base switching-capabilities; + description + "Lambda-Switch Capable (LSC)."; + reference + "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) + Signaling Functional Description"; + } - identity switching-fsc { + identity switching-fsc { -Busi, et al. Expires 31 March 2025 [Page 53] +Busi, et al. Expires 9 May 2025 [Page 52] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - base switching-capabilities; - description - "Fiber-Switch Capable (FSC)."; - reference - "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) - Signaling Functional Description"; - } + 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 @@ -2986,123 +2930,123 @@ Internet-Draft TE Common YANG Types September 2024 Signaling Functional Description"; } - identity lsp-encoding-packet { - base lsp-encoding-types; - description - "Packet LSP encoding."; - reference - "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) - Signaling Functional Description"; - } + identity lsp-encoding-packet { + base lsp-encoding-types; + description + "Packet LSP encoding."; + 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-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-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 + identity lsp-encoding-sdh { + base lsp-encoding-types; + description + "SDH ITU-T G.707 / SONET ANSI T1.105 LSP encoding."; + reference -Busi, et al. Expires 31 March 2025 [Page 54] +Busi, et al. Expires 9 May 2025 [Page 53] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) - Signaling Functional Description"; - } + "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-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"; - } + 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"; + } - 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 { + 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-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-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"; -Busi, et al. Expires 31 March 2025 [Page 55] +Busi, et al. Expires 9 May 2025 [Page 54] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - } + } - 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-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"; - } + 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"; + } identity path-signaling-type { description @@ -3110,32 +3054,32 @@ Internet-Draft TE Common YANG Types September 2024 are derived."; } - identity path-setup-static { - base path-signaling-type; - description - "Static LSP provisioning path setup."; - } + 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-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-setup-sr { + base path-signaling-type; + description + "Segment-routing path setup."; + } -Busi, et al. Expires 31 March 2025 [Page 56] +Busi, et al. Expires 9 May 2025 [Page 55] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 identity path-scope-type { @@ -3144,71 +3088,65 @@ Internet-Draft TE Common YANG Types September 2024 derived."; } - identity path-scope-segment { - base path-scope-type; - description - "Path scope segment."; - reference - "RFC 4873: GMPLS Segment Recovery"; - } + 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"; - } + identity path-scope-end-to-end { + base path-scope-type; + description + "Path scope end to end."; + reference + "RFC 4873: GMPLS Segment Recovery"; + } identity route-usage-type { description "Base identity for route usage."; } - identity route-include-object { - base route-usage-type; - description - "'Include route' object."; - } + 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-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 + identity route-exclude-srlg { + base route-usage-type; + description + "Excludes SRLGs."; + reference + "RFC 4874: Exclude Routes - Extension to Resource ReserVation -Busi, et al. Expires 31 March 2025 [Page 57] +Busi, et al. Expires 9 May 2025 [Page 56] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - Protocol-Traffic Engineering (RSVP-TE)"; - } + 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 @@ -3220,10 +3158,6 @@ Internet-Draft TE Common YANG Types September 2024 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 @@ -3242,14 +3176,6 @@ Internet-Draft TE Common YANG Types September 2024 } identity link-metric-igp { - - - -Busi, et al. Expires 31 March 2025 [Page 58] - -Internet-Draft TE Common YANG Types September 2024 - - base link-metric-type; description "Interior Gateway Protocol (IGP) Link Metric."; @@ -3260,6 +3186,14 @@ Internet-Draft TE Common YANG Types September 2024 } identity link-metric-delay-average { + + + +Busi, et al. Expires 9 May 2025 [Page 57] + +Internet-Draft TE Common YANG Types November 2024 + + base link-metric-type; description "Unidirectional Link Delay, measured in units of @@ -3298,14 +3232,6 @@ Internet-Draft TE Common YANG Types September 2024 identity link-metric-residual-bandwidth { base link-metric-type; description - - - -Busi, et al. Expires 31 March 2025 [Page 59] - -Internet-Draft TE Common YANG Types September 2024 - - "Unidirectional Residual Bandwidth, measured in units of bytes per second. @@ -3316,12 +3242,16 @@ Internet-Draft TE Common YANG Types September 2024 Extensions, Section 4.5 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.5"; + + + +Busi, et al. Expires 9 May 2025 [Page 58] + +Internet-Draft TE Common YANG Types November 2024 + + } - // 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; @@ -3329,10 +3259,6 @@ Internet-Draft TE Common YANG Types September 2024 "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 @@ -3342,10 +3268,6 @@ Internet-Draft TE Common YANG Types September 2024 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 @@ -3355,17 +3277,6 @@ Internet-Draft TE Common YANG Types September 2024 Protocol (PCEP), section 7.8"; } - - -Busi, et al. Expires 31 March 2025 [Page 60] - -Internet-Draft TE Common YANG Types September 2024 - - - // 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 @@ -3375,10 +3286,6 @@ Internet-Draft TE Common YANG Types September 2024 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 @@ -3391,34 +3298,26 @@ Internet-Draft TE Common YANG Types September 2024 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 - "RFC YYYY: Carrying SR-Algorithm information in PCE-based - Networks, Section 3.5.1"; - } - // RFC Editor: replace YYYY with actual RFC number assigned to - // [I-D.ietf-pce-sid-algo] and remove this note - - // CHANGE NOTE: The description and the reference of the - // path-metric-residual-bandwidth identity have been updated - // in this module revision -Busi, et al. Expires 31 March 2025 [Page 61] +Busi, et al. Expires 9 May 2025 [Page 59] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - // 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, + draft-ietf-pce-sid-algo-14, + Sections 3.5.1 and 3.5.2"; + } + identity path-metric-residual-bandwidth { base path-metric-type; description @@ -3434,9 +3333,6 @@ Internet-Draft TE Common YANG Types September 2024 (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 @@ -3444,9 +3340,6 @@ Internet-Draft TE Common YANG Types September 2024 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 @@ -3459,85 +3352,82 @@ Internet-Draft TE Common YANG Types September 2024 "Base identity for the path tiebreaker type."; } - identity path-tiebreaker-minfill { - base path-tiebreaker-type; - description - "Min-Fill LSP path placement: selects the path with the most - available bandwidth (load balance LSPs over more links)."; - } + identity path-tiebreaker-minfill { + base path-tiebreaker-type; - -Busi, et al. Expires 31 March 2025 [Page 62] +Busi, et al. Expires 9 May 2025 [Page 60] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - identity path-tiebreaker-maxfill { - base path-tiebreaker-type; - description - "Max-Fill LSP path placement: selects the path with the least - available bandwidth (packing more LSPs over few links)."; - } + description + "Min-Fill LSP path placement: selects the path with the most + available bandwidth (load balance LSPs over more links)."; + } - identity path-tiebreaker-random { - base path-tiebreaker-type; - description - "Random LSP path placement."; - } + identity path-tiebreaker-maxfill { + base path-tiebreaker-type; + description + "Max-Fill LSP path placement: selects the path with the least + available bandwidth (packing more LSPs over few links)."; + } + + 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"; + "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels + RFC 2702: Requirements for Traffic Engineering Over MPLS"; } - identity resource-aff-include-all { - base resource-affinities-type; - description - "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-all { + base resource-affinities-type; + description + "The set of attribute filters associated with a + tunnel, all of which must be present for a link + to be acceptable."; + reference + "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels + RFC 2702: Requirements for Traffic Engineering Over MPLS"; + } - 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-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 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels + RFC 2702: Requirements for Traffic Engineering Over MPLS"; + } - 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 -Busi, et al. Expires 31 March 2025 [Page 63] +Busi, et al. Expires 9 May 2025 [Page 61] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - "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 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels + RFC 2702: Requirements for Traffic Engineering Over MPLS"; + } - // 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."; @@ -3546,71 +3436,68 @@ Internet-Draft TE Common YANG Types September 2024 Engineering"; } - identity not-optimized { - base te-optimization-criterion; - description - "Optimization is not applied."; - } + identity not-optimized { + base te-optimization-criterion; + description + "Optimization is not applied."; + } - identity cost { - base te-optimization-criterion; - description - "Optimized on cost."; - reference - "RFC 5541: Encoding of Objective Functions in the Path - Computation Element Communication Protocol (PCEP)"; - } + identity cost { + 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 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 - -Busi, et al. Expires 31 March 2025 [Page 64] +Busi, et al. Expires 9 May 2025 [Page 62] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - "Ignores SRLGs in the 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-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-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."; - } + 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 - // 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."; @@ -3634,15 +3521,15 @@ Internet-Draft TE Common YANG Types September 2024 } identity path-computation-error-no-dependent-server { + base path-computation-error-reason; -Busi, et al. Expires 31 March 2025 [Page 65] +Busi, et al. Expires 9 May 2025 [Page 63] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - base path-computation-error-reason; description "Path computation has failed because one or more dependent path computation servers are unavailable. @@ -3690,15 +3577,15 @@ Internet-Draft TE Common YANG Types September 2024 It corresponds to bit 19 of the Flags field of the NO-PATH-VECTOR TLV."; + reference -Busi, et al. Expires 31 March 2025 [Page 66] +Busi, et al. Expires 9 May 2025 [Page 64] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture @@ -3749,9 +3636,10 @@ Internet-Draft TE Common YANG Types September 2024 -Busi, et al. Expires 31 March 2025 [Page 67] + +Busi, et al. Expires 9 May 2025 [Page 65] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 It corresponds to bit 22 of the Flags field of the @@ -3805,9 +3693,9 @@ Internet-Draft TE Common YANG Types September 2024 -Busi, et al. Expires 31 March 2025 [Page 68] +Busi, et al. Expires 9 May 2025 [Page 66] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 description @@ -3861,9 +3749,9 @@ Internet-Draft TE Common YANG Types September 2024 -Busi, et al. Expires 31 March 2025 [Page 69] +Busi, et al. Expires 9 May 2025 [Page 67] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 } @@ -3913,19 +3801,15 @@ Internet-Draft TE Common YANG Types September 2024 /pcep.xhtml#no-path-vector-tlv"; } - // CHANGE NOTE: The base identity protocol-origin-type and + identity protocol-origin-type { -Busi, et al. Expires 31 March 2025 [Page 70] +Busi, et al. Expires 9 May 2025 [Page 68] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 - // 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."; } @@ -3955,10 +3839,6 @@ Internet-Draft TE Common YANG Types September 2024 "RFC 9012: The BGP Tunnel Encapsulation Attribute"; } - // 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."; @@ -3970,14 +3850,6 @@ Internet-Draft TE Common YANG Types September 2024 identity svec-of-minimize-agg-bandwidth-consumption { base svec-objective-function-type; description - - - -Busi, et al. Expires 31 March 2025 [Page 71] - -Internet-Draft TE Common YANG Types September 2024 - - "Objective function for minimizing aggregate bandwidth consumption (MBC)."; reference @@ -3986,6 +3858,14 @@ Internet-Draft TE Common YANG Types September 2024 (PCEP)"; } + + + +Busi, et al. Expires 9 May 2025 [Page 69] + +Internet-Draft TE Common YANG Types November 2024 + + identity svec-of-minimize-load-most-loaded-link { base svec-objective-function-type; description @@ -4026,14 +3906,6 @@ Internet-Draft TE Common YANG Types September 2024 links (MSL)."; reference "RFC 8685: Path Computation Element Communication Protocol - - - -Busi, et al. Expires 31 March 2025 [Page 72] - -Internet-Draft TE Common YANG Types September 2024 - - (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } @@ -4042,6 +3914,14 @@ Internet-Draft TE Common YANG Types September 2024 base svec-objective-function-type; description "Objective function for minimizing the number of shared + + + +Busi, et al. Expires 9 May 2025 [Page 70] + +Internet-Draft TE Common YANG Types November 2024 + + Shared Risk Link Groups (SRLG) (MSS)."; reference "RFC 8685: Path Computation Element Communication Protocol @@ -4060,10 +3940,6 @@ Internet-Draft TE Common YANG Types September 2024 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."; @@ -4082,14 +3958,6 @@ Internet-Draft TE Common YANG Types September 2024 (PCEP)"; } - - - -Busi, et al. Expires 31 March 2025 [Page 73] - -Internet-Draft TE Common YANG Types September 2024 - - identity svec-metric-cumulative-igp { base svec-metric-type; description @@ -4102,6 +3970,14 @@ Internet-Draft TE Common YANG Types September 2024 identity svec-metric-cumulative-hop { base svec-metric-type; + + + +Busi, et al. Expires 9 May 2025 [Page 71] + +Internet-Draft TE Common YANG Types November 2024 + + description "Cumulative Hop path metric."; reference @@ -4138,14 +4014,6 @@ Internet-Draft TE Common YANG Types September 2024 description "This grouping defines the generic TE bandwidth. For some known data-plane technologies, specific modeling - - - -Busi, et al. Expires 31 March 2025 [Page 74] - -Internet-Draft TE Common YANG Types September 2024 - - structures are specified. The string-encoded 'te-bandwidth' type is used for unspecified technologies. The modeling structure can be augmented later for other @@ -4158,6 +4026,14 @@ Internet-Draft TE Common YANG Types September 2024 default "generic"; description "Data-plane technology type."; + + + +Busi, et al. Expires 9 May 2025 [Page 72] + +Internet-Draft TE Common YANG Types November 2024 + + case generic { leaf generic { type te-bandwidth; @@ -4194,14 +4070,6 @@ Internet-Draft TE Common YANG Types September 2024 "TE label specified in a generic format."; } } - - - -Busi, et al. Expires 31 March 2025 [Page 75] - -Internet-Draft TE Common YANG Types September 2024 - - } leaf direction { type te-label-direction; @@ -4214,6 +4082,14 @@ Internet-Draft TE Common YANG Types September 2024 grouping te-topology-identifier { description + + + +Busi, et al. Expires 9 May 2025 [Page 73] + +Internet-Draft TE Common YANG Types November 2024 + + "Augmentation for a TE topology."; container te-topology-identifier { description @@ -4250,14 +4126,6 @@ Internet-Draft TE Common YANG Types September 2024 **/ grouping performance-metrics-one-way-delay-loss { - - - -Busi, et al. Expires 31 March 2025 [Page 76] - -Internet-Draft TE Common YANG Types September 2024 - - description "Performance Metrics (PM) information in real time that can be applicable to links or connections. PM defined in this @@ -4265,11 +4133,19 @@ Internet-Draft TE Common YANG Types September 2024 PM."; reference "RFC 7471: OSPF Traffic Engineering (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"; + Extensions"; leaf one-way-delay { + + + +Busi, et al. Expires 9 May 2025 [Page 74] + +Internet-Draft TE Common YANG Types November 2024 + + type uint32 { range "0..16777215"; } @@ -4290,10 +4166,10 @@ Internet-Draft TE Common YANG Types September 2024 generic TE PM as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (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"; + Extensions"; leaf two-way-delay { type uint32 { range "0..16777215"; @@ -4306,14 +4182,6 @@ Internet-Draft TE Common YANG Types September 2024 description "Two-way delay normality."; } - - - -Busi, et al. Expires 31 March 2025 [Page 77] - -Internet-Draft TE Common YANG Types September 2024 - - } grouping performance-metrics-one-way-bandwidth { @@ -4323,10 +4191,18 @@ Internet-Draft TE Common YANG Types September 2024 as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (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"; + + + +Busi, et al. Expires 9 May 2025 [Page 75] + +Internet-Draft TE Common YANG Types November 2024 + + + Extensions"; leaf one-way-residual-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; @@ -4362,14 +4238,6 @@ Internet-Draft TE Common YANG Types September 2024 description "Available bandwidth normality."; } - - - -Busi, et al. Expires 31 March 2025 [Page 78] - -Internet-Draft TE Common YANG Types September 2024 - - leaf one-way-utilized-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; @@ -4382,6 +4250,14 @@ Internet-Draft TE Common YANG Types September 2024 } leaf one-way-utilized-bandwidth-normality { type te-types:performance-metrics-normality; + + + +Busi, et al. Expires 9 May 2025 [Page 76] + +Internet-Draft TE Common YANG Types November 2024 + + default "normal"; description "Bandwidth utilization normality."; @@ -4418,14 +4294,6 @@ Internet-Draft TE Common YANG Types September 2024 description "Available bandwidth that is defined to be residual bandwidth minus the measured bandwidth used for the - - - -Busi, et al. Expires 31 March 2025 [Page 79] - -Internet-Draft TE Common YANG Types September 2024 - - 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."; @@ -4438,6 +4306,14 @@ Internet-Draft TE Common YANG Types September 2024 "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 + + + +Busi, et al. Expires 9 May 2025 [Page 77] + +Internet-Draft TE Common YANG Types November 2024 + + be the sum of the component link bandwidth utilizations."; } } @@ -4471,18 +4347,10 @@ Internet-Draft TE Common YANG Types September 2024 "One-way link performance information in real time."; reference "RFC 7471: OSPF Traffic Engineering (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 - - - -Busi, et al. Expires 31 March 2025 [Page 80] - -Internet-Draft TE Common YANG Types September 2024 - - - RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; + Extensions"; uses performance-metrics-one-way-delay-loss; uses performance-metrics-one-way-bandwidth; } @@ -4494,6 +4362,14 @@ Internet-Draft TE Common YANG Types September 2024 Networks"; uses performance-metrics-two-way-delay-loss; } + + + +Busi, et al. Expires 9 May 2025 [Page 78] + +Internet-Draft TE Common YANG Types November 2024 + + } grouping performance-metrics-throttle-container { @@ -4511,10 +4387,10 @@ Internet-Draft TE Common YANG Types September 2024 "Link performance information in real time."; reference "RFC 7471: OSPF Traffic Engineering (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"; + Extensions"; leaf one-way-delay-offset { type uint32 { range "0..16777215"; @@ -4530,14 +4406,6 @@ Internet-Draft TE Common YANG Types September 2024 "Interval, in seconds, to measure the extended metric values."; } - - - -Busi, et al. Expires 31 March 2025 [Page 81] - -Internet-Draft TE Common YANG Types September 2024 - - leaf advertisement-interval { type uint32; default "0"; @@ -4550,6 +4418,14 @@ Internet-Draft TE Common YANG Types September 2024 range "1..max"; } default "120"; + + + +Busi, et al. Expires 9 May 2025 [Page 79] + +Internet-Draft TE Common YANG Types November 2024 + + description "Interval, in seconds, to suppress advertisement of the extended metric values."; @@ -4586,21 +4462,10 @@ Internet-Draft TE Common YANG Types September 2024 } } - - - -Busi, et al. Expires 31 March 2025 [Page 82] - -Internet-Draft TE Common YANG Types September 2024 - - /** * 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."; @@ -4609,6 +4474,14 @@ Internet-Draft TE Common YANG Types September 2024 "The explicit route entry type."; case numbered-node-hop { container numbered-node-hop { + + + +Busi, et al. Expires 9 May 2025 [Page 80] + +Internet-Draft TE Common YANG Types November 2024 + + must "node-id-uri or node-id" { description "At least one node identifier MUST be present."; @@ -4642,14 +4515,6 @@ Internet-Draft TE Common YANG Types September 2024 case numbered-link-hop { container numbered-link-hop { leaf link-tp-id { - - - -Busi, et al. Expires 31 March 2025 [Page 83] - -Internet-Draft TE Common YANG Types September 2024 - - type te-tp-id; mandatory true; description @@ -4665,6 +4530,14 @@ Internet-Draft TE Common YANG Types September 2024 type te-link-direction; default "outgoing"; description + + + +Busi, et al. Expires 9 May 2025 [Page 81] + +Internet-Draft TE Common YANG Types November 2024 + + "Link route object direction."; } description @@ -4696,16 +4569,8 @@ Internet-Draft TE Common YANG Types September 2024 "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 { - - - -Busi, et al. Expires 31 March 2025 [Page 84] - -Internet-Draft TE Common YANG Types September 2024 - - + } + leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; @@ -4721,6 +4586,14 @@ Internet-Draft TE Common YANG Types September 2024 description "Strict or loose hop."; } + + + +Busi, et al. Expires 9 May 2025 [Page 82] + +Internet-Draft TE Common YANG Types November 2024 + + leaf direction { type te-link-direction; default "outgoing"; @@ -4754,14 +4627,6 @@ Internet-Draft TE Common YANG Types September 2024 description "AS explicit route hop."; } - - - -Busi, et al. Expires 31 March 2025 [Page 85] - -Internet-Draft TE Common YANG Types September 2024 - - } case label { container label-hop { @@ -4775,11 +4640,16 @@ Internet-Draft TE Common YANG Types September 2024 } } - // 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 + + + +Busi, et al. Expires 9 May 2025 [Page 83] + +Internet-Draft TE Common YANG Types November 2024 + + "The Record Route grouping."; leaf index { type uint32; @@ -4810,14 +4680,6 @@ Internet-Draft TE Common YANG Types September 2024 "The identifier of a node in the TE topology."; } leaf-list flags { - - - -Busi, et al. Expires 31 March 2025 [Page 86] - -Internet-Draft TE Common YANG Types September 2024 - - type path-attribute-flags; description "Path attributes flags."; @@ -4836,6 +4698,14 @@ Internet-Draft TE Common YANG Types September 2024 container numbered-link-hop { description "Numbered link route hop container."; + + + +Busi, et al. Expires 9 May 2025 [Page 84] + +Internet-Draft TE Common YANG Types November 2024 + + leaf link-tp-id { type te-tp-id; mandatory true; @@ -4866,14 +4736,6 @@ Internet-Draft TE Common YANG Types September 2024 Termination Point (LTP) identifier MUST be present."; } leaf link-tp-id-uri { - - - -Busi, et al. Expires 31 March 2025 [Page 87] - -Internet-Draft TE Common YANG Types September 2024 - - type nt:tp-id; description "Link Termination Point (LTP) identifier."; @@ -4892,6 +4754,14 @@ Internet-Draft TE Common YANG Types September 2024 } leaf node-id { type te-node-id; + + + +Busi, et al. Expires 9 May 2025 [Page 85] + +Internet-Draft TE Common YANG Types November 2024 + + description "The identifier of a node in the TE topology."; } @@ -4922,14 +4792,6 @@ Internet-Draft TE Common YANG Types September 2024 "Label route hop type."; uses te-label; leaf-list flags { - - - -Busi, et al. Expires 31 March 2025 [Page 88] - -Internet-Draft TE Common YANG Types September 2024 - - type path-attribute-flags; description "Path attributes flags."; @@ -4948,6 +4810,14 @@ Internet-Draft TE Common YANG Types September 2024 } grouping label-restriction-info { + + + +Busi, et al. Expires 9 May 2025 [Page 86] + +Internet-Draft TE Common YANG Types November 2024 + + description "Label set item information."; leaf restriction { @@ -4978,14 +4848,6 @@ Internet-Draft TE Common YANG Types September 2024 + " or " + "(not(te-label/direction) and" + " (../label-end/te-label/direction = 'forward'))" - - - -Busi, et al. Expires 31 March 2025 [Page 89] - -Internet-Draft TE Common YANG Types September 2024 - - + " or " + "(not(../label-end/te-label/direction) and" + " (te-label/direction = 'forward'))" { @@ -5004,6 +4866,14 @@ Internet-Draft TE Common YANG Types September 2024 + " or " + "(../label-start/te-label/direction = te-label/direction)" + " or " + + + +Busi, et al. Expires 9 May 2025 [Page 87] + +Internet-Draft TE Common YANG Types November 2024 + + + "(not(te-label/direction) and" + " (../label-start/te-label/direction = 'forward'))" + " or " @@ -5034,14 +4904,6 @@ Internet-Draft TE Common YANG Types September 2024 default "1"; description "Label range step."; - - - -Busi, et al. Expires 31 March 2025 [Page 90] - -Internet-Draft TE Common YANG Types September 2024 - - } } } @@ -5060,6 +4922,14 @@ Internet-Draft TE Common YANG Types September 2024 labels in the range are available. In case the restriction is 'exclusive', the bit-position is + + + +Busi, et al. Expires 9 May 2025 [Page 88] + +Internet-Draft TE Common YANG Types November 2024 + + set if the corresponding mapped label is not available. In this case, if the range-bitmap is not present, all the labels in the range are not available. @@ -5090,14 +4960,6 @@ Internet-Draft TE Common YANG Types September 2024 description "The label restrictions container."; list label-restriction { - - - -Busi, et al. Expires 31 March 2025 [Page 91] - -Internet-Draft TE Common YANG Types September 2024 - - key "index"; description "The absence of the label restrictions container implies @@ -5111,14 +4973,19 @@ Internet-Draft TE Common YANG Types September 2024 } } - // 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 { + + + +Busi, et al. Expires 9 May 2025 [Page 89] + +Internet-Draft TE Common YANG Types November 2024 + + base path-metric-optimization-type; } description @@ -5147,13 +5014,6 @@ Internet-Draft TE Common YANG Types September 2024 } } - - -Busi, et al. Expires 31 March 2025 [Page 92] - -Internet-Draft TE Common YANG Types September 2024 - - grouping common-constraints { description "Common constraints grouping that can be set on @@ -5174,6 +5034,14 @@ Internet-Draft TE Common YANG Types September 2024 "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"; + + + +Busi, et al. Expires 9 May 2025 [Page 90] + +Internet-Draft TE Common YANG Types November 2024 + + } leaf setup-priority { type uint8 { @@ -5202,20 +5070,9 @@ Internet-Draft TE Common YANG Types September 2024 default "te-types:path-setup-rsvp"; description "TE tunnel path signaling type."; - - - -Busi, et al. Expires 31 March 2025 [Page 93] - -Internet-Draft TE Common YANG Types September 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 @@ -5229,13 +5086,18 @@ Internet-Draft TE Common YANG Types September 2024 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."; + + + +Busi, et al. Expires 9 May 2025 [Page 91] + +Internet-Draft TE Common YANG Types November 2024 + + container explicit-route-objects { description "Container for the explicit route object lists."; @@ -5258,14 +5120,6 @@ Internet-Draft TE Common YANG Types September 2024 key "index"; ordered-by user; description - - - -Busi, et al. Expires 31 March 2025 [Page 94] - -Internet-Draft TE Common YANG Types September 2024 - - "List of route objects to include or exclude in the path computation."; leaf explicit-route-usage { @@ -5292,6 +5146,14 @@ Internet-Draft TE Common YANG Types September 2024 "SRLG container."; leaf srlg { type uint32; + + + +Busi, et al. Expires 9 May 2025 [Page 92] + +Internet-Draft TE Common YANG Types November 2024 + + description "SRLG value."; } @@ -5314,14 +5176,6 @@ Internet-Draft TE Common YANG Types September 2024 the path computation."; list route-object-include-object { key "index"; - - - -Busi, et al. Expires 31 March 2025 [Page 95] - -Internet-Draft TE Common YANG Types September 2024 - - ordered-by user; description "List of Explicit Route Objects to be included in the @@ -5348,6 +5202,14 @@ Internet-Draft TE Common YANG Types September 2024 "List of Explicit Route Objects to be excluded in the path computation."; leaf index { + + + +Busi, et al. Expires 9 May 2025 [Page 93] + +Internet-Draft TE Common YANG Types November 2024 + + type uint32; description "Route object entry index. The index is used to @@ -5370,14 +5232,6 @@ Internet-Draft TE Common YANG Types September 2024 "An SRLG value to be included or excluded."; } description - - - -Busi, et al. Expires 31 March 2025 [Page 96] - -Internet-Draft TE Common YANG Types September 2024 - - "Augmentation for a generic explicit route for SRLG exclusion."; } @@ -5385,9 +5239,6 @@ Internet-Draft TE Common YANG Types September 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-metric-bounds { description "TE path metric bounds grouping."; @@ -5407,6 +5258,14 @@ Internet-Draft TE Common YANG Types September 2024 link metric which exceeds the specified bounds MUST NOT be selected."; leaf metric-type { + + + +Busi, et al. Expires 9 May 2025 [Page 94] + +Internet-Draft TE Common YANG Types November 2024 + + type identityref { base link-path-metric-type; } @@ -5426,21 +5285,10 @@ Internet-Draft TE Common YANG Types September 2024 The unit of is interpreted in the context of the 'metric-type' identity."; } - - - -Busi, et al. Expires 31 March 2025 [Page 97] - -Internet-Draft TE Common YANG Types September 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."; @@ -5466,6 +5314,14 @@ Internet-Draft TE Common YANG Types September 2024 description "Container for the list of tiebreakers. + + + +Busi, et al. Expires 9 May 2025 [Page 95] + +Internet-Draft TE Common YANG Types November 2024 + + This container has been deprecated by the tiebreaker leaf."; list tiebreaker { @@ -5482,14 +5338,6 @@ Internet-Draft TE Common YANG Types September 2024 status deprecated; description "Identifies an entry in the list of tiebreakers."; - - - -Busi, et al. Expires 31 March 2025 [Page 98] - -Internet-Draft TE Common YANG Types September 2024 - - } } } @@ -5522,6 +5370,14 @@ Internet-Draft TE Common YANG Types September 2024 "The tiebreaker criteria to apply on an equally favored set of paths, in order to pick the best."; } + + + +Busi, et al. Expires 9 May 2025 [Page 96] + +Internet-Draft TE Common YANG Types November 2024 + + } grouping generic-path-affinities { @@ -5538,14 +5394,6 @@ Internet-Draft TE Common YANG Types September 2024 type identityref { base resource-affinities-type; } - - - -Busi, et al. Expires 31 March 2025 [Page 99] - -Internet-Draft TE Common YANG Types September 2024 - - description "Identifies an entry in the list of value affinity constraints."; @@ -5578,6 +5426,14 @@ Internet-Draft TE Common YANG Types September 2024 leaf name { type string; description + + + +Busi, et al. Expires 9 May 2025 [Page 97] + +Internet-Draft TE Common YANG Types November 2024 + + "Identifies a named affinity entry."; } description @@ -5594,14 +5450,6 @@ Internet-Draft TE Common YANG Types September 2024 description "Path SRLG properties container."; list path-srlgs-list { - - - -Busi, et al. Expires 31 March 2025 [Page 100] - -Internet-Draft TE Common YANG Types September 2024 - - key "usage"; description "List of SRLG values to be included or excluded."; @@ -5634,6 +5482,14 @@ Internet-Draft TE Common YANG Types September 2024 description "Identifies an entry in a list of named SRLGs to either include or exclude."; + + + +Busi, et al. Expires 9 May 2025 [Page 98] + +Internet-Draft TE Common YANG Types November 2024 + + } leaf-list names { type string; @@ -5650,14 +5506,6 @@ Internet-Draft TE Common YANG Types September 2024 leaf disjointness { type te-path-disjointness; description - - - -Busi, et al. Expires 31 March 2025 [Page 101] - -Internet-Draft TE Common YANG Types September 2024 - - "The type of resource disjointness. When configured for a primary path, the disjointness level applies to all secondary LSPs. When configured for a @@ -5690,6 +5538,14 @@ Internet-Draft TE Common YANG Types September 2024 description "TE generic path properties grouping."; container path-properties { + + + +Busi, et al. Expires 9 May 2025 [Page 99] + +Internet-Draft TE Common YANG Types November 2024 + + config false; description "The TE path properties."; @@ -5706,14 +5562,6 @@ Internet-Draft TE Common YANG Types September 2024 } leaf accumulative-value { type uint64; - - - -Busi, et al. Expires 31 March 2025 [Page 102] - -Internet-Draft TE Common YANG Types September 2024 - - description "TE path metric accumulative value."; } @@ -5744,11 +5592,16 @@ Internet-Draft TE Common YANG Types September 2024 } } - // 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 + + + +Busi, et al. Expires 9 May 2025 [Page 100] + +Internet-Draft TE Common YANG Types November 2024 + + "Common grouping to define the LSP encoding and switching types"; leaf encoding { @@ -5762,14 +5615,6 @@ Internet-Draft TE Common YANG Types September 2024 Architecture"; } leaf switching-type { - - - -Busi, et al. Expires 31 March 2025 [Page 103] - -Internet-Draft TE Common YANG Types September 2024 - - type identityref { base te-types:switching-capabilities; } @@ -5781,9 +5626,6 @@ Internet-Draft TE Common YANG Types September 2024 } } - // CHANGE NOTE: The grouping te-generic-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."; @@ -5808,6 +5650,14 @@ Internet-Draft TE Common YANG Types September 2024 "IP address representation of the node identifier."; } enum te-id { + + + +Busi, et al. Expires 9 May 2025 [Page 101] + +Internet-Draft TE Common YANG Types November 2024 + + description "TE identifier of the node"; } @@ -5818,14 +5668,6 @@ Internet-Draft TE Common YANG Types September 2024 } description "Type of node identifier representation."; - - - -Busi, et al. Expires 31 March 2025 [Page 104] - -Internet-Draft TE Common YANG Types September 2024 - - } } } @@ -5838,10 +5680,7 @@ Internet-Draft TE Common YANG Types September 2024 The "ietf-te-packet-types" module imports from the "ietf-te-types" module defined in Section 4 of this document. - CHANGE NOTE: Please focus your review only on the updates to the - YANG model: see also Appendix B.1. - - file "ietf-te-packet-types@2024-01-25.yang" + file "ietf-te-packet-types@2024-10-17.yang" module ietf-te-packet-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-te-packet-types"; @@ -5868,19 +5707,18 @@ Internet-Draft TE Common YANG Types September 2024 "WG Web: WG List: - Editor: Tarek Saad - - - Editor: Rakesh Gandhi - +Busi, et al. Expires 9 May 2025 [Page 102] + +Internet-Draft TE Common YANG Types November 2024 -Busi, et al. Expires 31 March 2025 [Page 105] - -Internet-Draft TE Common YANG Types September 2024 + Editor: Tarek Saad + + Editor: Rakesh Gandhi + Editor: Vishnu Pavan Beeram @@ -5917,13 +5755,21 @@ Internet-Draft TE Common YANG Types September 2024 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-09-27 { + revision 2024-10-30 { description "This revision adds the following new identities: - bandwidth-profile-type; - link-metric-delay-variation; - link-metric-loss; - path-metric-delay-variation; + + + +Busi, et al. Expires 9 May 2025 [Page 103] + +Internet-Draft TE Common YANG Types November 2024 + + - path-metric-loss. This revision adds the following new groupings: @@ -5931,13 +5777,6 @@ Internet-Draft TE Common YANG Types September 2024 - te-packet-path-bandwidth; - te-packet-link-bandwidth. - - -Busi, et al. Expires 31 March 2025 [Page 106] - -Internet-Draft TE Common YANG Types September 2024 - - This revision provides also few editorial changes."; reference "RFC XXXX: Common YANG Data Types for Traffic Engineering"; @@ -5956,10 +5795,6 @@ Internet-Draft TE Common YANG Types September 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"; @@ -5983,33 +5818,22 @@ Internet-Draft TE Common YANG Types September 2024 identity rfc-2698 { base bandwidth-profile-type; - description - "RFC 2698 Bandwidth Profile"; - reference -Busi, et al. Expires 31 March 2025 [Page 107] +Busi, et al. Expires 9 May 2025 [Page 104] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - "RFC 2698: A Two Rate Three Color Marker"; - } - identity rfc-4115 { - base bandwidth-profile-type; description - "RFC 4115 Bandwidth Profile"; + "RFC 2698 Bandwidth Profile"; reference - "RFC 4115: A Differentiated Service Two-Rate, Three-Color - Marker with Efficient Handling of in-Profile - Traffic"; + "RFC 2698: A Two Rate Three Color Marker"; } - // 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 + // Derived identities from te-types:link-metric-type + identity link-metric-delay-variation { base te-types:link-metric-type; description @@ -6022,9 +5846,6 @@ Internet-Draft TE Common YANG Types September 2024 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 @@ -6037,19 +5858,10 @@ Internet-Draft TE Common YANG Types September 2024 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 + // Derived identities from te-types:link-metric-type + identity path-metric-delay-variation { base te-types:path-metric-type; - - - -Busi, et al. Expires 31 March 2025 [Page 108] - -Internet-Draft TE Common YANG Types September 2024 - - description "The Path Delay Variation Metric, measured in units of microseconds."; @@ -6060,11 +5872,16 @@ Internet-Draft TE Common YANG Types September 2024 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; + + + +Busi, et al. Expires 9 May 2025 [Page 105] + +Internet-Draft TE Common YANG Types November 2024 + + description "The Path Loss Metric, measured in units of 0.000003%."; reference @@ -6098,14 +5915,6 @@ Internet-Draft TE Common YANG Types September 2024 explicitly specified or automatically computed."; } - - - -Busi, et al. Expires 31 March 2025 [Page 109] - -Internet-Draft TE Common YANG Types September 2024 - - typedef te-class-type { type uint8; description @@ -6121,6 +5930,14 @@ Internet-Draft TE Common YANG Types September 2024 typedef bc-type { type uint8 { + + + +Busi, et al. Expires 9 May 2025 [Page 106] + +Internet-Draft TE Common YANG Types November 2024 + + range "0..7"; } description @@ -6154,14 +5971,6 @@ Internet-Draft TE Common YANG Types September 2024 identity backup-protection-type { description "Base identity for the backup protection type."; - - - -Busi, et al. Expires 31 March 2025 [Page 110] - -Internet-Draft TE Common YANG Types September 2024 - - } identity backup-protection-link { @@ -6177,6 +5986,14 @@ Internet-Draft TE Common YANG Types September 2024 } identity bc-model-type { + + + +Busi, et al. Expires 9 May 2025 [Page 107] + +Internet-Draft TE Common YANG Types November 2024 + + description "Base identity for the Diffserv-TE Bandwidth Constraints Model type."; @@ -6210,14 +6027,6 @@ Internet-Draft TE Common YANG Types September 2024 Model type."; reference "RFC 4126: Max Allocation with Reservation Bandwidth - - - -Busi, et al. Expires 31 March 2025 [Page 111] - -Internet-Draft TE Common YANG Types September 2024 - - Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons"; } @@ -6233,6 +6042,14 @@ Internet-Draft TE Common YANG Types September 2024 augment "performance-metrics-one-way" { leaf one-way-min-delay { type uint32 { + + + +Busi, et al. Expires 9 May 2025 [Page 108] + +Internet-Draft TE Common YANG Types November 2024 + + range "0..16777215"; } description @@ -6266,14 +6083,6 @@ Internet-Draft TE Common YANG Types September 2024 reference "RFC 5481: Packet Delay Variation Applicability Statement, Section 4.2"; - - - -Busi, et al. Expires 31 March 2025 [Page 112] - -Internet-Draft TE Common YANG Types September 2024 - - } leaf one-way-delay-variation-normality { type te-types:performance-metrics-normality; @@ -6283,12 +6092,20 @@ Internet-Draft TE Common YANG Types September 2024 reference "RFC 7471: OSPF Traffic Engineering (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"; + Using TE Metric Extensions"; } + + + +Busi, et al. Expires 9 May 2025 [Page 109] + +Internet-Draft TE Common YANG Types November 2024 + + leaf one-way-packet-loss { type decimal64 { fraction-digits 6; @@ -6310,11 +6127,11 @@ Internet-Draft TE Common YANG Types September 2024 reference "RFC 7471: OSPF Traffic Engineering (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"; + Using TE Metric Extensions"; } description "PM one-way packet-specific augmentation for a generic PM @@ -6322,14 +6139,6 @@ Internet-Draft TE Common YANG Types September 2024 } augment "performance-metrics-two-way" { leaf two-way-min-delay { - - - -Busi, et al. Expires 31 March 2025 [Page 113] - -Internet-Draft TE Common YANG Types September 2024 - - type uint32 { range "0..16777215"; } @@ -6345,11 +6154,19 @@ Internet-Draft TE Common YANG Types September 2024 reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions + + + +Busi, et al. Expires 9 May 2025 [Page 110] + +Internet-Draft TE Common YANG Types November 2024 + + + 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"; + Using TE Metric Extensions"; } leaf two-way-max-delay { type uint32 { @@ -6367,25 +6184,17 @@ Internet-Draft TE Common YANG Types September 2024 reference "RFC 7471: OSPF Traffic Engineering (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"; + Using TE Metric Extensions"; } leaf two-way-delay-variation { type uint32 { range "0..16777215"; } default "0"; - - - -Busi, et al. Expires 31 March 2025 [Page 114] - -Internet-Draft TE Common YANG Types September 2024 - - description "Two-way delay variation in microseconds."; reference @@ -6399,12 +6208,20 @@ Internet-Draft TE Common YANG Types September 2024 "Two-way delay variation normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric + Extensions + RFC 8570: IS-IS Traffic Engineering (TE) Metric + + + +Busi, et al. Expires 9 May 2025 [Page 111] + +Internet-Draft TE Common YANG Types November 2024 + + 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"; + Using TE Metric Extensions"; } leaf two-way-packet-loss { type decimal64 { @@ -6427,21 +6244,11 @@ Internet-Draft TE Common YANG Types September 2024 "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"; - - - -Busi, et al. Expires 31 March 2025 [Page 115] - -Internet-Draft TE Common YANG Types September 2024 - - + "RFC 7471: OSPF Traffic Engineering (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"; } } } @@ -6459,6 +6266,14 @@ Internet-Draft TE Common YANG Types September 2024 } leaf one-way-max-delay { type uint32 { + + + +Busi, et al. Expires 9 May 2025 [Page 112] + +Internet-Draft TE Common YANG Types November 2024 + + range "0..16777215"; } default "0"; @@ -6486,18 +6301,6 @@ Internet-Draft TE Common YANG Types September 2024 } } - // CHANGE NOTE: The grouping - // one-way-performance-metrics-gauge-packet has been added in - // this module revision - // RFC Editor: remove the note above and this note - - - -Busi, et al. Expires 31 March 2025 [Page 116] - -Internet-Draft TE Common YANG Types September 2024 - - grouping one-way-performance-metrics-gauge-packet { description "One-way packet PM throttle grouping. @@ -6519,6 +6322,14 @@ Internet-Draft TE Common YANG Types September 2024 "RFC 7679: A One-Way Delay Metric for IP Performance Metrics (IPPM)"; } + + + +Busi, et al. Expires 9 May 2025 [Page 113] + +Internet-Draft TE Common YANG Types November 2024 + + leaf one-way-delay-variation { type yang:gauge64; description @@ -6546,14 +6357,6 @@ Internet-Draft TE Common YANG Types September 2024 "Two-way packet PM throttle grouping."; leaf two-way-min-delay { type uint32 { - - - -Busi, et al. Expires 31 March 2025 [Page 117] - -Internet-Draft TE Common YANG Types September 2024 - - range "0..16777215"; } default "0"; @@ -6575,6 +6378,14 @@ Internet-Draft TE Common YANG Types September 2024 default "0"; description "Two-way delay variation in microseconds."; + + + +Busi, et al. Expires 9 May 2025 [Page 114] + +Internet-Draft TE Common YANG Types November 2024 + + } leaf two-way-packet-loss { type decimal64 { @@ -6589,10 +6400,6 @@ Internet-Draft TE Common YANG Types September 2024 } } - // CHANGE NOTE: The grouping - // two-way-performance-metrics-gauge-packet has been added in - // this module revision - // RFC Editor: remove the note above and this note grouping two-way-performance-metrics-gauge-packet { description "Two-way packet PM throttle grouping. @@ -6602,14 +6409,6 @@ Internet-Draft TE Common YANG Types September 2024 instead of uint32 data types and referencing IPPM RFCs instead of IGP-TE RFCs."; leaf two-way-min-delay { - - - -Busi, et al. Expires 31 March 2025 [Page 118] - -Internet-Draft TE Common YANG Types September 2024 - - type yang:gauge64; description "Two-way minimum delay or latency in microseconds."; @@ -6635,6 +6434,14 @@ Internet-Draft TE Common YANG Types September 2024 fraction-digits 5; range "0..100"; } + + + +Busi, et al. Expires 9 May 2025 [Page 115] + +Internet-Draft TE Common YANG Types November 2024 + + description "The ratio of packets dropped to packets transmitted between two endpoints."; @@ -6658,14 +6465,6 @@ Internet-Draft TE Common YANG Types September 2024 description "PM threshold-in packet augmentation for a generic grouping."; - - - -Busi, et al. Expires 31 March 2025 [Page 119] - -Internet-Draft TE Common YANG Types September 2024 - - } augment "throttle/threshold-accelerated-advertisement" { uses one-way-performance-metrics-packet; @@ -6677,9 +6476,6 @@ Internet-Draft TE Common YANG Types September 2024 } } - // CHANGE NOTE: The bandwidth-profile-parameters below has been - // added in this module revision - // RFC Editor: remove the note above and this note grouping bandwidth-profile-parameters { description "Common parameters to define bandwidth profiles in packet @@ -6694,6 +6490,14 @@ Internet-Draft TE Common YANG Types September 2024 type uint64; units "bytes"; description + + + +Busi, et al. Expires 9 May 2025 [Page 116] + +Internet-Draft TE Common YANG Types November 2024 + + "Committed Burst Size (CBS)."; } leaf eir { @@ -6714,14 +6518,6 @@ Internet-Draft TE Common YANG Types September 2024 description "Peak Information Rate (PIR)."; } - - - -Busi, et al. Expires 31 March 2025 [Page 120] - -Internet-Draft TE Common YANG Types September 2024 - - leaf pbs { type uint64; units "bytes"; @@ -6730,9 +6526,6 @@ Internet-Draft TE Common YANG Types September 2024 } } - // 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 "Bandwidth attributes for TE Packet paths."; @@ -6753,6 +6546,14 @@ Internet-Draft TE Common YANG Types September 2024 type bandwidth-kbps; description "Set the bandwidth value explicitly, e.g., using offline + + + +Busi, et al. Expires 9 May 2025 [Page 117] + +Internet-Draft TE Common YANG Types November 2024 + + calculation."; } container bandwidth-profile { @@ -6770,14 +6571,6 @@ Internet-Draft TE Common YANG Types September 2024 leaf bandwidth-profile-type { type identityref { base bandwidth-profile-type; - - - -Busi, et al. Expires 31 March 2025 [Page 121] - -Internet-Draft TE Common YANG Types September 2024 - - } description "Type of Bandwidth Profile."; @@ -6810,9 +6603,13 @@ Internet-Draft TE Common YANG Types September 2024 } } - // CHANGE NOTE: The te-packet-path-bandwidth below has been - // added in this module revision - // RFC Editor: remove the note above and this note + + +Busi, et al. Expires 9 May 2025 [Page 118] + +Internet-Draft TE Common YANG Types November 2024 + + grouping te-packet-link-bandwidth { description "Bandwidth attributes for Packet TE links."; @@ -6826,14 +6623,6 @@ Internet-Draft TE Common YANG Types September 2024 } - - - -Busi, et al. Expires 31 March 2025 [Page 122] - -Internet-Draft TE Common YANG Types September 2024 - - Figure 2: Packet TE Types YANG module 6. IANA Considerations @@ -6849,8 +6638,9 @@ Internet-Draft TE Common YANG Types September 2024 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. - This document also requests IANA to update the following YANG modules - to the "YANG Module Names" registry [RFC7950]: + This document requests IANA to register the following YANG modules in + the "YANG Module Names" registry [RFC6020] within the "YANG + Parameters" registry group. name: ietf-te-types Maintained by IANA? N @@ -6866,548 +6656,468 @@ Internet-Draft TE Common YANG Types September 2024 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 + This section is modeled after the template described in Section 3.7 + of [I-D.ietf-netmod-rfc8407bis]. -Busi, et al. Expires 31 March 2025 [Page 123] +Busi, et al. Expires 9 May 2025 [Page 119] -Internet-Draft TE Common YANG Types September 2024 - - - 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. - -8. References - -8.1. Normative References +Internet-Draft TE Common YANG Types November 2024 - [I-D.ietf-pce-sid-algo] - Sidor, S., Tokar, A., Peng, S., Peng, S., and A. Stone, - "Carrying SR-Algorithm Information in PCE-based - Networks.", Work in Progress, Internet-Draft, draft-ietf- - pce-sid-algo-14, 25 September 2024, - . - - [ITU-T_G.709] - International Telecommunication Union, "Interfaces for the - optical transport network", ITU-T G.709 , June 2020, - . - - [ITU_G.808.1] - ITU-T Recommendation G.808.1, "Generic protection - switching - Linear trail and subnetwork protection", ITU-T - Recommendation G.808.1 , May 2014, - . - - [MEF_10.3] MEF, "Ethernet Services Attributes Phase 3", MEF 10.3 , - October 2013, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color - Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, - . - [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color - Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, - . + The "ietf-te-types" and the "ietf-te-packet-types" YANG modules + define data models that are designed to be accessed via YANG-based + management protocols, such as NETCONF [RFC6241] and RESTCONF + [RFC8040]. These protocols have to use a secure transport layer + (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to + use mutual authentication. + 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 modules define a set of identities, types, and groupings. + These nodes are intended to be reused by other YANG modules. The + modules by themselves do not expose any data nodes that are writable, + data nodes that contain read-only state, or RPCs. As such, there are + no additional security issues related to the YANG module that need to + be considered. + Modules that use the groupings that are defined in this document + should identify the corresponding security considerations. For + example, reusing some of these groupings will expose privacy-related + information (e.g., 'node-example'). +8. References -Busi, et al. Expires 31 March 2025 [Page 124] - -Internet-Draft TE Common YANG Types September 2024 +8.1. Normative References + [ITU-T_G.709] + International Telecommunication Union, "Interfaces for the + optical transport network", ITU-T G.709 , June 2020, + . - [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, - . + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [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, - . + . [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, - . + . + + + + +Busi, et al. Expires 9 May 2025 [Page 120] + +Internet-Draft TE Common YANG Types November 2024 + [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, - . + . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, - . + . [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, - . + . [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, - . - - [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, . + . [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, DOI 10.17487/RFC4124, June 2005, - . - - - - - - -Busi, et al. Expires 31 March 2025 [Page 125] - -Internet-Draft TE Common YANG Types September 2024 - - - [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, - . - - [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, - . - - [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints - Model for Diffserv-aware MPLS Traffic Engineering", - RFC 4127, DOI 10.17487/RFC4127, June 2005, - . + . [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, - . + . [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, - . + . [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, - . - - [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, - . + . [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, - . + . - [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, . -Busi, et al. Expires 31 March 2025 [Page 126] +Busi, et al. Expires 9 May 2025 [Page 121] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - [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, . [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, - . + . [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, - May 2007, . + May 2007, . [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, - . + . [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, - . + . [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, . + 2007, . [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, - . + . [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, . + 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October - 2008, . + 2008, . + [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, + . -Busi, et al. Expires 31 March 2025 [Page 127] - -Internet-Draft TE Common YANG Types September 2024 - [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, - . +Busi, et al. Expires 9 May 2025 [Page 122] + +Internet-Draft TE Common YANG Types November 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, . + February 2009, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, - . + . [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, - . + . [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, - . + . [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, - . + . [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, . + July 2009, . [RFC5712] Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic Engineering Soft Preemption", RFC 5712, DOI 10.17487/RFC5712, January 2010, - . + . + [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, + . -Busi, et al. Expires 31 March 2025 [Page 128] +Busi, et al. Expires 9 May 2025 [Page 123] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - [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, - . [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, - . + . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, - . + . [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, - February 2011, . - - [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, - . + February 2011, . - [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure - Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, - . + [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. + Yamagata, "Internal BGP as the Provider/Customer Edge + Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", + RFC 6368, DOI 10.17487/RFC6368, September 2011, + . [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, - . + . [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, . + October 2011, . [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, . + February 2012, . [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, October 2012, - . + . + [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, + . -Busi, et al. Expires 31 March 2025 [Page 129] - -Internet-Draft TE Common YANG Types September 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, - . + + + +Busi, et al. Expires 9 May 2025 [Page 124] + +Internet-Draft TE Common YANG Types November 2024 + [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, - . + . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, - . + . [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, - . + . [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, . + 2014, . + + [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., + D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS + Transport Profile (MPLS-TP) Linear Protection to Match the + Operational Expectations of Synchronous Digital Hierarchy, + Optical Transport Network, and Ethernet Transport Network + Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, + . [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10.17487/RFC7308, July 2014, - . + . [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, - . + . [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, - . + . + - [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, - . -Busi, et al. Expires 31 March 2025 [Page 130] + +Busi, et al. Expires 9 May 2025 [Page 125] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 + + [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, + . [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, - . + . [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, - . - - [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, - . + . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, - . + . [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, - . - - [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF - Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, - . + . [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, . + April 2017, . [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, - . + . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - + May 2017, . + [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, . -Busi, et al. Expires 31 March 2025 [Page 131] +Busi, et al. Expires 9 May 2025 [Page 126] -Internet-Draft TE Common YANG Types September 2024 - +Internet-Draft TE Common YANG Types November 2024 - [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, . [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, - . + . [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, - . + . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, - . + . [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, . - - [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol - Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, - . + 2018, . [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, . + 2019, . [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, - . + . [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, - . - - - -Busi, et al. Expires 31 March 2025 [Page 132] - -Internet-Draft TE Common YANG Types September 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, . + July 2020, . + + + + + + + +Busi, et al. Expires 9 May 2025 [Page 127] + +Internet-Draft TE Common YANG Types November 2024 + [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, - . - - [RFC9522] Farrel, A., Ed., "Overview and Principles of Internet - Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, - January 2024, . + . 8.2. Informative References @@ -7415,23 +7125,127 @@ Internet-Draft TE Common YANG Types September 2024 Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", Work in Progress, Internet-Draft, draft-ietf- - netmod-rfc8407bis-17, 27 September 2024, + netmod-rfc8407bis-20, 21 October 2024, . + rfc8407bis-20>. + + [I-D.ietf-pce-sid-algo-14] + Sidor, S., Tokar, A., Peng, S., Peng, S., and A. Stone, + "Carrying SR-Algorithm Information in PCE-based + Networks.", Work in Progress, Internet-Draft, draft-ietf- + pce-sid-algo-14, 25 September 2024, + . + + [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, + . + + [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color + Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, + . + + [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, + . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, - . + . + + + + + + + +Busi, et al. Expires 9 May 2025 [Page 128] + +Internet-Draft TE Common YANG Types November 2024 + + + [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, + . + + [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, + . + + [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints + Model for Diffserv-aware MPLS Traffic Engineering", + RFC 4127, DOI 10.17487/RFC4127, June 2005, + . + + [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, + January 2006, . + + [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, + . + + [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, . + + [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, . + + [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, + . + + [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, + . + + + + +Busi, et al. Expires 9 May 2025 [Page 129] + +Internet-Draft TE Common YANG Types November 2024 + + + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, - . + . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . - [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, - . + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + . + + [RFC9522] Farrel, A., Ed., "Overview and Principles of Internet + Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, + January 2024, . Appendix A. The Complete Schema Trees @@ -7440,15 +7254,11 @@ Appendix A. The Complete Schema Trees used. The data type of every leaf node is shown near the right end of the corresponding line. -A.1. TE Types Schema Tree - - - - -Busi, et al. Expires 31 March 2025 [Page 133] - -Internet-Draft TE Common YANG Types September 2024 + Editors' Note: The YANG trees have been generated by pyang and + have some bugs to be fixed before publication. Please manually + fix the YANG tree before sending the document to the RFC EDITOR. +A.1. TE Types Schema Tree =============== NOTE: '\' line wrapping per RFC 8792 ================ @@ -7464,6 +7274,14 @@ Internet-Draft TE Common YANG Types September 2024 +-- (technology)? | +--:(generic) | +-- generic? rt-types:generalized-label + + + +Busi, et al. Expires 9 May 2025 [Page 130] + +Internet-Draft TE Common YANG Types November 2024 + + +-- direction? te-label-direction grouping te-topology-identifier: +-- te-topology-identifier @@ -7498,14 +7316,6 @@ Internet-Draft TE Common YANG Types September 2024 +-- one-way-available-bandwidth? | rt-types:bandwidth-ieee-float32 +-- one-way-utilized-bandwidth? - - - -Busi, et al. Expires 31 March 2025 [Page 134] - -Internet-Draft TE Common YANG Types September 2024 - - rt-types:bandwidth-ieee-float32 grouping two-way-performance-metrics: +-- two-way-delay? uint32 @@ -7520,6 +7330,14 @@ Internet-Draft TE Common YANG Types September 2024 +-- two-way-delay? uint32 grouping performance-metrics-attributes: +-- performance-metrics-one-way + + + +Busi, et al. Expires 9 May 2025 [Page 131] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- one-way-delay? uint32 | +-- one-way-delay-normality? | | te-types:performance-metrics-normality @@ -7554,14 +7372,6 @@ Internet-Draft TE Common YANG Types September 2024 | +-- one-way-utilized-bandwidth? | | rt-types:bandwidth-ieee-float32 | +-- two-way-delay? uint32 - - - -Busi, et al. Expires 31 March 2025 [Page 135] - -Internet-Draft TE Common YANG Types September 2024 - - +-- threshold-in | +-- one-way-delay? uint32 | +-- one-way-residual-bandwidth? @@ -7576,6 +7386,14 @@ Internet-Draft TE Common YANG Types September 2024 +-- one-way-residual-bandwidth? | rt-types:bandwidth-ieee-float32 +-- one-way-available-bandwidth? + + + +Busi, et al. Expires 9 May 2025 [Page 132] + +Internet-Draft TE Common YANG Types November 2024 + + | rt-types:bandwidth-ieee-float32 +-- one-way-utilized-bandwidth? | rt-types:bandwidth-ieee-float32 @@ -7610,14 +7428,6 @@ Internet-Draft TE Common YANG Types September 2024 +-- (technology)? | +--:(generic) | +-- generic? rt-types:generalized-label - - - -Busi, et al. Expires 31 March 2025 [Page 136] - -Internet-Draft TE Common YANG Types September 2024 - - +-- direction? te-label-direction grouping record-route-state: +-- index? uint32 @@ -7632,6 +7442,14 @@ Internet-Draft TE Common YANG Types September 2024 | +-- link-tp-id te-tp-id | +-- flags* path-attribute-flags +--:(unnumbered-link-hop) + + + +Busi, et al. Expires 9 May 2025 [Page 133] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- unnumbered-link-hop | +-- link-tp-id-uri? nt:tp-id | +-- link-tp-id? te-tp-id @@ -7666,14 +7484,6 @@ Internet-Draft TE Common YANG Types September 2024 | +--:(generic) | +-- generic? int32 +-- range-bitmap? yang:hex-string - - - -Busi, et al. Expires 31 March 2025 [Page 137] - -Internet-Draft TE Common YANG Types September 2024 - - grouping label-set-info: +-- label-restrictions +-- label-restriction* [index] @@ -7688,6 +7498,14 @@ Internet-Draft TE Common YANG Types September 2024 +-- label-end | +-- te-label | +-- (technology)? + + + +Busi, et al. Expires 9 May 2025 [Page 134] + +Internet-Draft TE Common YANG Types November 2024 + + | | +--:(generic) | | +-- generic? rt-types:generalized-label | +-- direction? te-label-direction @@ -7722,14 +7540,6 @@ Internet-Draft TE Common YANG Types September 2024 | | +-- hop-type? te-hop-type | | +-- direction? te-link-direction | +--:(as-number) - - - -Busi, et al. Expires 31 March 2025 [Page 138] - -Internet-Draft TE Common YANG Types September 2024 - - | | +-- as-number-hop | | +-- as-number inet:as-number | | +-- hop-type? te-hop-type @@ -7744,6 +7554,14 @@ Internet-Draft TE Common YANG Types September 2024 | +-- srlg | +-- srlg? uint32 +-- explicit-route-include-objects + + + +Busi, et al. Expires 9 May 2025 [Page 135] + +Internet-Draft TE Common YANG Types November 2024 + + +-- route-object-include-object* [index] +-- index? uint32 +-- (type)? @@ -7778,14 +7596,6 @@ Internet-Draft TE Common YANG Types September 2024 +-- direction? te-label-direction grouping common-constraints: +-- te-bandwidth - - - -Busi, et al. Expires 31 March 2025 [Page 139] - -Internet-Draft TE Common YANG Types September 2024 - - | +-- (technology)? | +--:(generic) | +-- generic? te-bandwidth @@ -7800,6 +7610,14 @@ Internet-Draft TE Common YANG Types September 2024 | +-- client-id? te-global-id | +-- topology-id? te-topology-id +-- te-bandwidth + + + +Busi, et al. Expires 9 May 2025 [Page 136] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- (technology)? | +--:(generic) | +-- generic? te-bandwidth @@ -7834,14 +7652,6 @@ Internet-Draft TE Common YANG Types September 2024 | | +-- as-number-hop | | +-- as-number inet:as-number | | +-- hop-type? te-hop-type - - - -Busi, et al. Expires 31 March 2025 [Page 140] - -Internet-Draft TE Common YANG Types September 2024 - - | +--:(label) | +-- label-hop | +-- te-label @@ -7856,6 +7666,14 @@ Internet-Draft TE Common YANG Types September 2024 +--:(numbered-node-hop) | +-- numbered-node-hop | +-- node-id-uri? nw:node-id + + + +Busi, et al. Expires 9 May 2025 [Page 137] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- node-id? te-node-id | +-- hop-type? te-hop-type +--:(numbered-link-hop) @@ -7890,14 +7708,6 @@ Internet-Draft TE Common YANG Types September 2024 +-- index? uint32 +-- (type)? +--:(numbered-node-hop) - - - -Busi, et al. Expires 31 March 2025 [Page 141] - -Internet-Draft TE Common YANG Types September 2024 - - | +-- numbered-node-hop | +-- node-id-uri? nw:node-id | +-- node-id? te-node-id @@ -7912,6 +7722,14 @@ Internet-Draft TE Common YANG Types September 2024 | +-- link-tp-id-uri? nt:tp-id | +-- link-tp-id? te-tp-id | +-- node-id-uri? nw:node-id + + + +Busi, et al. Expires 9 May 2025 [Page 138] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- node-id? te-node-id | +-- hop-type? te-hop-type | +-- direction? te-link-direction @@ -7946,14 +7764,6 @@ Internet-Draft TE Common YANG Types September 2024 | +-- link-tp-id? te-tp-id | +-- node-id-uri? nw:node-id | +-- node-id? te-node-id - - - -Busi, et al. Expires 31 March 2025 [Page 142] - -Internet-Draft TE Common YANG Types September 2024 - - | +-- hop-type? te-hop-type | +-- direction? te-link-direction +--:(as-number) @@ -7968,6 +7778,14 @@ Internet-Draft TE Common YANG Types September 2024 | | +-- generic? rt-types:generalized-label | +-- direction? te-label-direction +--:(srlg) + + + +Busi, et al. Expires 9 May 2025 [Page 139] + +Internet-Draft TE Common YANG Types November 2024 + + +-- srlg +-- srlg? uint32 grouping generic-path-metric-bounds: @@ -8002,14 +7820,6 @@ Internet-Draft TE Common YANG Types September 2024 | | | | | +-- link-tp-id? te-tp-id | | | | | +-- node-id-uri? nw:node-id | | | | | +-- node-id? te-node-id - - - -Busi, et al. Expires 31 March 2025 [Page 143] - -Internet-Draft TE Common YANG Types September 2024 - - | | | | | +-- hop-type? te-hop-type | | | | | +-- direction? | | | | | te-link-direction @@ -8024,6 +7834,14 @@ Internet-Draft TE Common YANG Types September 2024 | | | | | | +--:(generic) | | | | | | +-- generic? | | | | | | rt-types:generalized\ + + + +Busi, et al. Expires 9 May 2025 [Page 140] + +Internet-Draft TE Common YANG Types November 2024 + + -label | | | | | +-- direction? | | | | | te-label-direction @@ -8058,14 +7876,6 @@ Internet-Draft TE Common YANG Types September 2024 | | | | +-- as-number inet:as-number | | | | +-- hop-type? te-hop-type | | | +--:(label) - - - -Busi, et al. Expires 31 March 2025 [Page 144] - -Internet-Draft TE Common YANG Types September 2024 - - | | | +-- label-hop | | | +-- te-label | | | +-- (technology)? @@ -8080,6 +7890,14 @@ Internet-Draft TE Common YANG Types September 2024 | | x-- tiebreaker-type? identityref | +--:(objective-function) | {path-optimization-objective-function}? + + + +Busi, et al. Expires 9 May 2025 [Page 141] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- objective-function | +-- objective-function-type? identityref +-- tiebreaker? identityref @@ -8114,14 +7932,6 @@ Internet-Draft TE Common YANG Types September 2024 +-- hold-priority? uint8 +-- signaling-type? identityref +-- path-metric-bounds - - - -Busi, et al. Expires 31 March 2025 [Page 145] - -Internet-Draft TE Common YANG Types September 2024 - - | +-- path-metric-bound* [metric-type] | +-- metric-type? identityref | +-- upper-bound? uint64 @@ -8136,6 +7946,14 @@ Internet-Draft TE Common YANG Types September 2024 | +-- name? string +-- path-srlgs-lists | +-- path-srlgs-list* [usage] + + + +Busi, et al. Expires 9 May 2025 [Page 142] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- usage? identityref | +-- values* srlg +-- path-srlgs-names @@ -8170,14 +7988,6 @@ Internet-Draft TE Common YANG Types September 2024 | +-- usage? identityref | +-- values* srlg +-- path-srlgs-names - - - -Busi, et al. Expires 31 March 2025 [Page 146] - -Internet-Draft TE Common YANG Types September 2024 - - | +-- path-srlgs-name* [usage] | +-- usage? identityref | +-- names* string @@ -8192,6 +8002,14 @@ Internet-Draft TE Common YANG Types September 2024 | +--ro usage? identityref | +--ro value? admin-groups +--ro path-affinity-names + + + +Busi, et al. Expires 9 May 2025 [Page 143] + +Internet-Draft TE Common YANG Types November 2024 + + | +--ro path-affinity-name* [usage] | +--ro usage? identityref | +--ro affinity-name* [name] @@ -8226,14 +8044,6 @@ Internet-Draft TE Common YANG Types September 2024 | +--ro node-id? te-node-id | +--ro hop-type? te-hop-type | +--ro direction? te-link-direction - - - -Busi, et al. Expires 31 March 2025 [Page 147] - -Internet-Draft TE Common YANG Types September 2024 - - +--:(as-number) | +--ro as-number-hop | +--ro as-number inet:as-number @@ -8248,9 +8058,17 @@ Internet-Draft TE Common YANG Types September 2024 +--ro direction? te-label-direction grouping encoding-and-switching-type: +-- encoding? identityref + + + +Busi, et al. Expires 9 May 2025 [Page 144] + +Internet-Draft TE Common YANG Types November 2024 + + +-- switching-type? identityref grouping te-generic-node-id: - +-- id? te-gen-node-id + +-- id? union +-- type? enumeration A.2. Packet TE Types Schema Tree @@ -8282,14 +8100,6 @@ A.2. Packet TE Types Schema Tree | | te-types:performance-metrics-normality | +-- one-way-delay-variation? uint32 | +-- one-way-delay-variation-normality? - - - -Busi, et al. Expires 31 March 2025 [Page 148] - -Internet-Draft TE Common YANG Types September 2024 - - | | te-types:performance-metrics-normality | +-- one-way-packet-loss? decimal64 | +-- one-way-packet-loss-normality? @@ -8304,6 +8114,14 @@ Internet-Draft TE Common YANG Types September 2024 +-- two-way-max-delay? uint32 +-- two-way-max-delay-normality? | te-types:performance-metrics-normality + + + +Busi, et al. Expires 9 May 2025 [Page 145] + +Internet-Draft TE Common YANG Types November 2024 + + +-- two-way-delay-variation? uint32 +-- two-way-delay-variation-normality? | te-types:performance-metrics-normality @@ -8338,14 +8156,6 @@ Internet-Draft TE Common YANG Types September 2024 +-- suppression-interval? uint32 +-- threshold-out | +-- one-way-delay? uint32 - - - -Busi, et al. Expires 31 March 2025 [Page 149] - -Internet-Draft TE Common YANG Types September 2024 - - | +-- one-way-residual-bandwidth? | | rt-types:bandwidth-ieee-float32 | +-- one-way-available-bandwidth? @@ -8360,6 +8170,14 @@ Internet-Draft TE Common YANG Types September 2024 | +-- two-way-min-delay? uint32 | +-- two-way-max-delay? uint32 | +-- two-way-delay-variation? uint32 + + + +Busi, et al. Expires 9 May 2025 [Page 146] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- two-way-packet-loss? decimal64 +-- threshold-in | +-- one-way-delay? uint32 @@ -8394,14 +8212,6 @@ Internet-Draft TE Common YANG Types September 2024 +-- two-way-min-delay? uint32 +-- two-way-max-delay? uint32 +-- two-way-delay-variation? uint32 - - - -Busi, et al. Expires 31 March 2025 [Page 150] - -Internet-Draft TE Common YANG Types September 2024 - - +-- two-way-packet-loss? decimal64 grouping bandwidth-profile-parameters: +-- cir? uint64 @@ -8416,6 +8226,14 @@ Internet-Draft TE Common YANG Types September 2024 +-- set-bandwidth? bandwidth-kbps +-- bandwidth-profile | +-- bandwidth-profile-name? string + + + +Busi, et al. Expires 9 May 2025 [Page 147] + +Internet-Draft TE Common YANG Types November 2024 + + | +-- bandwidth-profile-type? identityref | +-- cir? uint64 | +-- cbs? uint64 @@ -8450,14 +8268,6 @@ Appendix B. Changes from RFC 8776 * path-metric-optimization-type; - - - -Busi, et al. Expires 31 March 2025 [Page 151] - -Internet-Draft TE Common YANG Types September 2024 - - * link-path-metric-type; * link-metric-type and its derived identities; @@ -8473,6 +8283,13 @@ Internet-Draft TE Common YANG Types September 2024 The following new data types have been added to the 'ietf-te-types' module: + + +Busi, et al. Expires 9 May 2025 [Page 148] + +Internet-Draft TE Common YANG Types November 2024 + + * path-type; * te-gen-node-id. @@ -8507,13 +8324,6 @@ Internet-Draft TE Common YANG Types September 2024 The following identities, already defined in [RFC8776], have been updated in the 'ietf-te-types' module: - - -Busi, et al. Expires 31 March 2025 [Page 152] - -Internet-Draft TE Common YANG Types September 2024 - - * objective-function-type (editorial); * action-exercise (bug fix); @@ -8528,6 +8338,14 @@ Internet-Draft TE Common YANG Types September 2024 * path-metric-hop (bug fix); + + + +Busi, et al. Expires 9 May 2025 [Page 149] + +Internet-Draft TE Common YANG Types November 2024 + + * path-metric-delay-average (bug fix); * path-metric-delay-minimum (bug fix); @@ -8562,14 +8380,6 @@ Internet-Draft TE Common YANG Types September 2024 The following leaves, already defined in [RFC8776], have been updated in the 'explicit-route-hop': - - - -Busi, et al. Expires 31 March 2025 [Page 153] - -Internet-Draft TE Common YANG Types September 2024 - - - node-id; - link-tp-id. @@ -8584,6 +8394,14 @@ Internet-Draft TE Common YANG Types September 2024 * explicit-route-hop + + + +Busi, et al. Expires 9 May 2025 [Page 150] + +Internet-Draft TE Common YANG Types November 2024 + + The following new leaves have been added to the 'explicit-route- hop' grouping: @@ -8618,14 +8436,6 @@ Internet-Draft TE Common YANG Types September 2024 * tunnel-constraints; - - - -Busi, et al. Expires 31 March 2025 [Page 154] - -Internet-Draft TE Common YANG Types September 2024 - - The following new leaf have been added to the 'tunnel-constraints' grouping: @@ -8638,6 +8448,16 @@ Internet-Draft TE Common YANG Types September 2024 - explicit-route-objects-always; + + + + + +Busi, et al. Expires 9 May 2025 [Page 151] + +Internet-Draft TE Common YANG Types November 2024 + + 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 @@ -8674,14 +8494,6 @@ Internet-Draft TE Common YANG Types September 2024 * of-minimize-agg-bandwidth-consumption; - - - -Busi, et al. Expires 31 March 2025 [Page 155] - -Internet-Draft TE Common YANG Types September 2024 - - * of-minimize-load-most-loaded-link; * of-minimize-cost-path-set; @@ -8690,3195 +8502,17 @@ Internet-Draft TE Common YANG Types September 2024 * lsp-protection-reroute. -B.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: - - 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,33 - > 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"; - > } - > - 30c42 - < - --- - > - - - -Busi, et al. Expires 31 March 2025 [Page 156] - -Internet-Draft TE Common YANG Types September 2024 - - - 55c67 - < Copyright (c) 2020 IETF Trust and the persons identified as - --- - > Copyright (c) 2024 IETF Trust and the persons identified as - 60c72 - < the license terms contained in, the Simplified BSD License set - --- - > the license terms contained in, the Revised BSD License set - 65,66c77,165 - < 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-09-13 { - > 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. - > - > 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; - - - -Busi, et al. Expires 31 March 2025 [Page 157] - -Internet-Draft TE Common YANG Types September 2024 - - - > - 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. - > - > 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."; - - - -Busi, et al. Expires 31 March 2025 [Page 158] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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 - 70c169 - < "Latest revision of TE types."; - --- - > "Initial Version of TE types."; - 86a186 - > - 92c192 - < Version 2 - --- - > Version 2 - 95c195 - < Engineering (MPLS-TE)"; - --- - > Engineering (MPLS-TE)"; - 111a212 - > - 117c218 - < Engineering (MPLS-TE)"; - --- - > Engineering (MPLS-TE)"; - 157,158c258,259 - < Routed Label Switched Paths (LSPs) Using TE Metric - < Extensions - --- - > Routed Label Switched Paths (LSPs) Using TE Metric - > Extensions - 168c269 - < Multi-Protocol Label Switching (GMPLS) - --- - > Multi-Protocol Label Switching (GMPLS) - 170c271 - < Multi-Protocol Label Switching (GMPLS)"; - --- - > Multi-Protocol Label Switching (GMPLS)"; - 193c294 - < Traffic Engineering Networks"; - --- - > Traffic Engineering Networks"; - 244,245c345,346 - < ITU-T Recommendation G.709: Interfaces for the - < optical transport network"; - --- - > ITU-T G.709: Interfaces for the optical transport network - - - - -Busi, et al. Expires 31 March 2025 [Page 159] - -Internet-Draft TE Common YANG Types September 2024 - - - > Edition 6.0 (06/2020)"; - 256c357 - < MPLS Traffic Engineering, Section 4.3.1"; - --- - > MPLS Traffic Engineering, Section 4.3.1"; - 263a365 - > - 264a367 - > - 269c372 - < Aggregation - --- - > Aggregation - 288c391 - < Section 4.3.3"; - --- - > Section 4.3.3"; - 306c409 - < Version 2"; - --- - > Version 2"; - 349c452 - < second MPLS Traffic Engineering (TE) Metric"; - --- - > second MPLS Traffic Engineering (TE) Metric"; - 351a455,457 - > // CHANGE NOTE: The typedef te-node-id below has been - > // updated in this module revision - > // RFC Editor: remove the note above and this note - 353c459,462 - < type yang:dotted-quad; - --- - > type union { - > type yang:dotted-quad; - > type inet:ipv6-address-no-zone; - > } - 357,358c466,470 - < The identifier is represented as 4 octets in dotted-quad - < notation. - --- - > - > The identifier is represented either as 4 octets in - > dotted-quad notation, or as 16 octets in full, mixed, - > shortened, or shortened-mixed IPv6 address notation. - > - 362,363c474,477 - < 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. - - - -Busi, et al. Expires 31 March 2025 [Page 160] - -Internet-Draft TE Common YANG Types September 2024 - - - --- - > 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. - > - 368c482 - < Version 2, Section 2.4.1 - --- - > Version 2, Section 2.4.1 - 370c484 - < Section 4.3 - --- - > Section 4.3 - 373c487 - < Routing for OSPFv2 Protocols, Section 3"; - --- - > Routing for OSPFv2 Protocols, Section 3"; - 412c526,527 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 472c587,588 - < for Generalized Multi-Protocol Label Switching (GMPLS) - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS) - 519a636 - > - 537a655 - > - 542c660 - < Version 2 - --- - > Version 2 - 545a664,691 - > // 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 - > "Indicates that the TE path is a secondary path."; - - - -Busi, et al. Expires 31 March 2025 [Page 161] - -Internet-Draft TE Common YANG Types September 2024 - - - > } - > 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."; - > } - > - 553,554c699,700 - < Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE - < Label Switched Paths (LSPs)"; - --- - > Traffic Engineering (RSVP-TE) for - > Point-to-Multipoint TE Label Switched Paths (LSPs)"; - 570c716 - < Engineering (MPLS-TE)"; - --- - > Engineering (MPLS-TE)"; - 606a753,760 - > // 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."; - > } - > - 618c772 - < Section 4.7.1"; - --- - > Section 4.7.1"; - 636c790 - < Section 4.7.1"; - --- - > Section 4.7.1"; - 664,665c818,819 - < (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched - < Path (LSP)"; - --- - > (MPLS) Traffic Engineering (TE) Loosely Routed Label - - - -Busi, et al. Expires 31 March 2025 [Page 162] - -Internet-Draft TE Common YANG Types September 2024 - - - > Switched Path (LSP)"; - 690c844 - < RSVP-TE - --- - > RSVP-TE - 692,693c846,847 - < Using Resource Reservation Protocol Traffic Engineering - < (RSVP-TE) - --- - > Using Resource Reservation Protocol Traffic - > Engineering (RSVP-TE) - 695c849 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 711c865 - < RSVP-TE - --- - > RSVP-TE - 713,714c867,868 - < Using Resource Reservation Protocol Traffic Engineering - < (RSVP-TE) - --- - > Using Resource Reservation Protocol Traffic - > Engineering (RSVP-TE) - 716c870 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 727c881 - < RSVP-TE - --- - > RSVP-TE - 729,730c883,884 - < Using Resource Reservation Protocol Traffic Engineering - < (RSVP-TE) - --- - > Using Resource Reservation Protocol - > Traffic Engineering (RSVP-TE) - 732c886 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 741,742c895,896 - < Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE - < Label Switched Paths (LSPs) - --- - > Traffic Engineering (RSVP-TE) for - - - -Busi, et al. Expires 31 March 2025 [Page 163] - -Internet-Draft TE Common YANG Types September 2024 - - - > Point-to-Multipoint TE Label Switched Paths (LSPs) - 744c898 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 753,754c907,908 - < Resource Reservation Protocol-Traffic Engineering (RSVP-TE) - < Extensions - --- - > Resource Reservation Protocol-Traffic Engineering - > (RSVP-TE) Extensions - 756c910 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 765c919,920 - < Multiprotocol Label Switching Traffic Engineering (GMPLS TE) - --- - > Multiprotocol Label Switching Traffic Engineering - > (GMPLS TE) - 767c922 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 777c932 - < Multi-Layer and Multi-Region Networks (MLN/MRN) - --- - > Multi-Layer and Multi-Region Networks (MLN/MRN) - 779c934 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 789c944 - < Mapping for RSVP-TE Label Switched Paths - --- - > Mapping for RSVP-TE Label Switched Paths - 791c946 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 801c956 - < Mapping for RSVP-TE Label Switched Paths - --- - > Mapping for RSVP-TE Label Switched Paths - 803c958 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - - - -Busi, et al. Expires 31 March 2025 [Page 164] - -Internet-Draft TE Common YANG Types September 2024 - - - 813c968 - < Route Object (ERO)"; - --- - > Route Object (ERO)"; - 823c978,979 - < Administration, and Maintenance (OAM) Configuration"; - --- - > Administration, and Maintenance (OAM) - > Configuration"; - 833c989,990 - < Administration, and Maintenance (OAM) Configuration"; - --- - > Administration, and Maintenance (OAM) - > Configuration"; - 842c999 - < Route Object (ERO) - --- - > Route Object (ERO) - 844c1001 - < Link Group (SRLG) Information"; - --- - > Link Group (SRLG) Information"; - 855c1012 - < Loopback"; - --- - > Loopback"; - 864,865c1021,1022 - < Point-to-Multipoint Traffic Engineering Label Switched Paths - < (LSPs)"; - --- - > Point-to-Multipoint Traffic Engineering Label - > Switched Paths (LSPs)"; - 887c1044,1045 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 896c1054,1055 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 905c1064,1065 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 914c1074,1075 - - - -Busi, et al. Expires 31 March 2025 [Page 165] - -Internet-Draft TE Common YANG Types September 2024 - - - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 923c1084,1085 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 945c1107,1108 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery - 967c1130 - < Label Switched Paths (LSPs)"; - --- - > Label Switched Paths (LSPs)"; - 980c1143 - < Label Switched Paths (LSPs)"; - --- - > Label Switched Paths (LSPs)"; - 982a1146,1163 - > // 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; - > 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 - 985c1166 - < "Base objective function type."; - --- - > "Base identity for path objective function types."; - 994c1175 - < Computation Element Communication Protocol (PCEP)"; - --- - - - -Busi, et al. Expires 31 March 2025 [Page 166] - -Internet-Draft TE Common YANG Types September 2024 - - - > Computation Element Communication Protocol (PCEP)"; - 1004c1185 - < Computation Element Communication Protocol (PCEP)"; - --- - > Computation Element Communication Protocol (PCEP)"; - 1013c1194 - < Computation Element Communication Protocol (PCEP)"; - --- - > Computation Element Communication Protocol (PCEP)"; - 1015a1197,1199 - > // 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 - 1017a1202 - > status obsolete; - 1020c1205,1209 - < consumption."; - --- - > consumption. - > - > This identity has been obsoleted: the - > 'svec-of-minimize-agg-bandwidth-consumption' identity SHOULD - > be used instead."; - 1023c1212 - < Computation Element Communication Protocol (PCEP)"; - --- - > Computation Element Communication Protocol (PCEP)"; - 1025a1215,1217 - > // 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 - 1027a1220 - > status obsolete; - 1030c1223,1227 - < is carrying the highest load."; - --- - > is carrying the highest load. - > - > This identity has been obsoleted: the - > 'svec-of-minimize-load-most-loaded-link' identity SHOULD - > be used instead."; - 1033c1230 - < Computation Element Communication Protocol (PCEP)"; - --- - > Computation Element Communication Protocol (PCEP)"; - 1035a1233,1235 - > // CHANGE NOTE: The identity of-minimize-cost-path-set - > // below has been obsoleted in this module revision - - - -Busi, et al. Expires 31 March 2025 [Page 167] - -Internet-Draft TE Common YANG Types September 2024 - - - > // RFC Editor: remove the note above and this note - 1037a1238 - > status obsolete; - 1039c1240,1244 - < "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."; - 1042c1247 - < Computation Element Communication Protocol (PCEP)"; - --- - > Computation Element Communication Protocol (PCEP)"; - 1049a1255,1257 - > // 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,1057c1264,1265 - < "RFC 3272: Overview and Principles of Internet Traffic - < Engineering, Section 5.4"; - --- - > "RFC 9522: Overview and Principles of Internet Traffic - > Engineering, Section 4.4"; - 1059a1268,1271 - > // 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 - 1071,1072c1283,1284 - < "RFC 3272: Overview and Principles of Internet Traffic - < Engineering - --- - > "RFC 9522: Overview and Principles of Internet Traffic - > Engineering - 1074c1286 - < Protocol Generic Requirements"; - --- - > Protocol Generic Requirements"; - 1076a1289,1292 - > // 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 - 1085,1086c1301,1302 - < RFC 3272: Overview and Principles of Internet Traffic - < Engineering"; - - - -Busi, et al. Expires 31 March 2025 [Page 168] - -Internet-Draft TE Common YANG Types September 2024 - - - --- - > RFC 9522: Overview and Principles of Internet Traffic - > Engineering"; - 1102c1318 - < Protocol Generic Requirements"; - --- - > Protocol Generic Requirements"; - 1112c1328 - < Protocol Generic Requirements"; - --- - > Protocol Generic Requirements"; - 1123c1339 - < Protocol Generic Requirements"; - --- - > Protocol Generic Requirements"; - 1145,1146c1361,1362 - < Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE - < Label Switched Paths (LSPs)"; - --- - > Traffic Engineering (RSVP-TE) for - > Point-to-Multipoint TE Label Switched Paths (LSPs)"; - 1216a1433,1444 - > // 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."; - > } - > - 1305c1533 - < Section 2.5"; - --- - > Section 2.5"; - 1314c1542 - < Section 2.5"; - --- - > Section 2.5"; - 1321a1550,1558 - > // 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; - - - -Busi, et al. Expires 31 March 2025 [Page 169] - -Internet-Draft TE Common YANG Types September 2024 - - - > description - > "No LSP affected by a failure is restored."; - > } - > - 1339a1577,1592 - > // 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)"; - > } - > - 1346c1599,1600 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1355c1609,1610 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1364c1619,1620 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1372c1628,1629 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 1381c1638,1639 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 1383a1642,1644 - > // CHANGE NOTE: The identity lsp-protection-reroute-extra - - - -Busi, et al. Expires 31 March 2025 [Page 170] - -Internet-Draft TE Common YANG Types September 2024 - - - > // below has been obsoleted in this module revision - > // RFC Editor: remove the note above and this note - 1385a1647 - > status obsolete; - 1387c1649,1653 - < "'(Full) Rerouting' LSP protection type."; - --- - > "'(Full) Rerouting' LSP protection type. - > - > This identity has been obsoleted: the - > 'restoration-scheme-rerouting' identity SHOULD be used - > instead."; - 1390c1656,1657 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 1392a1660,1662 - > // CHANGE NOTE: The identity lsp-protection-reroute - > // below has been obsoleted in this module revision - > // RFC Editor: remove the note above and this note - 1394a1665 - > status obsolete; - 1396c1667,1671 - < "'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."; - 1399c1674,1675 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 1408c1684,1685 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 1417c1694,1695 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 1426c1704,1705 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - - - -Busi, et al. Expires 31 March 2025 [Page 171] - -Internet-Draft TE Common YANG Types September 2024 - - - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 1435c1714,1715 - < Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; - --- - > Generalized Multi-Protocol Label Switching (GMPLS) - > Recovery"; - 1444c1724,1725 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1466c1747,1748 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1475c1757,1758 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1484c1767,1768 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1494c1778,1779 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1504c1789,1790 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1513c1799,1800 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1522c1809,1810 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - - - -Busi, et al. Expires 31 March 2025 [Page 172] - -Internet-Draft TE Common YANG Types September 2024 - - - 1532c1820,1821 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1542c1831,1832 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1559c1849,1850 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1568c1859,1860 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1579c1871,1872 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1589c1882,1883 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1601c1895,1896 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1613c1908,1909 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1626c1922,1923 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1628a1926,1929 - > // CHANGE NOTE: The description and reference of the - > // identity action-exercise have been updated in this module - - - -Busi, et al. Expires 31 March 2025 [Page 173] - -Internet-Draft TE Common YANG Types September 2024 - - - > // revision - > // RFC Editor: remove the note above and this note - 1632,1633c1933,1935 - < "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,1637c1938,1939 - < "RFC 4427: Recovery (Protection and Restoration) Terminology - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > "ITU-T G.808.1: Generic protection switching - Linear trail and - > subnetwork protection - Edition 4.0 (05/2014)"; - 1648c1950,1951 - < for Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > for Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 1656c1959 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1665c1968 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1674c1977 - < Forum and G.8011 Ethernet Service Switching"; - --- - > Forum and G.8011 Ethernet Service Switching"; - 1683c1986 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1692c1995 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1701c2004,2005 - < Control of Evolving G.709 Optical Transport Networks"; - --- - > Control of Evolving G.709 Optical Transport - > Networks"; - 1710c2014,2015 - < Switching Capable (DCSC) and Channel Set Label Extensions"; - --- - - - -Busi, et al. Expires 31 March 2025 [Page 174] - -Internet-Draft TE Common YANG Types September 2024 - - - > Switching Capable (DCSC) and Channel Set Label - > Extensions"; - 1719c2024 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1728c2033 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1736c2041 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1745c2050 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1754c2059 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1763c2068 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1772c2077 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1781c2086 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1790c2095 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1799c2104 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1808c2113 - < Signaling Functional Description"; - --- - > Signaling Functional Description"; - 1817,1818c2122,2123 - < Signaling Extensions for G.709 Optical Transport Networks - - - -Busi, et al. Expires 31 March 2025 [Page 175] - -Internet-Draft TE Common YANG Types September 2024 - - - < Control"; - --- - > Signaling Extensions for G.709 Optical Transport - > Networks Control"; - 1827,1828c2132,2133 - < Signaling Extensions for G.709 Optical Transport Networks - < Control"; - --- - > Signaling Extensions for G.709 Optical Transport - > Networks Control"; - 1837c2142,2143 - < Ethernet Forum and G.8011 Ethernet Service Switching"; - --- - > Ethernet Forum and G.8011 Ethernet Service - > Switching"; - 1905c2211 - < Protocol-Traffic Engineering (RSVP-TE)"; - --- - > Protocol-Traffic Engineering (RSVP-TE)"; - 1914c2220 - < Protocol-Traffic Engineering (RSVP-TE)"; - --- - > Protocol-Traffic Engineering (RSVP-TE)"; - 1917c2223,2226 - < 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 { - 1919c2228,2229 - < "Base identity for the path metric type."; - --- - > "Base identity used to define the path metric optimization - > types."; - 1922,1923c2232,2235 - < 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,1928c2237,2243 - < "TE path metric."; - < reference - < "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a - < second MPLS Traffic Engineering (TE) Metric"; - - - -Busi, et al. Expires 31 March 2025 [Page 176] - -Internet-Draft TE Common YANG Types September 2024 - - - --- - > "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,1938c2246,2254 - < 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,1944c2256,2265 - < identity path-metric-hop { - < base path-metric-type; - < 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 - > RFC 5305: IS-IS Extensions for Traffic Engineering, - > Section 3.7"; - > } - 1946,1952c2267,2275 - < identity path-metric-delay-average { - < base path-metric-type; - < description - - - -Busi, et al. Expires 31 March 2025 [Page 177] - -Internet-Draft TE Common YANG Types September 2024 - - - < "Average 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"; - > } - 1954,1960c2277,2287 - < 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-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"; - > } - 1962,1972c2289,2299 - < 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 - < "RFC 3630: Traffic Engineering (TE) Extensions to OSPF - < Version 2 - < RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; - < } - --- - > identity link-metric-delay-minimum { - - - -Busi, et al. Expires 31 March 2025 [Page 178] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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"; - > } - 1974,1979c2301,2311 - < 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-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"; - > } - 1981,1986c2313,2447 - < 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-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 - - - -Busi, et al. Expires 31 March 2025 [Page 179] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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"; - > } - > - > // 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 - - - -Busi, et al. Expires 31 March 2025 [Page 180] - -Internet-Draft TE Common YANG Types September 2024 - - - > "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 { - > base path-metric-type; - > description - > "The Path Min Delay Metric, measured in units of - > microseconds."; - > reference - > "RFC YYYY: Carrying SR-Algorithm information in PCE-based - > Networks, Section 3.5.1"; - > } - > // RFC Editor: replace YYYY with actual RFC number assigned to - > // [I-D.ietf-pce-sid-algo] and remove this note - > - > // 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. - > - - - -Busi, et al. Expires 31 March 2025 [Page 181] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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."; - > } - 1996c2457,2458 - < "Min-Fill LSP path placement."; - --- - > "Min-Fill LSP path placement: selects the path with the most - > available bandwidth (load balance LSPs over more links)."; - 2002c2464,2465 - < "Max-Fill LSP path placement."; - --- - > "Max-Fill LSP path placement: selects the path with the least - > available bandwidth (packing more LSPs over few links)."; - 2049a2513,2516 - > // 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 - 2054,2055c2521,2522 - < "RFC 3272: Overview and Principles of Internet Traffic - < Engineering"; - --- - > "RFC 9522: Overview and Principles of Internet Traffic - - - -Busi, et al. Expires 31 March 2025 [Page 182] - -Internet-Draft TE Common YANG Types September 2024 - - - > Engineering"; - 2070c2537 - < Computation Element Communication Protocol (PCEP)"; - --- - > Computation Element Communication Protocol (PCEP)"; - 2079c2546 - < Computation Element Communication Protocol (PCEP)"; - --- - > Computation Element Communication Protocol (PCEP)"; - 2110a2578,3029 - > // 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 - - - -Busi, et al. Expires 31 March 2025 [Page 183] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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. - > - > 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; - - - -Busi, et al. Expires 31 March 2025 [Page 184] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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 - > /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"; - > } - - - -Busi, et al. Expires 31 March 2025 [Page 185] - -Internet-Draft TE Common YANG Types September 2024 - - - > - > 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 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 - - - -Busi, et al. Expires 31 March 2025 [Page 186] - -Internet-Draft TE Common YANG Types September 2024 - - - > - > 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."; - > 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."; - - - -Busi, et al. Expires 31 March 2025 [Page 187] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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. - > - > 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; - - - -Busi, et al. Expires 31 March 2025 [Page 188] - -Internet-Draft TE Common YANG Types September 2024 - - - > description - > "Protocol origin is via Application Programming 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)"; - > } - > - > identity protocol-origin-bgp { - > base protocol-origin-type; - > description - > "Protocol origin is Border Gateway Protocol (BGP)."; - > reference - > "RFC 9012: The BGP Tunnel Encapsulation Attribute"; - > } - > - > // 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; - - - -Busi, et al. Expires 31 March 2025 [Page 189] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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)"; - > } - > - > 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 - - - -Busi, et al. Expires 31 March 2025 [Page 190] - -Internet-Draft TE Common YANG Types September 2024 - - - > "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 - > 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)"; - > } - > - - - -Busi, et al. Expires 31 March 2025 [Page 191] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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."; - > reference - > "RFC 5541: Encoding of Objective Functions in the Path - > Computation Element Communication Protocol - > (PCEP)"; - > } - > - 2223,2224c3142,3143 - < Routed Label Switched Paths (LSPs) Using TE Metric - < Extensions - --- - > Routed Label Switched Paths (LSPs) Using TE Metric - > Extensions - 2248,2249c3167,3168 - < Routed Label Switched Paths (LSPs) Using TE Metric - < Extensions - --- - > Routed Label Switched Paths (LSPs) Using TE Metric - > Extensions - 2273,2274c3192,3193 - < Routed Label Switched Paths (LSPs) Using TE Metric - < Extensions - --- - > Routed Label Switched Paths (LSPs) Using TE Metric - > Extensions - - - -Busi, et al. Expires 31 March 2025 [Page 192] - -Internet-Draft TE Common YANG Types September 2024 - - - 2286c3205 - < Version 2"; - --- - > Version 2"; - 2350c3269 - < Version 2"; - --- - > Version 2"; - 2405,2406c3324,3325 - < Routed Label Switched Paths (LSPs) Using TE Metric - < Extensions - --- - > Routed Label Switched Paths (LSPs) Using TE Metric - > Extensions - 2416c3335 - < Networks"; - --- - > Networks"; - 2437,2438c3356,3357 - < Routed Label Switched Paths (LSPs) Using TE Metric - < Extensions - --- - > Routed Label Switched Paths (LSPs) Using TE Metric - > Extensions - 2472c3391 - < Extensions, Section 6"; - --- - > Extensions, Section 6"; - 2506a3426,3428 - > // CHANGE NOTE: The explicit-route-hop grouping below has been - > // updated in this module revision - > // RFC Editor: remove the note above and this note - 2514a3437,3445 - > 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."; - > } - 2517d3447 - < mandatory true; - 2531c3461 - < Section 4.3, EXPLICIT_ROUTE in RSVP-TE - --- - > Section 4.3, EXPLICIT_ROUTE in RSVP-TE - - - -Busi, et al. Expires 31 March 2025 [Page 193] - -Internet-Draft TE Common YANG Types September 2024 - - - 2533c3463,3464 - < ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; - --- - > ReSerVation Protocol - Traffic Engineering - > (RSVP-TE)"; - 2560c3491 - < Section 4.3, EXPLICIT_ROUTE in RSVP-TE - --- - > Section 4.3, EXPLICIT_ROUTE in RSVP-TE - 2562c3493,3494 - < ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; - --- - > ReSerVation Protocol - Traffic Engineering - > (RSVP-TE)"; - 2566a3499,3509 - > 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."; - > } - 2569d3511 - < mandatory true; - 2574a3517,3521 - > leaf node-id-uri { - > type nw:node-id; - > description - > "The identifier of a node in the topology."; - > } - 2577d3523 - < mandatory true; - 2597c3543 - < Section 4.3, EXPLICIT_ROUTE in RSVP-TE - --- - > Section 4.3, EXPLICIT_ROUTE in RSVP-TE - 2599c3545,3546 - < ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; - --- - > ReSerVation Protocol - Traffic Engineering - > (RSVP-TE)"; - 2631a3579,3581 - > // CHANGE NOTE: The explicit-route-hop grouping below has been - > // updated in this module revision - - - -Busi, et al. Expires 31 March 2025 [Page 194] - -Internet-Draft TE Common YANG Types September 2024 - - - > // RFC Editor: remove the note above and this note - 2646a3597,3600 - > must "node-id-uri or node-id" { - > description - > "At least one node identifier MUST be present."; - > } - 2648a3603,3607 - > leaf node-id-uri { - > type nw:node-id; - > description - > "The identifier of a node in the topology."; - > } - 2651d3609 - < mandatory true; - 2662c3620 - < Tunnels - --- - > Tunnels - 2664c3622 - < Node-Id Sub-Object"; - --- - > Node-Id Sub-Object"; - 2687c3645 - < Tunnels - --- - > Tunnels - 2689c3647 - < Node-Id Sub-Object"; - --- - > Node-Id Sub-Object"; - 2696a3655,3665 - > 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."; - > } - 2699d3667 - < mandatory true; - 2704a3673,3677 - > leaf node-id-uri { - > type nw:node-id; - > description - - - -Busi, et al. Expires 31 March 2025 [Page 195] - -Internet-Draft TE Common YANG Types September 2024 - - - > "The identifier of a node in the topology."; - > } - 2717c3690 - < Tunnels - --- - > Tunnels - 2719c3692 - < Node-Id Sub-Object"; - --- - > Node-Id Sub-Object"; - 2725c3698,3699 - < ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; - --- - > ReSerVation Protocol - Traffic Engineering - > (RSVP-TE)"; - 2742c3716 - < Tunnels - --- - > Tunnels - 2744c3718 - < Node-Id Sub-Object"; - --- - > Node-Id Sub-Object"; - 2842a3817,3827 - > - > In case the restriction is 'inclusive', the bit-position is - > set if the corresponding mapped label is available. - > In this case, if the range-bitmap is not present, all the - > labels in the range are available. - > - > In case the restriction is 'exclusive', the bit-position is - > set if the corresponding mapped label is not available. - > In this case, if the range-bitmap is not present, all the - > labels in the range are not available. - > - 2876c3861 - < for GMPLS-Controlled Networks"; - --- - > for GMPLS-Controlled Networks"; - 2881a3867,3869 - > // CHANGE NOTE: The grouping optimization-metric-entry below has - > // been updated in this module revision - > // RFC Editor: remove the note above and this note - 2887c3875 - < base path-metric-type; - --- - > base path-metric-optimization-type; - 2933c3921,3922 - - - -Busi, et al. Expires 31 March 2025 [Page 196] - -Internet-Draft TE Common YANG Types September 2024 - - - < Generalized Multi-Protocol Label Switching (GMPLS)"; - --- - > Generalized Multi-Protocol Label Switching - > (GMPLS)"; - 2964a3954,3956 - > // CHANGE NOTE: The grouping tunnel-constraints below has - > // been updated in this module revision - > // RFC Editor: remove the note above and this note - 2968a3961,3965 - > leaf network-id { - > type nw:network-id; - > description - > "The network topology identifier."; - > } - 2972a3970,3972 - > // 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 - 2977c3977 - < container explicit-route-objects-always { - --- - > container explicit-route-objects { - 2979c3979 - < "Container for the 'exclude route' object list."; - --- - > "Container for the explicit route object lists."; - 3101a4102,4104 - > // 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 - 3107c4110 - < "TE path metric bounds container."; - --- - > "Top-level container for the list of path metric bounds."; - 3111c4114,4122 - < "List of TE path metric bounds."; - --- - > "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."; - 3114c4125 - < base path-metric-type; - - - -Busi, et al. Expires 31 March 2025 [Page 197] - -Internet-Draft TE Common YANG Types September 2024 - - - --- - > base link-path-metric-type; - 3124,3126c4135,4141 - < "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."; - 3131a4147,4149 - > // 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 - 3152a4171 - > status deprecated; - 3154c4173,4176 - < "Container for the list of tiebreakers."; - --- - > "Container for the list of tiebreakers. - > - > This container has been deprecated by the tiebreaker - > leaf."; - 3156a4179 - > status deprecated; - 3164a4188 - > status deprecated; - 3189a4214,4222 - > 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."; - > } - 3376a4410,4478 - > } - > } - > - > // NOTE: The grouping encoding-and-switching-type below has been - > // added in this module revision - > // RFC Editor: remove the note above and this note - - - -Busi, et al. Expires 31 March 2025 [Page 198] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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: Generalized Multi-Protocol Label Switching (GMPLS) - > Architecture"; - > } - > leaf switching-type { - > type identityref { - > base te-types:switching-capabilities; - > } - > description - > "LSP switching type."; - > reference - > "RFC 3945: Generalized Multi-Protocol Label Switching (GMPLS) - > Architecture"; - > } - > } - > - > // CHANGE NOTE: The grouping te-generic-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 union { - > type te-node-id; - > type inet:ip-address; - > type nw:node-id; - > } - > description - > "The identifier of the node. - > - > It can be represented as IP address or dotted quad address - > or as an URI. - > - > The type data node disambiguates the union type."; - > } - > leaf type { - > type enumeration { - - - -Busi, et al. Expires 31 March 2025 [Page 199] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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."; - -B.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: - - 6c6,10 - < /* Import TE generic types */ - --- - > import ietf-yang-types { - > prefix yang; - > reference - > "RFC 6991: Common YANG Data Types"; - > } - 11c15 - - - -Busi, et al. Expires 31 March 2025 [Page 200] - -Internet-Draft TE Common YANG Types September 2024 - - - < "RFC 8776: Common YANG Data Types for Traffic Engineering"; - --- - > "RFC XXXX: Common YANG Data Types for Traffic Engineering"; - 12a17,18 - > // RFC Editor: replace XXXX with actual RFC number - > // and remove this note - 22c28 - < - --- - > - 37,39c43,53 - < 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. - 41c55 - < Copyright (c) 2020 IETF Trust and the persons identified as - --- - > Copyright (c) 2024 IETF Trust and the persons identified as - 46c60 - < the license terms contained in, the Simplified BSD License set - --- - > the license terms contained in, the Revised BSD License set - 51,52c65,87 - < 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-09-27 { - > description - > "This revision adds the following new identities: - > - bandwidth-profile-type; - > - link-metric-delay-variation; - > - link-metric-loss; - > - path-metric-delay-variation; - - - -Busi, et al. Expires 31 March 2025 [Page 201] - -Internet-Draft TE Common YANG Types September 2024 - - - > - path-metric-loss. - > - > This revision adds the following new groupings: - > - bandwidth-profile-parameters; - > - 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 - 61c96,202 - < /** - --- - > /* - > * 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 { - > base bandwidth-profile-type; - > description - > "MEF 10 Bandwidth Profile"; - > reference - > "MEF 10.3: Ethernet Services Attributes Phase 3"; - > } - > - > identity rfc-2697 { - > base bandwidth-profile-type; - > description - > "RFC 2697 Bandwidth Profile"; - > reference - > "RFC 2697: A Single Rate Three Color Marker"; - > } - > - > identity rfc-2698 { - > base bandwidth-profile-type; - > description - - - -Busi, et al. Expires 31 March 2025 [Page 202] - -Internet-Draft TE Common YANG Types September 2024 - - - > "RFC 2698 Bandwidth Profile"; - > reference - > "RFC 2698: A Two Rate Three Color Marker"; - > } - > - > identity rfc-4115 { - > base bandwidth-profile-type; - > description - > "RFC 4115 Bandwidth Profile"; - > reference - > "RFC 4115: 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 - > "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, - > Section 4.3 - > RFC 8570: 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 - > "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, - > Section 4.4 - > RFC 8570: 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 - - - -Busi, et al. Expires 31 March 2025 [Page 203] - -Internet-Draft TE Common YANG Types September 2024 - - - > identity path-metric-delay-variation { - > base te-types:path-metric-type; - > description - > "The Path Delay Variation Metric, - > measured in units of microseconds."; - > reference - > "RFC 8233: 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 - > "RFC 8233: Extensions to the Path Computation Element - > Communication Protocol (PCEP) to Compute - > Service-Aware Label Switched Paths (LSPs), - > Section 3.1.3"; - > } - > - > /* - 67c208,212 - < enum specified { - --- - > enum specified-value { - > description - > "Bandwidth value is explicitly specified."; - > } - > enum specified-profile { - 69c214 - < "Bandwidth is explicitly specified."; - --- - > "Bandwidth profile is explicitly specified."; - 91c236 - < MPLS Traffic Engineering"; - --- - > MPLS Traffic Engineering"; - 102c247 - < MPLS Traffic Engineering"; - --- - > MPLS Traffic Engineering"; - 149c294 - - - -Busi, et al. Expires 31 March 2025 [Page 204] - -Internet-Draft TE Common YANG Types September 2024 - - - < MPLS Traffic Engineering"; - --- - > MPLS Traffic Engineering"; - 177,178c322,323 - < Constraints Model for Diffserv-aware MPLS Traffic Engineering - < & Performance Comparisons"; - --- - > Constraints Model for Diffserv-aware MPLS Traffic - > Engineering & Performance Comparisons"; - 180a326,329 - > /* - > * Groupings - > */ - > - 220c369 - < Statement, Section 4.2"; - --- - > Statement, Section 4.2"; - 229c378 - < Extensions - --- - > Extensions - 231,232c380,381 - < Explicitly Routed Label Switched Paths (LSPs) Using - < TE Metric Extensions - --- - > Explicitly Routed Label Switched Paths (LSPs) - > Using TE Metric Extensions - 234c383 - < Extensions"; - --- - > Extensions"; - 247c396 - < Extensions, Section 4.4"; - --- - > Extensions, Section 4.4"; - 256c405 - < Extensions - --- - > Extensions - 258,259c407,408 - < Explicitly Routed Label Switched Paths (LSPs) Using - < TE Metric Extensions - --- - > Explicitly Routed Label Switched Paths (LSPs) - > Using TE Metric Extensions - 261c410 - < Extensions"; - - - -Busi, et al. Expires 31 March 2025 [Page 205] - -Internet-Draft TE Common YANG Types September 2024 - - - --- - > Extensions"; - 283c432 - < Extensions - --- - > Extensions - 285,286c434,435 - < Explicitly Routed Label Switched Paths (LSPs) Using - < TE Metric Extensions - --- - > Explicitly Routed Label Switched Paths (LSPs) - > Using TE Metric Extensions - 288c437 - < Extensions"; - --- - > Extensions"; - 305c454 - < Extensions - --- - > Extensions - 307,308c456,457 - < Explicitly Routed Label Switched Paths (LSPs) Using - < TE Metric Extensions - --- - > Explicitly Routed Label Switched Paths (LSPs) - > Using TE Metric Extensions - 310c459 - < Extensions"; - --- - > Extensions"; - 321c470 - < Statement, Section 4.2"; - --- - > Statement, Section 4.2"; - 330c479 - < Extensions - --- - > Extensions - 332,333c481,482 - < Explicitly Routed Label Switched Paths (LSPs) Using - < TE Metric Extensions - --- - > Explicitly Routed Label Switched Paths (LSPs) - > Using TE Metric Extensions - 335c484 - < Extensions"; - --- - > Extensions"; - - - -Busi, et al. Expires 31 March 2025 [Page 206] - -Internet-Draft TE Common YANG Types September 2024 - - - 358,363c507,513 - < "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"; - --- - > "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"; - 407a558,604 - > // CHANGE NOTE: The grouping - > // one-way-performance-metrics-gauge-packet has been added in - > // this module revision - > // RFC Editor: remove the note above and this note - > grouping one-way-performance-metrics-gauge-packet { - > description - > "One-way packet PM throttle grouping. - > - > This grouping is used to report the same metrics defined in - > the one-way-performance-metrics-packet grouping, using gauges - > instead of uint32 data types and referencing IPPM RFCs - > instead of IGP-TE RFCs."; - > leaf one-way-min-delay { - > type yang:gauge64; - > description - > "One-way minimum delay or latency in microseconds."; - > } - > leaf one-way-max-delay { - > type yang:gauge64; - > description - > "One-way maximum delay or latency in microseconds."; - > reference - > "RFC 7679: A One-Way Delay Metric for IP Performance - > Metrics (IPPM)"; - > } - > leaf one-way-delay-variation { - > type yang:gauge64; - > description - > "One-way delay variation in microseconds."; - > reference - > "RFC 3393: IP Packet Delay Variation Metric for IP - > Performance Metrics (IPPM)"; - - - -Busi, et al. Expires 31 March 2025 [Page 207] - -Internet-Draft TE Common YANG Types September 2024 - - - > } - > leaf one-way-packet-loss { - > type decimal64 { - > fraction-digits 5; - > range "0..100"; - > } - > description - > "The ratio of packets dropped to packets transmitted between - > two endpoints."; - > reference - > "RFC 7680: A One-Way Loss Metric for IP Performance - > Metrics (IPPM)"; - > } - > } - > - 447a645,688 - > // CHANGE NOTE: The grouping - > // two-way-performance-metrics-gauge-packet has been added in - > // this module revision - > // RFC Editor: remove the note above and this note - > grouping two-way-performance-metrics-gauge-packet { - > description - > "Two-way packet PM throttle grouping. - > - > This grouping is used to report the same metrics defined in - > the two-way-performance-metrics-packet grouping, using gauges - > instead of uint32 data types and referencing IPPM RFCs - > instead of IGP-TE RFCs."; - > leaf two-way-min-delay { - > type yang:gauge64; - > description - > "Two-way minimum delay or latency in microseconds."; - > reference - > "RFC 2681: A Round-trip Delay Metric for IPPM"; - > } - > leaf two-way-max-delay { - > type yang:gauge64; - > description - > "Two-way maximum delay or latency in microseconds."; - > reference - > "RFC 2681: A Round-trip Delay Metric for IPPM"; - > } - > leaf two-way-delay-variation { - > type yang:gauge64; - > description - > "Two-way delay variation in microseconds."; - > reference - > "RFC 5481: Packet Delay Variation Applicability Statement"; - - - -Busi, et al. Expires 31 March 2025 [Page 208] - -Internet-Draft TE Common YANG Types September 2024 - - - > } - > leaf two-way-packet-loss { - > type decimal64 { - > fraction-digits 5; - > range "0..100"; - > } - > description - > "The ratio of packets dropped to packets transmitted between - > two endpoints."; - > } - > } - > - 472a714,844 - > } - > } - > - > // CHANGE NOTE: The bandwidth-profile-parameters below has been - > // added in this module revision - > // RFC Editor: remove the note above and this note - > grouping bandwidth-profile-parameters { - > description - > "Common parameters to define bandwidth profiles in packet - > networks."; - > leaf cir { - > type uint64; - > units "bits/second"; - > description - > "Committed Information Rate (CIR)."; - > } - > leaf cbs { - > type uint64; - > units "bytes"; - > 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 { - - - -Busi, et al. Expires 31 March 2025 [Page 209] - -Internet-Draft TE Common YANG Types September 2024 - - - > 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-path-bandwidth { - > description - > "Bandwidth attributes for TE Packet paths."; - > container packet-bandwidth { - > description - > "Bandwidth attributes for TE Packet paths."; - > leaf specification-type { - > type te-bandwidth-requested-type; - > description - > "The bandwidth specification type, either explicitly - > specified or automatically computed."; - > } - > leaf set-bandwidth { - > when "../specification-type = 'specified-value'" { - > description - > "When the bandwidth value is explicitly specified."; - > } - > type bandwidth-kbps; - > description - > "Set the bandwidth value explicitly, e.g., using offline - > calculation."; - > } - > container bandwidth-profile { - > when "../specification-type = 'specified-profile'" { - > description - > "When the bandwidth profile is explicitly specified."; - > } - > description - > "Set the bandwidth profile attributes explicitly."; - > leaf bandwidth-profile-name { - > type string; - > description - - - -Busi, et al. Expires 31 March 2025 [Page 210] - -Internet-Draft TE Common YANG Types September 2024 - - - > "Name of Bandwidth Profile."; - > } - > leaf bandwidth-profile-type { - > type identityref { - > base bandwidth-profile-type; - > } - > description - > "Type of Bandwidth Profile."; - > } - > uses bandwidth-profile-parameters; - > } - > leaf class-type { - > type te-types:te-ds-class; - > description - > "The Class-Type of traffic transported by the LSP."; - > reference - > "RFC 4124: Protocol Extensions for Support of - > Diffserv-aware MPLS Traffic Engineering, - > Section 4.3.1"; - > } - > leaf signaled-bandwidth { - > type te-packet-types:bandwidth-kbps; - > config false; - > description - > "The currently signaled bandwidth of the LSP. - > - > In the case where the bandwidth is specified - > explicitly, then this will match the value of the - > set-bandwidth leaf. - > - > In the cases where the bandwidth is dynamically - > computed by the system, the current value of the - > bandwidth should be reflected."; - > } - > } - > } - > - > // 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 - > "Bandwidth attributes for Packet TE links."; - > leaf packet-bandwidth { - > type uint64; - > units "bits/second"; - > description - > "Bandwidth value for Packet TE links."; - - - -Busi, et al. Expires 31 March 2025 [Page 211] - -Internet-Draft TE Common YANG Types September 2024 - - -Appendix C. 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 31 March 2025 [Page 212] - -Internet-Draft TE Common YANG Types September 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. + + +Busi, et al. Expires 9 May 2025 [Page 152] + +Internet-Draft TE Common YANG Types November 2024 + Acknowledgements @@ -11921,23 +8555,29 @@ Authors' Addresses Email: xufeng.liu.ietf@gmail.com + Tarek Saad + Cisco Systems Inc. + Email: tsaad.net@gmail.com + + Igor Bryskin + Individual -Busi, et al. Expires 31 March 2025 [Page 213] +Busi, et al. Expires 9 May 2025 [Page 153] -Internet-Draft TE Common YANG Types September 2024 +Internet-Draft TE Common YANG Types November 2024 + + + Email: i_bryskin@yahoo.com + + + - Tarek Saad - Cisco Systems Inc. - Email: tsaad.net@gmail.com - Igor Bryskin - Individual - Email: i_bryskin@yahoo.com @@ -11981,4 +8621,4 @@ Internet-Draft TE Common YANG Types September 2024 -Busi, et al. Expires 31 March 2025 [Page 214] +Busi, et al. Expires 9 May 2025 [Page 154] diff --git a/drafts/te-types-update/draft-ietf-teas-rfc8776-update.xml b/drafts/te-types-update/draft-ietf-teas-rfc8776-update.xml index dd5ce38..397c859 100644 --- a/drafts/te-types-update/draft-ietf-teas-rfc8776-update.xml +++ b/drafts/te-types-update/draft-ietf-teas-rfc8776-update.xml @@ -1,6 +1,6 @@ - + - + TEAS Working Group @@ -57,6 +57,8 @@ + + This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. @@ -72,6 +74,8 @@ + +
Introduction YANG 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) or RESTCONF . The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. @@ -86,15 +90,12 @@ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they -appear in all capitals, as shown here. +appear in all capitals, as shown here. + The terminology for describing YANG data models is found in . -
  • - RFC Editor: The document uses "CHANGE NOTE" to ease identifying the changes vs. RFC8776. Please remove these notes. -
-
Tree Diagrams @@ -286,7 +287,7 @@ appear in all capitals, as shown here.
te-recovery-status:
- An enumerated type for the different statuses of a recovery action as defined in and . + An enumerated type for the different statuses of a recovery action as defined in and .
@@ -299,7 +300,7 @@ appear in all capitals, as shown here.
link-protection-type:
- A base YANG identity for supported link protection types as defined in and . + A base YANG identity for supported link protection types as defined in .
restoration-scheme-type:
@@ -307,37 +308,16 @@ appear in all capitals, as shown here.
protection-external-commands:
- A base YANG identity for supported protection-related external commands used for troubleshooting purposes, as defined in and . + A base YANG identity for supported protection-related external commands used for troubleshooting purposes, as defined in , , and .
- - -
  • - 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. -
- -
association-type:
A base YANG identity for supported LSP association types as defined in , , , and .
-
- -
  • - CHANGE NOTE: The association-type-diversity identity, defined in has been added to the association-type base identity. -
- -
objective-function-type:
A base YANG identity for supported path objective functions as defined in .
-
- -
  • - 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 and derived from the objective-function-type identity, have been obsoleted because not applicable to paths but to Synchronization VECtor (SVEC) objects. -
- -
te-tunnel-type:
A base YANG identity for supported TE tunnel types as defined in and . @@ -356,18 +336,11 @@ appear in all capitals, as shown here.
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 and . + 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 and .
-
- -
  • - CHANGE NOTE: The description of the path-metric-type has been updated -
- -
path-metric-type:
- A base YANG identity for supported path metric types as defined in , , , , , and . + A base YANG identity for supported path metric types as defined in , , , , , and .
@@ -385,13 +358,6 @@ appear in all capitals, as shown here.
An enumerated type for the different TE link access types as defined in .
-
- -
  • - CHANGE NOTE: The module "ietf-te-types" has been updated to add the following YANG identities, types and groupings. -
- -
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. @@ -418,14 +384,6 @@ appear in all capitals, as shown here.
-
  • - 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. -
-
Path Computation Errors The "ietf-te-types" module contains the YANG reusable identities for reporting path computation error reasons as defined in , , , , , and . @@ -449,7 +407,7 @@ appear in all capitals, as shown here. The derived identities are defined in the "ietf-te-types" module because there are error reasons which are: - + applicable only to the TE YANG models and not to PCEP environments (e.g., path-computation-error-no-topology); technology-specific (e.g., No RWA constraints met) which are better defined in technology-specific YANG models; match more than one PCEP numbers in order to hide the details of the underlay PCE architecture (e.g., path-computation-error-no-dependent-server). @@ -502,16 +460,9 @@ appear in all capitals, as shown here.
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. -
- -
bandwidth-profile-type:
- A base YANG identity for various bandwidth profiles specified in , , and that may be used to limit bandwidth utilization of packet flows (e.g., MPLS-TE LSPs). + A base YANG identity for various bandwidth profiles specified in , and that may be used to limit bandwidth utilization of packet flows (e.g., MPLS-TE LSPs).
bandwidth-profile-parameters:
@@ -547,13 +498,9 @@ appear in all capitals, as shown here. In addition to and , this module references the following documents in defining the types and YANG groupings: -, , , , , , , , , , , , , , and . - -
  • - CHANGE NOTE: Please focus your review only on the updates to the YANG model: see also . -
+, , , , , , , , , , , , , , , , and . -
The "ietf-te-packet-types" module imports from the "ietf-te-types" module defined in of this document. -
  • - CHANGE NOTE: Please focus your review only on the updates to the YANG model: see also . -
- -
-This document also requests IANA to update the following YANG modules to the "YANG Module -Names" registry : +This document requests IANA to register the following YANG modules in the "YANG Module Names" registry within the "YANG Parameters" registry group.
:
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 or RESTCONF . The lowest NETCONF layer - is the secure transport layer, and the mandatory-to-implement secure - transport is Secure Shell (SSH) . The lowest RESTCONF layer - is HTTPS, and the mandatory-to-implement secure transport is TLS - . +This section is modeled after the template described in Section 3.7 +of . + +The "ietf-te-types" and the "ietf-te-packet-types" YANG modules define data models that are +designed to be accessed via YANG-based management protocols, such as +NETCONF and RESTCONF . These protocols have to +use a secure transport layer (e.g., SSH , TLS , and +QUIC ) and have to use mutual authentication. The Network Configuration Access Control Model (NACM) - 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. +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 modules define a set of identities, types, and +groupings. These nodes are intended to be reused by other YANG +modules. The modules by themselves do not expose any data nodes that +are writable, data nodes that contain read-only state, or RPCs. +As such, there are no additional security issues related to +the YANG module that need to be considered. + +Modules that use the groupings that are defined in this document +should identify the corresponding security considerations. For +example, reusing some of these groupings will expose privacy-related +information (e.g., 'node-example').
@@ -5961,28 +5784,10 @@ Names" registry : - + + + - - - Generic protection switching - Linear trail and subnetwork protection - - ITU-T Recommendation G.808.1 - - - - - - - - Ethernet Services Attributes Phase 3 - - MEF - - - - - Interfaces for the optical transport network @@ -5995,167 +5800,136 @@ Names" registry : - + YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) - - + + YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] - - + + - + The YANG 1.1 Data Modeling Language - - + + YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). - - - - - - - Network Configuration Protocol (NETCONF) - - - - - - - The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] - - - - - - - - - RESTCONF Protocol - - - - - - This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). - - - - + + - + Common YANG Data Types for Traffic Engineering - - - - - - + + + + + + This document defines a collection of common data types 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. - - + + - + Key words for use in RFCs to Indicate Requirement Levels - - + + In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. - - - + + + - + Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words - - + + RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. - - - + + + - + Common YANG Data Types - - + + This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. - - + + - + Common YANG Data Types for the Routing Area - - - - - - + + + + + + This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. - - + + - + OSPF Traffic Engineering (TE) Metric Extensions - - - - - - + + + + + + In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. - - + + - + IS-IS Traffic Engineering (TE) Metric Extensions - - - - - - - + + + + + + + In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. @@ -6163,93 +5937,77 @@ Names" registry : This document obsoletes RFC 7810. - - - - - - - Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions - - - - - - - In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections. - - - - + + - + Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering - - + + This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK] - - + + - + MPLS Transport Profile (MPLS-TP) Identifiers - - - - + + + + This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK] - - + + - + Attachment Individual Identifier (AII) Types for Aggregation - - - - - + + + + + The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK] - - + + - + Traffic Engineering (TE) Extensions to OSPF Version 2 - - - - + + + + This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. - - + + - + Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols - - - - + + + + The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks. @@ -6257,253 +6015,224 @@ Names" registry : Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK] - - + + - + IS-IS Extensions for Traffic Engineering - - - + + + This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] - - + + - + IPv6 Traffic Engineering in IS-IS - - - - + + + + This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK] - - + + - + A YANG Data Model for Network Topologies - - - - - - - + + + + + + + This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. - - + + - + RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery - - - - + + + + This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK] - - + + - + Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) - - + + MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305). This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. - - + + - + OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) - - - + + + This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] - - + + - + IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) - - - + + + This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] - - + + - + Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric - - - - - - + + + + + + This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. - - - - - - - - Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) - - - - - This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community. - - - - + + + - + MPLS Transport Profile (MPLS-TP) Linear Protection - - - - - - + + + + + + This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK] - - + + - + RSVP-TE: Extensions to RSVP for LSP Tunnels - - - - - - - + + + + + + + This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] - - + + - + Fast Reroute Extensions to RSVP-TE for LSP Tunnels - - - - + + + + This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK] - - - - - - - Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) - - - - - - This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. This memo provides information for the Internet community. - - - - + + - + MPLS Traffic Engineering Soft Preemption - - - + + + This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK] - - + + - + Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE - - - - - - + + + + + + In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK] - - + + - + Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) - - - - - + + + + + Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. @@ -6511,233 +6240,271 @@ Names" registry : This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK] - - + + - + Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) - - - - - + + + + + RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop. - - + + - + Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) - - - - + + + + This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK] - - + + - + Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions - - - - + + + + This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK] - - + + - + Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) - - - - - + + + + + In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK] - - + + - + Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) - - - - - - + + + + + + There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK] - - + + - + The Use of Entropy Labels in MPLS Forwarding - - - - - - + + + + + + Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK] - - + + - + GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration - - - - + + + + Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling. - - + + - + RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information - - - - - - + + + + + + This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). - - + + - + RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) - - - - - - + + + + + + The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list. - - + + - + Residence Time Measurement in MPLS Networks - - - - - - - + + + + + + + This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain. Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message. - - + + + + + + + Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) + + + + + + + + This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK] + + + + + + + + + MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators + + + + + + + + + This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. + This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. + This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. + This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. + + + + - + RSVP ASSOCIATION Object Extensions - - - - + + + + The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK] - - + + - + GMPLS Segment Recovery - - - - - + + + + + This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK] - - + + - + Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling - - - - - + + + + + This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other. - - + + - + Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) - - - - + + + + The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.). In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE. @@ -6745,536 +6512,386 @@ Names" registry : This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK] - - + + - + Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description - - + + This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK] - - - - - - - Requirements for Traffic Engineering Over MPLS - - - - - - - - This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community. - - - - + + - + Path Computation Element (PCE) Communication Protocol (PCEP) - - - + + + This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] - - + + - + Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) - - - - - - + + + + + + In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation. - - - - - - - - Carrying SR-Algorithm Information in PCE-based Networks. - - Cisco Systems, Inc. - - - Cisco Systems, Inc. - - - ZTE Corporation - - - Huawei Technologies - - - Nokia - - - - The SR-Algorithm associated with a Segment-ID (SID) defines the path - computation algorithm used by Interior Gateway Protocols (IGPs). - This information is available to controllers, such as the Path - Computation Element (PCE), via topology learning. This document - proposes an approach for informing headend routers regarding the SR- - Algorithm associated with each SID used in PCE-computed paths, as - well as signaling a specific SR-Algorithm as a constraint to the PCE. - - - - - - - + + - + Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) - - - + + + Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK] - - - - - - - Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture - - - - - - - - The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. - This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures. - - - - - - - - - A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths - - - - - - - The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK] - - - - - - - - - Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism - - - - - - Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. - This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK] - - - - - - - - - Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization - - - - - - - The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. - This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK] - - - - - - - - - Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths - - - - - - - Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs. - This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. - This document obsoletes RFC 6006. - - - - - - - - - The BGP Tunnel Encapsulation Attribute - - - - - - - This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. - This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. - - - - - - - - - Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering - - - - - This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. This memo defines an Experimental Protocol for the Internet community. - - - - + + - + - Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons - - + Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture + + + + + + - This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. This memo defines an Experimental Protocol for the Internet community. + The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. + This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures. - - + + - + - Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering - - + A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths + + + + + - This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. This memo defines an Experimental Protocol for the Internet community. + The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK] - - + + - + - A Single Rate Three Color Marker - - - + Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism + + + + - This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community. + Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. + This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK] - - + + - + - A Two Rate Three Color Marker - - - + Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization + + + + + - This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community. + The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. + This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK] - - + + - + - A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic - - - + Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths + + + + + - This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community. + Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs. + This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. + This document obsoletes RFC 6006. - - + + - + - Overview and Principles of Internet Traffic Engineering - - + The BGP Tunnel Encapsulation Attribute + + + + + - This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. - This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. + This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. + This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. - - + + - + Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) - - - + + + This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK] - - + + - + Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control - - + + This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK] - - + + - + Definition of a Record Route Object (RRO) Node-Id Sub-Object - - - - + + + + In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK] - - - - - - - Path Computation Element (PCE) Communication Protocol Generic Requirements - - - - - The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community. - - - - + + - + Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching - - - + + + - - + + - + Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths - - - - + + + + There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK] - - + + - + GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks - - - - - - + + + + + + ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility. This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex. - - + + - + RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) - - - - + + + + This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case. - - + + - + GMPLS RSVP-TE Extensions for Lock Instruct and Loopback - - - - - + + + + + This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane. - - + + - + General Network Element Constraint Encoding for GMPLS-Controlled Networks - - - - - - + + + + + + Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. - - + + - + - Using the NETCONF Protocol over Secure Shell (SSH) - - + Network Configuration Access Control Model + + + - This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] + The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. + This document obsoletes RFC 6536. - - + + + - + + + + + + + + - The Transport Layer Security (TLS) Protocol Version 1.3 - - + Ethernet Services Attributes Phase 3 + + MEF + + + + + + + + + + Network Configuration Protocol (NETCONF) + + + + + - This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. - This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. + The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] - - + + - + - Network Configuration Access Control Model - - - + RESTCONF Protocol + + + + - The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. - This document obsoletes RFC 6536. + This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). - - - + + - - - - - - - - - - + Guidelines for Authors and Reviewers of Documents Containing YANG Data Models - + YumaWorks - + Orange - + Huawei - + This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained @@ -7292,55 +6909,274 @@ Names" registry : - + - + YANG Tree Diagrams - - - + + + This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. - - - + + + + + + + + Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions + + + + + + + In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections. + + + + + + + + + Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) + + + + + This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community. + + + + + + + + + Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) + + + + + + This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. This memo provides information for the Internet community. + + + + + + + + + Requirements for Traffic Engineering Over MPLS + + + + + + + + This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community. + + + + + + + + + + Carrying SR-Algorithm Information in PCE-based Networks. + + Cisco Systems, Inc. + + + Cisco Systems, Inc. + + + ZTE Corporation + + + Huawei Technologies + + + Nokia + + + + The SR-Algorithm associated with a Segment-ID (SID) defines the path + computation algorithm used by Interior Gateway Protocols (IGPs). + This information is available to controllers, such as the Path + Computation Element (PCE), via topology learning. This document + proposes an approach for informing headend routers regarding the SR- + Algorithm associated with each SID used in PCE-computed paths, as + well as signaling a specific SR-Algorithm as a constraint to the PCE. + + + + + + + + + + + + Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering + + + + + This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. This memo defines an Experimental Protocol for the Internet community. + + + + + + + + + Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons + + + + This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. This memo defines an Experimental Protocol for the Internet community. + + + + + + + + + Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering + + + + This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. This memo defines an Experimental Protocol for the Internet community. + + + + + + + + + A Single Rate Three Color Marker + + + + + This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community. + + + + + + + + + A Two Rate Three Color Marker + + + + + This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community. + + + + + + + + + Overview and Principles of Internet Traffic Engineering + + + + This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. + This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. + + + + + + + + + Path Computation Element (PCE) Communication Protocol Generic Requirements + + + + + The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community. + + + + - + The IETF XML Registry - - + + This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. - - - + + + + + + + + The Secure Shell (SSH) Authentication Protocol + + + + + The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] + + + + + + + + + The Transport Layer Security (TLS) Protocol Version 1.3 + + + + This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. + This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. + + + + - + - YANG Data Model for Bidirectional Forwarding Detection (BFD) - - - - - - + QUIC: A UDP-Based Multiplexed and Secure Transport + + + - This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). - The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342). This document updates "YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC 9127). + This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. - - + + @@ -7348,6 +7184,10 @@ Names" registry : + + + +
The Complete Schema Trees @@ -7356,6 +7196,10 @@ model. See for an explanation of the symbols used. The data type of every leaf node is shown near the right end of the corresponding line. +
  • + Editors' Note: The YANG trees have been generated by pyang and have some bugs to be fixed before publication. Please manually fix the YANG tree before sending the document to the RFC EDITOR. +
+
TE Types Schema Tree
@@ -8354,2718 +8198,6 @@ The following container, already defined in , has been d lsp-protection-reroute. -
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 and the YANG model revision in . - -The intention of this appendix is to facilitate focusing the review of the YANG model in to the changes compared with the YANG model in . - -This diff has been generated using the following UNIX commands to compare the YANG module revisions in section 3.1 of and in : - -
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: - -
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"; -> } -> -30c42 -< ---- -> -55c67 -< Copyright (c) 2020 IETF Trust and the persons identified as ---- -> Copyright (c) 2024 IETF Trust and the persons identified as -60c72 -< the license terms contained in, the Simplified BSD License set ---- -> the license terms contained in, the Revised BSD License set -65,66c77,165 -< 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-09-13 { -> 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. -> -> 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: -> - 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 -70c169 -< "Latest revision of TE types."; ---- -> "Initial Version of TE types."; -86a186 -> -92c192 -< Version 2 ---- -> Version 2 -95c195 -< Engineering (MPLS-TE)"; ---- -> Engineering (MPLS-TE)"; -111a212 -> -117c218 -< Engineering (MPLS-TE)"; ---- -> Engineering (MPLS-TE)"; -157,158c258,259 -< Routed Label Switched Paths (LSPs) Using TE Metric -< Extensions ---- -> Routed Label Switched Paths (LSPs) Using TE Metric -> Extensions -168c269 -< Multi-Protocol Label Switching (GMPLS) ---- -> Multi-Protocol Label Switching (GMPLS) -170c271 -< Multi-Protocol Label Switching (GMPLS)"; ---- -> Multi-Protocol Label Switching (GMPLS)"; -193c294 -< Traffic Engineering Networks"; ---- -> Traffic Engineering Networks"; -244,245c345,346 -< ITU-T Recommendation G.709: Interfaces for the -< optical transport network"; ---- -> ITU-T G.709: Interfaces for the optical transport network - -> Edition 6.0 (06/2020)"; -256c357 -< MPLS Traffic Engineering, Section 4.3.1"; ---- -> MPLS Traffic Engineering, Section 4.3.1"; -263a365 -> -264a367 -> -269c372 -< Aggregation ---- -> Aggregation -288c391 -< Section 4.3.3"; ---- -> Section 4.3.3"; -306c409 -< Version 2"; ---- -> Version 2"; -349c452 -< second MPLS Traffic Engineering (TE) Metric"; ---- -> second MPLS Traffic Engineering (TE) Metric"; -351a455,457 -> // CHANGE NOTE: The typedef te-node-id below has been -> // updated in this module revision -> // RFC Editor: remove the note above and this note -353c459,462 -< type yang:dotted-quad; ---- -> type union { -> type yang:dotted-quad; -> type inet:ipv6-address-no-zone; -> } -357,358c466,470 -< The identifier is represented as 4 octets in dotted-quad -< notation. ---- -> -> The identifier is represented either as 4 octets in -> dotted-quad notation, or as 16 octets in full, mixed, -> shortened, or shortened-mixed IPv6 address notation. -> -362,363c474,477 -< 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. -> -368c482 -< Version 2, Section 2.4.1 ---- -> Version 2, Section 2.4.1 -370c484 -< Section 4.3 ---- -> Section 4.3 -373c487 -< Routing for OSPFv2 Protocols, Section 3"; ---- -> Routing for OSPFv2 Protocols, Section 3"; -412c526,527 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -472c587,588 -< for Generalized Multi-Protocol Label Switching (GMPLS) ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS) -519a636 -> -537a655 -> -542c660 -< Version 2 ---- -> Version 2 -545a664,691 -> // 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 -> "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."; -> } -> -553,554c699,700 -< Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE -< Label Switched Paths (LSPs)"; ---- -> Traffic Engineering (RSVP-TE) for -> Point-to-Multipoint TE Label Switched Paths (LSPs)"; -570c716 -< Engineering (MPLS-TE)"; ---- -> Engineering (MPLS-TE)"; -606a753,760 -> // 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."; -> } -> -618c772 -< Section 4.7.1"; ---- -> Section 4.7.1"; -636c790 -< Section 4.7.1"; ---- -> Section 4.7.1"; -664,665c818,819 -< (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched -< Path (LSP)"; ---- -> (MPLS) Traffic Engineering (TE) Loosely Routed Label -> Switched Path (LSP)"; -690c844 -< RSVP-TE ---- -> RSVP-TE -692,693c846,847 -< Using Resource Reservation Protocol Traffic Engineering -< (RSVP-TE) ---- -> Using Resource Reservation Protocol Traffic -> Engineering (RSVP-TE) -695c849 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -711c865 -< RSVP-TE ---- -> RSVP-TE -713,714c867,868 -< Using Resource Reservation Protocol Traffic Engineering -< (RSVP-TE) ---- -> Using Resource Reservation Protocol Traffic -> Engineering (RSVP-TE) -716c870 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -727c881 -< RSVP-TE ---- -> RSVP-TE -729,730c883,884 -< Using Resource Reservation Protocol Traffic Engineering -< (RSVP-TE) ---- -> Using Resource Reservation Protocol -> Traffic Engineering (RSVP-TE) -732c886 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -741,742c895,896 -< Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE -< Label Switched Paths (LSPs) ---- -> Traffic Engineering (RSVP-TE) for -> Point-to-Multipoint TE Label Switched Paths (LSPs) -744c898 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -753,754c907,908 -< Resource Reservation Protocol-Traffic Engineering (RSVP-TE) -< Extensions ---- -> Resource Reservation Protocol-Traffic Engineering -> (RSVP-TE) Extensions -756c910 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -765c919,920 -< Multiprotocol Label Switching Traffic Engineering (GMPLS TE) ---- -> Multiprotocol Label Switching Traffic Engineering -> (GMPLS TE) -767c922 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -777c932 -< Multi-Layer and Multi-Region Networks (MLN/MRN) ---- -> Multi-Layer and Multi-Region Networks (MLN/MRN) -779c934 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -789c944 -< Mapping for RSVP-TE Label Switched Paths ---- -> Mapping for RSVP-TE Label Switched Paths -791c946 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -801c956 -< Mapping for RSVP-TE Label Switched Paths ---- -> Mapping for RSVP-TE Label Switched Paths -803c958 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -813c968 -< Route Object (ERO)"; ---- -> Route Object (ERO)"; -823c978,979 -< Administration, and Maintenance (OAM) Configuration"; ---- -> Administration, and Maintenance (OAM) -> Configuration"; -833c989,990 -< Administration, and Maintenance (OAM) Configuration"; ---- -> Administration, and Maintenance (OAM) -> Configuration"; -842c999 -< Route Object (ERO) ---- -> Route Object (ERO) -844c1001 -< Link Group (SRLG) Information"; ---- -> Link Group (SRLG) Information"; -855c1012 -< Loopback"; ---- -> Loopback"; -864,865c1021,1022 -< Point-to-Multipoint Traffic Engineering Label Switched Paths -< (LSPs)"; ---- -> Point-to-Multipoint Traffic Engineering Label -> Switched Paths (LSPs)"; -887c1044,1045 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -896c1054,1055 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -905c1064,1065 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -914c1074,1075 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -923c1084,1085 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -945c1107,1108 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery -967c1130 -< Label Switched Paths (LSPs)"; ---- -> Label Switched Paths (LSPs)"; -980c1143 -< Label Switched Paths (LSPs)"; ---- -> Label Switched Paths (LSPs)"; -982a1146,1163 -> // 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; -> 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 -985c1166 -< "Base objective function type."; ---- -> "Base identity for path objective function types."; -994c1175 -< Computation Element Communication Protocol (PCEP)"; ---- -> Computation Element Communication Protocol (PCEP)"; -1004c1185 -< Computation Element Communication Protocol (PCEP)"; ---- -> Computation Element Communication Protocol (PCEP)"; -1013c1194 -< Computation Element Communication Protocol (PCEP)"; ---- -> Computation Element Communication Protocol (PCEP)"; -1015a1197,1199 -> // 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 -1017a1202 -> status obsolete; -1020c1205,1209 -< consumption."; ---- -> consumption. -> -> This identity has been obsoleted: the -> 'svec-of-minimize-agg-bandwidth-consumption' identity SHOULD -> be used instead."; -1023c1212 -< Computation Element Communication Protocol (PCEP)"; ---- -> Computation Element Communication Protocol (PCEP)"; -1025a1215,1217 -> // 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 -1027a1220 -> status obsolete; -1030c1223,1227 -< is carrying the highest load."; ---- -> is carrying the highest load. -> -> This identity has been obsoleted: the -> 'svec-of-minimize-load-most-loaded-link' identity SHOULD -> be used instead."; -1033c1230 -< Computation Element Communication Protocol (PCEP)"; ---- -> Computation Element Communication Protocol (PCEP)"; -1035a1233,1235 -> // 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 -1037a1238 -> status obsolete; -1039c1240,1244 -< "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."; -1042c1247 -< Computation Element Communication Protocol (PCEP)"; ---- -> Computation Element Communication Protocol (PCEP)"; -1049a1255,1257 -> // 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,1057c1264,1265 -< "RFC 3272: Overview and Principles of Internet Traffic -< Engineering, Section 5.4"; ---- -> "RFC 9522: Overview and Principles of Internet Traffic -> Engineering, Section 4.4"; -1059a1268,1271 -> // 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 -1071,1072c1283,1284 -< "RFC 3272: Overview and Principles of Internet Traffic -< Engineering ---- -> "RFC 9522: Overview and Principles of Internet Traffic -> Engineering -1074c1286 -< Protocol Generic Requirements"; ---- -> Protocol Generic Requirements"; -1076a1289,1292 -> // 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 -1085,1086c1301,1302 -< RFC 3272: Overview and Principles of Internet Traffic -< Engineering"; ---- -> RFC 9522: Overview and Principles of Internet Traffic -> Engineering"; -1102c1318 -< Protocol Generic Requirements"; ---- -> Protocol Generic Requirements"; -1112c1328 -< Protocol Generic Requirements"; ---- -> Protocol Generic Requirements"; -1123c1339 -< Protocol Generic Requirements"; ---- -> Protocol Generic Requirements"; -1145,1146c1361,1362 -< Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE -< Label Switched Paths (LSPs)"; ---- -> Traffic Engineering (RSVP-TE) for -> Point-to-Multipoint TE Label Switched Paths (LSPs)"; -1216a1433,1444 -> // 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."; -> } -> -1305c1533 -< Section 2.5"; ---- -> Section 2.5"; -1314c1542 -< Section 2.5"; ---- -> Section 2.5"; -1321a1550,1558 -> // 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."; -> } -> -1339a1577,1592 -> // 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)"; -> } -> -1346c1599,1600 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1355c1609,1610 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1364c1619,1620 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1372c1628,1629 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -1381c1638,1639 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -1383a1642,1644 -> // 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 -1385a1647 -> status obsolete; -1387c1649,1653 -< "'(Full) Rerouting' LSP protection type."; ---- -> "'(Full) Rerouting' LSP protection type. -> -> This identity has been obsoleted: the -> 'restoration-scheme-rerouting' identity SHOULD be used -> instead."; -1390c1656,1657 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -1392a1660,1662 -> // CHANGE NOTE: The identity lsp-protection-reroute -> // below has been obsoleted in this module revision -> // RFC Editor: remove the note above and this note -1394a1665 -> status obsolete; -1396c1667,1671 -< "'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."; -1399c1674,1675 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -1408c1684,1685 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -1417c1694,1695 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -1426c1704,1705 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -1435c1714,1715 -< Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; ---- -> Generalized Multi-Protocol Label Switching (GMPLS) -> Recovery"; -1444c1724,1725 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1466c1747,1748 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1475c1757,1758 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1484c1767,1768 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1494c1778,1779 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1504c1789,1790 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1513c1799,1800 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1522c1809,1810 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1532c1820,1821 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1542c1831,1832 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1559c1849,1850 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1568c1859,1860 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1579c1871,1872 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1589c1882,1883 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1601c1895,1896 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1613c1908,1909 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1626c1922,1923 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1628a1926,1929 -> // 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,1633c1933,1935 -< "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,1637c1938,1939 -< "RFC 4427: Recovery (Protection and Restoration) Terminology -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> "ITU-T G.808.1: Generic protection switching - Linear trail and -> subnetwork protection - Edition 4.0 (05/2014)"; -1648c1950,1951 -< for Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> for Generalized Multi-Protocol Label Switching -> (GMPLS)"; -1656c1959 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1665c1968 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1674c1977 -< Forum and G.8011 Ethernet Service Switching"; ---- -> Forum and G.8011 Ethernet Service Switching"; -1683c1986 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1692c1995 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1701c2004,2005 -< Control of Evolving G.709 Optical Transport Networks"; ---- -> Control of Evolving G.709 Optical Transport -> Networks"; -1710c2014,2015 -< Switching Capable (DCSC) and Channel Set Label Extensions"; ---- -> Switching Capable (DCSC) and Channel Set Label -> Extensions"; -1719c2024 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1728c2033 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1736c2041 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1745c2050 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1754c2059 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1763c2068 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1772c2077 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1781c2086 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1790c2095 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1799c2104 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1808c2113 -< Signaling Functional Description"; ---- -> Signaling Functional Description"; -1817,1818c2122,2123 -< Signaling Extensions for G.709 Optical Transport Networks -< Control"; ---- -> Signaling Extensions for G.709 Optical Transport -> Networks Control"; -1827,1828c2132,2133 -< Signaling Extensions for G.709 Optical Transport Networks -< Control"; ---- -> Signaling Extensions for G.709 Optical Transport -> Networks Control"; -1837c2142,2143 -< Ethernet Forum and G.8011 Ethernet Service Switching"; ---- -> Ethernet Forum and G.8011 Ethernet Service -> Switching"; -1905c2211 -< Protocol-Traffic Engineering (RSVP-TE)"; ---- -> Protocol-Traffic Engineering (RSVP-TE)"; -1914c2220 -< Protocol-Traffic Engineering (RSVP-TE)"; ---- -> Protocol-Traffic Engineering (RSVP-TE)"; -1917c2223,2226 -< 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 { -1919c2228,2229 -< "Base identity for the path metric type."; ---- -> "Base identity used to define the path metric optimization -> types."; -1922,1923c2232,2235 -< 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,1928c2237,2243 -< "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,1938c2246,2254 -< 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,1944c2256,2265 -< identity path-metric-hop { -< base path-metric-type; -< 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 -> RFC 5305: IS-IS Extensions for Traffic Engineering, -> Section 3.7"; -> } -1946,1952c2267,2275 -< identity path-metric-delay-average { -< base path-metric-type; -< description -< "Average 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"; -> } -1954,1960c2277,2287 -< 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-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"; -> } -1962,1972c2289,2299 -< 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 -< "RFC 3630: Traffic Engineering (TE) Extensions to OSPF -< Version 2 -< RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; -< } ---- -> 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"; -> } -1974,1979c2301,2311 -< 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-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"; -> } -1981,1986c2313,2447 -< 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-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"; -> } -> -> // 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 { -> base path-metric-type; -> description -> "The Path Min Delay Metric, measured in units of -> microseconds."; -> reference -> "RFC YYYY: Carrying SR-Algorithm information in PCE-based -> Networks, Section 3.5.1"; -> } -> // RFC Editor: replace YYYY with actual RFC number assigned to -> // [I-D.ietf-pce-sid-algo] and remove this note -> -> // 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."; -> } -1996c2457,2458 -< "Min-Fill LSP path placement."; ---- -> "Min-Fill LSP path placement: selects the path with the most -> available bandwidth (load balance LSPs over more links)."; -2002c2464,2465 -< "Max-Fill LSP path placement."; ---- -> "Max-Fill LSP path placement: selects the path with the least -> available bandwidth (packing more LSPs over few links)."; -2049a2513,2516 -> // 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 -2054,2055c2521,2522 -< "RFC 3272: Overview and Principles of Internet Traffic -< Engineering"; ---- -> "RFC 9522: Overview and Principles of Internet Traffic -> Engineering"; -2070c2537 -< Computation Element Communication Protocol (PCEP)"; ---- -> Computation Element Communication Protocol (PCEP)"; -2079c2546 -< Computation Element Communication Protocol (PCEP)"; ---- -> Computation Element Communication Protocol (PCEP)"; -2110a2578,3029 -> // 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 -> 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 -> 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 { -> 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"; -> } -> -> 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); -> -> 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 Programming 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)"; -> } -> -> identity protocol-origin-bgp { -> base protocol-origin-type; -> description -> "Protocol origin is Border Gateway Protocol (BGP)."; -> reference -> "RFC 9012: The BGP Tunnel Encapsulation Attribute"; -> } -> -> // 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)"; -> } -> -> 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 -> 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."; -> reference -> "RFC 5541: Encoding of Objective Functions in the Path -> Computation Element Communication Protocol -> (PCEP)"; -> } -> -2223,2224c3142,3143 -< Routed Label Switched Paths (LSPs) Using TE Metric -< Extensions ---- -> Routed Label Switched Paths (LSPs) Using TE Metric -> Extensions -2248,2249c3167,3168 -< Routed Label Switched Paths (LSPs) Using TE Metric -< Extensions ---- -> Routed Label Switched Paths (LSPs) Using TE Metric -> Extensions -2273,2274c3192,3193 -< Routed Label Switched Paths (LSPs) Using TE Metric -< Extensions ---- -> Routed Label Switched Paths (LSPs) Using TE Metric -> Extensions -2286c3205 -< Version 2"; ---- -> Version 2"; -2350c3269 -< Version 2"; ---- -> Version 2"; -2405,2406c3324,3325 -< Routed Label Switched Paths (LSPs) Using TE Metric -< Extensions ---- -> Routed Label Switched Paths (LSPs) Using TE Metric -> Extensions -2416c3335 -< Networks"; ---- -> Networks"; -2437,2438c3356,3357 -< Routed Label Switched Paths (LSPs) Using TE Metric -< Extensions ---- -> Routed Label Switched Paths (LSPs) Using TE Metric -> Extensions -2472c3391 -< Extensions, Section 6"; ---- -> Extensions, Section 6"; -2506a3426,3428 -> // CHANGE NOTE: The explicit-route-hop grouping below has been -> // updated in this module revision -> // RFC Editor: remove the note above and this note -2514a3437,3445 -> 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."; -> } -2517d3447 -< mandatory true; -2531c3461 -< Section 4.3, EXPLICIT_ROUTE in RSVP-TE ---- -> Section 4.3, EXPLICIT_ROUTE in RSVP-TE -2533c3463,3464 -< ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; ---- -> ReSerVation Protocol - Traffic Engineering -> (RSVP-TE)"; -2560c3491 -< Section 4.3, EXPLICIT_ROUTE in RSVP-TE ---- -> Section 4.3, EXPLICIT_ROUTE in RSVP-TE -2562c3493,3494 -< ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; ---- -> ReSerVation Protocol - Traffic Engineering -> (RSVP-TE)"; -2566a3499,3509 -> 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."; -> } -2569d3511 -< mandatory true; -2574a3517,3521 -> leaf node-id-uri { -> type nw:node-id; -> description -> "The identifier of a node in the topology."; -> } -2577d3523 -< mandatory true; -2597c3543 -< Section 4.3, EXPLICIT_ROUTE in RSVP-TE ---- -> Section 4.3, EXPLICIT_ROUTE in RSVP-TE -2599c3545,3546 -< ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; ---- -> ReSerVation Protocol - Traffic Engineering -> (RSVP-TE)"; -2631a3579,3581 -> // CHANGE NOTE: The explicit-route-hop grouping below has been -> // updated in this module revision -> // RFC Editor: remove the note above and this note -2646a3597,3600 -> must "node-id-uri or node-id" { -> description -> "At least one node identifier MUST be present."; -> } -2648a3603,3607 -> leaf node-id-uri { -> type nw:node-id; -> description -> "The identifier of a node in the topology."; -> } -2651d3609 -< mandatory true; -2662c3620 -< Tunnels ---- -> Tunnels -2664c3622 -< Node-Id Sub-Object"; ---- -> Node-Id Sub-Object"; -2687c3645 -< Tunnels ---- -> Tunnels -2689c3647 -< Node-Id Sub-Object"; ---- -> Node-Id Sub-Object"; -2696a3655,3665 -> 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."; -> } -2699d3667 -< mandatory true; -2704a3673,3677 -> leaf node-id-uri { -> type nw:node-id; -> description -> "The identifier of a node in the topology."; -> } -2717c3690 -< Tunnels ---- -> Tunnels -2719c3692 -< Node-Id Sub-Object"; ---- -> Node-Id Sub-Object"; -2725c3698,3699 -< ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; ---- -> ReSerVation Protocol - Traffic Engineering -> (RSVP-TE)"; -2742c3716 -< Tunnels ---- -> Tunnels -2744c3718 -< Node-Id Sub-Object"; ---- -> Node-Id Sub-Object"; -2842a3817,3827 -> -> In case the restriction is 'inclusive', the bit-position is -> set if the corresponding mapped label is available. -> In this case, if the range-bitmap is not present, all the -> labels in the range are available. -> -> In case the restriction is 'exclusive', the bit-position is -> set if the corresponding mapped label is not available. -> In this case, if the range-bitmap is not present, all the -> labels in the range are not available. -> -2876c3861 -< for GMPLS-Controlled Networks"; ---- -> for GMPLS-Controlled Networks"; -2881a3867,3869 -> // CHANGE NOTE: The grouping optimization-metric-entry below has -> // been updated in this module revision -> // RFC Editor: remove the note above and this note -2887c3875 -< base path-metric-type; ---- -> base path-metric-optimization-type; -2933c3921,3922 -< Generalized Multi-Protocol Label Switching (GMPLS)"; ---- -> Generalized Multi-Protocol Label Switching -> (GMPLS)"; -2964a3954,3956 -> // CHANGE NOTE: The grouping tunnel-constraints below has -> // been updated in this module revision -> // RFC Editor: remove the note above and this note -2968a3961,3965 -> leaf network-id { -> type nw:network-id; -> description -> "The network topology identifier."; -> } -2972a3970,3972 -> // 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 -2977c3977 -< container explicit-route-objects-always { ---- -> container explicit-route-objects { -2979c3979 -< "Container for the 'exclude route' object list."; ---- -> "Container for the explicit route object lists."; -3101a4102,4104 -> // 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 -3107c4110 -< "TE path metric bounds container."; ---- -> "Top-level container for the list of path metric bounds."; -3111c4114,4122 -< "List of TE path metric bounds."; ---- -> "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."; -3114c4125 -< base path-metric-type; ---- -> base link-path-metric-type; -3124,3126c4135,4141 -< "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."; -3131a4147,4149 -> // 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 -3152a4171 -> status deprecated; -3154c4173,4176 -< "Container for the list of tiebreakers."; ---- -> "Container for the list of tiebreakers. -> -> This container has been deprecated by the tiebreaker -> leaf."; -3156a4179 -> status deprecated; -3164a4188 -> status deprecated; -3189a4214,4222 -> 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."; -> } -3376a4410,4478 -> } -> } -> -> // 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: Generalized Multi-Protocol Label Switching (GMPLS) -> Architecture"; -> } -> leaf switching-type { -> type identityref { -> base te-types:switching-capabilities; -> } -> description -> "LSP switching type."; -> reference -> "RFC 3945: Generalized Multi-Protocol Label Switching (GMPLS) -> Architecture"; -> } -> } -> -> // CHANGE NOTE: The grouping te-generic-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 union { -> type te-node-id; -> type inet:ip-address; -> type nw:node-id; -> } -> description -> "The identifier of the node. -> -> It can be represented as IP address or dotted quad address -> or as an URI. -> -> The type data node disambiguates the union type."; -> } -> 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."; -]]>
- -
-
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 and the YANG model revision in . - -The intention of this appendix is to facilitate focusing the review of the YANG model in to the changes compared with the YANG model in . - -This diff has been generated using the following UNIX commands to compare the YANG module revisions in section 3.2 of and in : - -
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: - -
import ietf-yang-types { -> prefix yang; -> reference -> "RFC 6991: Common YANG Data Types"; -> } -11c15 -< "RFC 8776: Common YANG Data Types for Traffic Engineering"; ---- -> "RFC XXXX: Common YANG Data Types for Traffic Engineering"; -12a17,18 -> // RFC Editor: replace XXXX with actual RFC number -> // and remove this note -22c28 -< ---- -> -37,39c43,53 -< 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. -41c55 -< Copyright (c) 2020 IETF Trust and the persons identified as ---- -> Copyright (c) 2024 IETF Trust and the persons identified as -46c60 -< the license terms contained in, the Simplified BSD License set ---- -> the license terms contained in, the Revised BSD License set -51,52c65,87 -< 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-09-27 { -> 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: -> - bandwidth-profile-parameters; -> - 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 -61c96,202 -< /** ---- -> /* -> * 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 { -> base bandwidth-profile-type; -> description -> "MEF 10 Bandwidth Profile"; -> reference -> "MEF 10.3: Ethernet Services Attributes Phase 3"; -> } -> -> identity rfc-2697 { -> base bandwidth-profile-type; -> description -> "RFC 2697 Bandwidth Profile"; -> reference -> "RFC 2697: A Single Rate Three Color Marker"; -> } -> -> identity rfc-2698 { -> base bandwidth-profile-type; -> description -> "RFC 2698 Bandwidth Profile"; -> reference -> "RFC 2698: A Two Rate Three Color Marker"; -> } -> -> identity rfc-4115 { -> base bandwidth-profile-type; -> description -> "RFC 4115 Bandwidth Profile"; -> reference -> "RFC 4115: 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 -> "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, -> Section 4.3 -> RFC 8570: 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 -> "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, -> Section 4.4 -> RFC 8570: 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 -> "RFC 8233: 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 -> "RFC 8233: Extensions to the Path Computation Element -> Communication Protocol (PCEP) to Compute -> Service-Aware Label Switched Paths (LSPs), -> Section 3.1.3"; -> } -> -> /* -67c208,212 -< enum specified { ---- -> enum specified-value { -> description -> "Bandwidth value is explicitly specified."; -> } -> enum specified-profile { -69c214 -< "Bandwidth is explicitly specified."; ---- -> "Bandwidth profile is explicitly specified."; -91c236 -< MPLS Traffic Engineering"; ---- -> MPLS Traffic Engineering"; -102c247 -< MPLS Traffic Engineering"; ---- -> MPLS Traffic Engineering"; -149c294 -< MPLS Traffic Engineering"; ---- -> MPLS Traffic Engineering"; -177,178c322,323 -< Constraints Model for Diffserv-aware MPLS Traffic Engineering -< & Performance Comparisons"; ---- -> Constraints Model for Diffserv-aware MPLS Traffic -> Engineering & Performance Comparisons"; -180a326,329 -> /* -> * Groupings -> */ -> -220c369 -< Statement, Section 4.2"; ---- -> Statement, Section 4.2"; -229c378 -< Extensions ---- -> Extensions -231,232c380,381 -< Explicitly Routed Label Switched Paths (LSPs) Using -< TE Metric Extensions ---- -> Explicitly Routed Label Switched Paths (LSPs) -> Using TE Metric Extensions -234c383 -< Extensions"; ---- -> Extensions"; -247c396 -< Extensions, Section 4.4"; ---- -> Extensions, Section 4.4"; -256c405 -< Extensions ---- -> Extensions -258,259c407,408 -< Explicitly Routed Label Switched Paths (LSPs) Using -< TE Metric Extensions ---- -> Explicitly Routed Label Switched Paths (LSPs) -> Using TE Metric Extensions -261c410 -< Extensions"; ---- -> Extensions"; -283c432 -< Extensions ---- -> Extensions -285,286c434,435 -< Explicitly Routed Label Switched Paths (LSPs) Using -< TE Metric Extensions ---- -> Explicitly Routed Label Switched Paths (LSPs) -> Using TE Metric Extensions -288c437 -< Extensions"; ---- -> Extensions"; -305c454 -< Extensions ---- -> Extensions -307,308c456,457 -< Explicitly Routed Label Switched Paths (LSPs) Using -< TE Metric Extensions ---- -> Explicitly Routed Label Switched Paths (LSPs) -> Using TE Metric Extensions -310c459 -< Extensions"; ---- -> Extensions"; -321c470 -< Statement, Section 4.2"; ---- -> Statement, Section 4.2"; -330c479 -< Extensions ---- -> Extensions -332,333c481,482 -< Explicitly Routed Label Switched Paths (LSPs) Using -< TE Metric Extensions ---- -> Explicitly Routed Label Switched Paths (LSPs) -> Using TE Metric Extensions -335c484 -< Extensions"; ---- -> Extensions"; -358,363c507,513 -< "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"; ---- -> "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"; -407a558,604 -> // CHANGE NOTE: The grouping -> // one-way-performance-metrics-gauge-packet has been added in -> // this module revision -> // RFC Editor: remove the note above and this note -> grouping one-way-performance-metrics-gauge-packet { -> description -> "One-way packet PM throttle grouping. -> -> This grouping is used to report the same metrics defined in -> the one-way-performance-metrics-packet grouping, using gauges -> instead of uint32 data types and referencing IPPM RFCs -> instead of IGP-TE RFCs."; -> leaf one-way-min-delay { -> type yang:gauge64; -> description -> "One-way minimum delay or latency in microseconds."; -> } -> leaf one-way-max-delay { -> type yang:gauge64; -> description -> "One-way maximum delay or latency in microseconds."; -> reference -> "RFC 7679: A One-Way Delay Metric for IP Performance -> Metrics (IPPM)"; -> } -> leaf one-way-delay-variation { -> type yang:gauge64; -> description -> "One-way delay variation in microseconds."; -> reference -> "RFC 3393: IP Packet Delay Variation Metric for IP -> Performance Metrics (IPPM)"; -> } -> leaf one-way-packet-loss { -> type decimal64 { -> fraction-digits 5; -> range "0..100"; -> } -> description -> "The ratio of packets dropped to packets transmitted between -> two endpoints."; -> reference -> "RFC 7680: A One-Way Loss Metric for IP Performance -> Metrics (IPPM)"; -> } -> } -> -447a645,688 -> // CHANGE NOTE: The grouping -> // two-way-performance-metrics-gauge-packet has been added in -> // this module revision -> // RFC Editor: remove the note above and this note -> grouping two-way-performance-metrics-gauge-packet { -> description -> "Two-way packet PM throttle grouping. -> -> This grouping is used to report the same metrics defined in -> the two-way-performance-metrics-packet grouping, using gauges -> instead of uint32 data types and referencing IPPM RFCs -> instead of IGP-TE RFCs."; -> leaf two-way-min-delay { -> type yang:gauge64; -> description -> "Two-way minimum delay or latency in microseconds."; -> reference -> "RFC 2681: A Round-trip Delay Metric for IPPM"; -> } -> leaf two-way-max-delay { -> type yang:gauge64; -> description -> "Two-way maximum delay or latency in microseconds."; -> reference -> "RFC 2681: A Round-trip Delay Metric for IPPM"; -> } -> leaf two-way-delay-variation { -> type yang:gauge64; -> description -> "Two-way delay variation in microseconds."; -> reference -> "RFC 5481: Packet Delay Variation Applicability Statement"; -> } -> leaf two-way-packet-loss { -> type decimal64 { -> fraction-digits 5; -> range "0..100"; -> } -> description -> "The ratio of packets dropped to packets transmitted between -> two endpoints."; -> } -> } -> -472a714,844 -> } -> } -> -> // CHANGE NOTE: The bandwidth-profile-parameters below has been -> // added in this module revision -> // RFC Editor: remove the note above and this note -> grouping bandwidth-profile-parameters { -> description -> "Common parameters to define bandwidth profiles in packet -> networks."; -> leaf cir { -> type uint64; -> units "bits/second"; -> description -> "Committed Information Rate (CIR)."; -> } -> leaf cbs { -> type uint64; -> units "bytes"; -> 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-path-bandwidth { -> description -> "Bandwidth attributes for TE Packet paths."; -> container packet-bandwidth { -> description -> "Bandwidth attributes for TE Packet paths."; -> leaf specification-type { -> type te-bandwidth-requested-type; -> description -> "The bandwidth specification type, either explicitly -> specified or automatically computed."; -> } -> leaf set-bandwidth { -> when "../specification-type = 'specified-value'" { -> description -> "When the bandwidth value is explicitly specified."; -> } -> type bandwidth-kbps; -> description -> "Set the bandwidth value explicitly, e.g., using offline -> calculation."; -> } -> container bandwidth-profile { -> when "../specification-type = 'specified-profile'" { -> description -> "When the bandwidth profile is explicitly specified."; -> } -> description -> "Set the bandwidth profile attributes explicitly."; -> 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."; -> } -> uses bandwidth-profile-parameters; -> } -> leaf class-type { -> type te-types:te-ds-class; -> description -> "The Class-Type of traffic transported by the LSP."; -> reference -> "RFC 4124: Protocol Extensions for Support of -> Diffserv-aware MPLS Traffic Engineering, -> Section 4.3.1"; -> } -> leaf signaled-bandwidth { -> type te-packet-types:bandwidth-kbps; -> config false; -> description -> "The currently signaled bandwidth of the LSP. -> -> In the case where the bandwidth is specified -> explicitly, then this will match the value of the -> set-bandwidth leaf. -> -> In the cases where the bandwidth is dynamically -> computed by the system, the current value of the -> bandwidth should be reflected."; -> } -> } -> } -> -> // 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 -> "Bandwidth attributes for Packet TE links."; -> leaf packet-bandwidth { -> type uint64; -> units "bits/second"; -> description -> "Bandwidth value for Packet TE links."; -]]>
- -
-
-
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 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 but it does not need to be revised, needs to be published just to change its reference to RFC8776-bis (see ). - -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: - -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 @@ -11103,1162 +8235,809 @@ for their valuable comments and suggestions on this document. diff --git a/ietf-te-packet-types.tree.fold b/ietf-te-packet-types.tree.fold deleted file mode 100644 index 557a926..0000000 --- a/ietf-te-packet-types.tree.fold +++ /dev/null @@ -1,148 +0,0 @@ -module: ietf-te-packet-types - - grouping performance-metrics-attributes-packet: - +-- performance-metrics-one-way - | +-- one-way-delay? uint32 - | +-- one-way-delay-normality? - | | te-types:performance-metrics-normality - | +-- one-way-residual-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-residual-bandwidth-normality? - | | te-types:performance-metrics-normality - | +-- one-way-available-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-available-bandwidth-normality? - | | te-types:performance-metrics-normality - | +-- one-way-utilized-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-utilized-bandwidth-normality? - | | te-types:performance-metrics-normality - | +-- one-way-min-delay? uint32 - | +-- one-way-min-delay-normality? - | | te-types:performance-metrics-normality - | +-- one-way-max-delay? uint32 - | +-- one-way-max-delay-normality? - | | te-types:performance-metrics-normality - | +-- one-way-delay-variation? uint32 - | +-- one-way-delay-variation-normality? - | | te-types:performance-metrics-normality - | +-- one-way-packet-loss? decimal64 - | +-- one-way-packet-loss-normality? - | te-types:performance-metrics-normality - +-- performance-metrics-two-way - +-- two-way-delay? uint32 - +-- two-way-delay-normality? - | te-types:performance-metrics-normality - +-- two-way-min-delay? uint32 - +-- two-way-min-delay-normality? - | te-types:performance-metrics-normality - +-- two-way-max-delay? uint32 - +-- two-way-max-delay-normality? - | te-types:performance-metrics-normality - +-- two-way-delay-variation? uint32 - +-- two-way-delay-variation-normality? - | te-types:performance-metrics-normality - +-- two-way-packet-loss? decimal64 - +-- two-way-packet-loss-normality? - te-types:performance-metrics-normality - grouping one-way-performance-metrics-packet: - +-- one-way-min-delay? uint32 - +-- one-way-max-delay? uint32 - +-- one-way-delay-variation? uint32 - +-- one-way-packet-loss? decimal64 - grouping one-way-performance-metrics-gauge-packet: - +-- one-way-min-delay? yang:gauge64 - +-- one-way-max-delay? yang:gauge64 - +-- one-way-delay-variation? yang:gauge64 - +-- one-way-packet-loss? decimal64 - grouping two-way-performance-metrics-packet: - +-- two-way-min-delay? uint32 - +-- two-way-max-delay? uint32 - +-- two-way-delay-variation? uint32 - +-- two-way-packet-loss? decimal64 - grouping two-way-performance-metrics-gauge-packet: - +-- two-way-min-delay? yang:gauge64 - +-- two-way-max-delay? yang:gauge64 - +-- two-way-delay-variation? yang:gauge64 - +-- two-way-packet-loss? decimal64 - grouping performance-metrics-throttle-container-packet: - +-- throttle - +-- one-way-delay-offset? uint32 - +-- measure-interval? uint32 - +-- advertisement-interval? uint32 - +-- suppression-interval? uint32 - +-- threshold-out - | +-- one-way-delay? uint32 - | +-- one-way-residual-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-available-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-utilized-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- two-way-delay? uint32 - | +-- one-way-min-delay? uint32 - | +-- one-way-max-delay? uint32 - | +-- one-way-delay-variation? uint32 - | +-- one-way-packet-loss? decimal64 - | +-- two-way-min-delay? uint32 - | +-- two-way-max-delay? uint32 - | +-- two-way-delay-variation? uint32 - | +-- two-way-packet-loss? decimal64 - +-- threshold-in - | +-- one-way-delay? uint32 - | +-- one-way-residual-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-available-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-utilized-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- two-way-delay? uint32 - | +-- one-way-min-delay? uint32 - | +-- one-way-max-delay? uint32 - | +-- one-way-delay-variation? uint32 - | +-- one-way-packet-loss? decimal64 - | +-- two-way-min-delay? uint32 - | +-- two-way-max-delay? uint32 - | +-- two-way-delay-variation? uint32 - | +-- two-way-packet-loss? decimal64 - +-- threshold-accelerated-advertisement - +-- one-way-delay? uint32 - +-- one-way-residual-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-available-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-utilized-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- two-way-delay? uint32 - +-- one-way-min-delay? uint32 - +-- one-way-max-delay? uint32 - +-- one-way-delay-variation? uint32 - +-- one-way-packet-loss? decimal64 - +-- two-way-min-delay? uint32 - +-- two-way-max-delay? uint32 - +-- two-way-delay-variation? uint32 - +-- two-way-packet-loss? decimal64 - grouping bandwidth-profile-parameters: - +-- cir? uint64 - +-- cbs? uint64 - +-- eir? uint64 - +-- ebs? uint64 - +-- pir? uint64 - +-- pbs? uint64 - grouping te-packet-path-bandwidth: - +-- packet-bandwidth - +-- specification-type? te-bandwidth-requested-type - +-- set-bandwidth? bandwidth-kbps - +-- bandwidth-profile - | +-- bandwidth-profile-name? string - | +-- bandwidth-profile-type? identityref - | +-- cir? uint64 - | +-- cbs? uint64 - | +-- eir? uint64 - | +-- ebs? uint64 - | +-- pir? uint64 - | +-- pbs? uint64 - +-- class-type? te-types:te-ds-class - +--ro signaled-bandwidth? te-packet-types:bandwidth-kbps - grouping te-packet-link-bandwidth: - +-- packet-bandwidth? uint64 diff --git a/ietf-te-packet-types.yang b/ietf-te-packet-types.yang index aa011ed..b6b4be7 100644 --- a/ietf-te-packet-types.yang +++ b/ietf-te-packet-types.yang @@ -65,7 +65,7 @@ module ietf-te-packet-types { 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-09-27 { + revision 2024-10-30 { description "This revision adds the following new identities: - bandwidth-profile-type; @@ -97,10 +97,6 @@ module ietf-te-packet-types { * 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"; @@ -130,19 +126,8 @@ module ietf-te-packet-types { "RFC 2698: A Two Rate Three Color Marker"; } - identity rfc-4115 { - base bandwidth-profile-type; - description - "RFC 4115 Bandwidth Profile"; - reference - "RFC 4115: A Differentiated Service Two-Rate, Three-Color - Marker with Efficient Handling of in-Profile - Traffic"; - } + // Derived identities from te-types:link-metric-type - // 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 @@ -155,9 +140,6 @@ module ietf-te-packet-types { 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 @@ -170,9 +152,8 @@ module ietf-te-packet-types { 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 + // Derived identities from te-types:link-metric-type + identity path-metric-delay-variation { base te-types:path-metric-type; description @@ -185,9 +166,6 @@ module ietf-te-packet-types { 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 @@ -376,11 +354,11 @@ module ietf-te-packet-types { reference "RFC 7471: OSPF Traffic Engineering (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"; + Using TE Metric Extensions"; } leaf one-way-packet-loss { type decimal64 { @@ -403,11 +381,11 @@ module ietf-te-packet-types { reference "RFC 7471: OSPF Traffic Engineering (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"; + Using TE Metric Extensions"; } description "PM one-way packet-specific augmentation for a generic PM @@ -430,11 +408,11 @@ module ietf-te-packet-types { reference "RFC 7471: OSPF Traffic Engineering (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"; + Using TE Metric Extensions"; } leaf two-way-max-delay { type uint32 { @@ -452,11 +430,11 @@ module ietf-te-packet-types { reference "RFC 7471: OSPF Traffic Engineering (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"; + Using TE Metric Extensions"; } leaf two-way-delay-variation { type uint32 { @@ -477,11 +455,11 @@ module ietf-te-packet-types { 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"; + Extensions + RFC 7823: Performance-Based Path Selection for + Explicitly Routed Label Switched Paths (LSPs) + Using TE Metric Extensions"; } leaf two-way-packet-loss { type decimal64 { @@ -504,13 +482,11 @@ module ietf-te-packet-types { "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"; + "RFC 7471: OSPF Traffic Engineering (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"; } } } @@ -555,10 +531,6 @@ module ietf-te-packet-types { } } - // CHANGE NOTE: The grouping - // one-way-performance-metrics-gauge-packet has been added in - // this module revision - // RFC Editor: remove the note above and this note grouping one-way-performance-metrics-gauge-packet { description "One-way packet PM throttle grouping. @@ -642,10 +614,6 @@ module ietf-te-packet-types { } } - // CHANGE NOTE: The grouping - // two-way-performance-metrics-gauge-packet has been added in - // this module revision - // RFC Editor: remove the note above and this note grouping two-way-performance-metrics-gauge-packet { description "Two-way packet PM throttle grouping. @@ -714,9 +682,6 @@ module ietf-te-packet-types { } } - // CHANGE NOTE: The bandwidth-profile-parameters below has been - // added in this module revision - // RFC Editor: remove the note above and this note grouping bandwidth-profile-parameters { description "Common parameters to define bandwidth profiles in packet @@ -759,9 +724,6 @@ module ietf-te-packet-types { } } - // 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 "Bandwidth attributes for TE Packet paths."; @@ -831,9 +793,6 @@ module ietf-te-packet-types { } } - // 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 "Bandwidth attributes for Packet TE links."; diff --git a/ietf-te-types.tree.fold b/ietf-te-types.tree.fold deleted file mode 100644 index b335380..0000000 --- a/ietf-te-types.tree.fold +++ /dev/null @@ -1,690 +0,0 @@ -=============== NOTE: '\' line wrapping per RFC 8792 ================ - -module: ietf-te-types - - grouping te-bandwidth: - +-- te-bandwidth - +-- (technology)? - +--:(generic) - +-- generic? te-bandwidth - grouping te-label: - +-- te-label - +-- (technology)? - | +--:(generic) - | +-- generic? rt-types:generalized-label - +-- direction? te-label-direction - grouping te-topology-identifier: - +-- te-topology-identifier - +-- provider-id? te-global-id - +-- client-id? te-global-id - +-- topology-id? te-topology-id - grouping performance-metrics-one-way-delay-loss: - +-- one-way-delay? uint32 - +-- one-way-delay-normality? - te-types:performance-metrics-normality - grouping performance-metrics-two-way-delay-loss: - +-- two-way-delay? uint32 - +-- two-way-delay-normality? - te-types:performance-metrics-normality - grouping performance-metrics-one-way-bandwidth: - +-- one-way-residual-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-residual-bandwidth-normality? - | te-types:performance-metrics-normality - +-- one-way-available-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-available-bandwidth-normality? - | te-types:performance-metrics-normality - +-- one-way-utilized-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-utilized-bandwidth-normality? - te-types:performance-metrics-normality - grouping one-way-performance-metrics: - +-- one-way-delay? uint32 - +-- one-way-residual-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-available-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-utilized-bandwidth? - rt-types:bandwidth-ieee-float32 - grouping two-way-performance-metrics: - +-- two-way-delay? uint32 - grouping performance-metrics-thresholds: - +-- one-way-delay? uint32 - +-- one-way-residual-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-available-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-utilized-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- two-way-delay? uint32 - grouping performance-metrics-attributes: - +-- performance-metrics-one-way - | +-- one-way-delay? uint32 - | +-- one-way-delay-normality? - | | te-types:performance-metrics-normality - | +-- one-way-residual-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-residual-bandwidth-normality? - | | te-types:performance-metrics-normality - | +-- one-way-available-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-available-bandwidth-normality? - | | te-types:performance-metrics-normality - | +-- one-way-utilized-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-utilized-bandwidth-normality? - | te-types:performance-metrics-normality - +-- performance-metrics-two-way - +-- two-way-delay? uint32 - +-- two-way-delay-normality? - te-types:performance-metrics-normality - grouping performance-metrics-throttle-container: - +-- throttle - +-- one-way-delay-offset? uint32 - +-- measure-interval? uint32 - +-- advertisement-interval? uint32 - +-- suppression-interval? uint32 - +-- threshold-out - | +-- one-way-delay? uint32 - | +-- one-way-residual-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-available-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-utilized-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- two-way-delay? uint32 - +-- threshold-in - | +-- one-way-delay? uint32 - | +-- one-way-residual-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-available-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- one-way-utilized-bandwidth? - | | rt-types:bandwidth-ieee-float32 - | +-- two-way-delay? uint32 - +-- threshold-accelerated-advertisement - +-- one-way-delay? uint32 - +-- one-way-residual-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-available-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- one-way-utilized-bandwidth? - | rt-types:bandwidth-ieee-float32 - +-- two-way-delay? uint32 - grouping explicit-route-hop: - +-- (type)? - +--:(numbered-node-hop) - | +-- numbered-node-hop - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - +--:(numbered-link-hop) - | +-- numbered-link-hop - | +-- link-tp-id te-tp-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(unnumbered-link-hop) - | +-- unnumbered-link-hop - | +-- link-tp-id-uri? nt:tp-id - | +-- link-tp-id? te-tp-id - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(as-number) - | +-- as-number-hop - | +-- as-number inet:as-number - | +-- hop-type? te-hop-type - +--:(label) - +-- label-hop - +-- te-label - +-- (technology)? - | +--:(generic) - | +-- generic? rt-types:generalized-label - +-- direction? te-label-direction - grouping record-route-state: - +-- index? uint32 - +-- (type)? - +--:(numbered-node-hop) - | +-- numbered-node-hop - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- flags* path-attribute-flags - +--:(numbered-link-hop) - | +-- numbered-link-hop - | +-- link-tp-id te-tp-id - | +-- flags* path-attribute-flags - +--:(unnumbered-link-hop) - | +-- unnumbered-link-hop - | +-- link-tp-id-uri? nt:tp-id - | +-- link-tp-id? te-tp-id - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- flags* path-attribute-flags - +--:(label) - +-- label-hop - +-- te-label - | +-- (technology)? - | | +--:(generic) - | | +-- generic? rt-types:generalized-label - | +-- direction? te-label-direction - +-- flags* path-attribute-flags - grouping label-restriction-info: - +-- restriction? enumeration - +-- index? uint32 - +-- label-start - | +-- te-label - | +-- (technology)? - | | +--:(generic) - | | +-- generic? rt-types:generalized-label - | +-- direction? te-label-direction - +-- label-end - | +-- te-label - | +-- (technology)? - | | +--:(generic) - | | +-- generic? rt-types:generalized-label - | +-- direction? te-label-direction - +-- label-step - | +-- (technology)? - | +--:(generic) - | +-- generic? int32 - +-- range-bitmap? yang:hex-string - grouping label-set-info: - +-- label-restrictions - +-- label-restriction* [index] - +-- restriction? enumeration - +-- index? uint32 - +-- label-start - | +-- te-label - | +-- (technology)? - | | +--:(generic) - | | +-- generic? rt-types:generalized-label - | +-- direction? te-label-direction - +-- label-end - | +-- te-label - | +-- (technology)? - | | +--:(generic) - | | +-- generic? rt-types:generalized-label - | +-- direction? te-label-direction - +-- label-step - | +-- (technology)? - | +--:(generic) - | +-- generic? int32 - +-- range-bitmap? yang:hex-string - grouping optimization-metric-entry: - +-- metric-type? identityref - +-- weight? uint8 - +-- explicit-route-exclude-objects - | +-- route-object-exclude-object* [index] - | +-- index? uint32 - | +-- (type)? - | +--:(numbered-node-hop) - | | +-- numbered-node-hop - | | +-- node-id-uri? nw:node-id - | | +-- node-id? te-node-id - | | +-- hop-type? te-hop-type - | +--:(numbered-link-hop) - | | +-- numbered-link-hop - | | +-- link-tp-id te-tp-id - | | +-- hop-type? te-hop-type - | | +-- direction? te-link-direction - | +--:(unnumbered-link-hop) - | | +-- unnumbered-link-hop - | | +-- link-tp-id-uri? nt:tp-id - | | +-- link-tp-id? te-tp-id - | | +-- node-id-uri? nw:node-id - | | +-- node-id? te-node-id - | | +-- hop-type? te-hop-type - | | +-- direction? te-link-direction - | +--:(as-number) - | | +-- as-number-hop - | | +-- as-number inet:as-number - | | +-- hop-type? te-hop-type - | +--:(label) - | | +-- label-hop - | | +-- te-label - | | +-- (technology)? - | | | +--:(generic) - | | | +-- generic? rt-types:generalized-label - | | +-- direction? te-label-direction - | +--:(srlg) - | +-- srlg - | +-- srlg? uint32 - +-- explicit-route-include-objects - +-- route-object-include-object* [index] - +-- index? uint32 - +-- (type)? - +--:(numbered-node-hop) - | +-- numbered-node-hop - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - +--:(numbered-link-hop) - | +-- numbered-link-hop - | +-- link-tp-id te-tp-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(unnumbered-link-hop) - | +-- unnumbered-link-hop - | +-- link-tp-id-uri? nt:tp-id - | +-- link-tp-id? te-tp-id - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(as-number) - | +-- as-number-hop - | +-- as-number inet:as-number - | +-- hop-type? te-hop-type - +--:(label) - +-- label-hop - +-- te-label - +-- (technology)? - | +--:(generic) - | +-- generic? rt-types:generalized-label - +-- direction? te-label-direction - grouping common-constraints: - +-- te-bandwidth - | +-- (technology)? - | +--:(generic) - | +-- generic? te-bandwidth - +-- link-protection? identityref - +-- setup-priority? uint8 - +-- hold-priority? uint8 - +-- signaling-type? identityref - grouping tunnel-constraints: - +-- network-id? nw:network-id - +-- te-topology-identifier - | +-- provider-id? te-global-id - | +-- client-id? te-global-id - | +-- topology-id? te-topology-id - +-- te-bandwidth - | +-- (technology)? - | +--:(generic) - | +-- generic? te-bandwidth - +-- link-protection? identityref - +-- setup-priority? uint8 - +-- hold-priority? uint8 - +-- signaling-type? identityref - grouping path-constraints-route-objects: - +-- explicit-route-objects - +-- route-object-exclude-always* [index] - | +-- index? uint32 - | +-- (type)? - | +--:(numbered-node-hop) - | | +-- numbered-node-hop - | | +-- node-id-uri? nw:node-id - | | +-- node-id? te-node-id - | | +-- hop-type? te-hop-type - | +--:(numbered-link-hop) - | | +-- numbered-link-hop - | | +-- link-tp-id te-tp-id - | | +-- hop-type? te-hop-type - | | +-- direction? te-link-direction - | +--:(unnumbered-link-hop) - | | +-- unnumbered-link-hop - | | +-- link-tp-id-uri? nt:tp-id - | | +-- link-tp-id? te-tp-id - | | +-- node-id-uri? nw:node-id - | | +-- node-id? te-node-id - | | +-- hop-type? te-hop-type - | | +-- direction? te-link-direction - | +--:(as-number) - | | +-- as-number-hop - | | +-- as-number inet:as-number - | | +-- hop-type? te-hop-type - | +--:(label) - | +-- label-hop - | +-- te-label - | +-- (technology)? - | | +--:(generic) - | | +-- generic? rt-types:generalized-label - | +-- direction? te-label-direction - +-- route-object-include-exclude* [index] - +-- explicit-route-usage? identityref - +-- index? uint32 - +-- (type)? - +--:(numbered-node-hop) - | +-- numbered-node-hop - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - +--:(numbered-link-hop) - | +-- numbered-link-hop - | +-- link-tp-id te-tp-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(unnumbered-link-hop) - | +-- unnumbered-link-hop - | +-- link-tp-id-uri? nt:tp-id - | +-- link-tp-id? te-tp-id - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(as-number) - | +-- as-number-hop - | +-- as-number inet:as-number - | +-- hop-type? te-hop-type - +--:(label) - | +-- label-hop - | +-- te-label - | +-- (technology)? - | | +--:(generic) - | | +-- generic? rt-types:generalized-label - | +-- direction? te-label-direction - +--:(srlg) - +-- srlg - +-- srlg? uint32 - grouping path-route-include-objects: - +-- route-object-include-object* [index] - +-- index? uint32 - +-- (type)? - +--:(numbered-node-hop) - | +-- numbered-node-hop - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - +--:(numbered-link-hop) - | +-- numbered-link-hop - | +-- link-tp-id te-tp-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(unnumbered-link-hop) - | +-- unnumbered-link-hop - | +-- link-tp-id-uri? nt:tp-id - | +-- link-tp-id? te-tp-id - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(as-number) - | +-- as-number-hop - | +-- as-number inet:as-number - | +-- hop-type? te-hop-type - +--:(label) - +-- label-hop - +-- te-label - +-- (technology)? - | +--:(generic) - | +-- generic? rt-types:generalized-label - +-- direction? te-label-direction - grouping path-route-exclude-objects: - +-- route-object-exclude-object* [index] - +-- index? uint32 - +-- (type)? - +--:(numbered-node-hop) - | +-- numbered-node-hop - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - +--:(numbered-link-hop) - | +-- numbered-link-hop - | +-- link-tp-id te-tp-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(unnumbered-link-hop) - | +-- unnumbered-link-hop - | +-- link-tp-id-uri? nt:tp-id - | +-- link-tp-id? te-tp-id - | +-- node-id-uri? nw:node-id - | +-- node-id? te-node-id - | +-- hop-type? te-hop-type - | +-- direction? te-link-direction - +--:(as-number) - | +-- as-number-hop - | +-- as-number inet:as-number - | +-- hop-type? te-hop-type - +--:(label) - | +-- label-hop - | +-- te-label - | +-- (technology)? - | | +--:(generic) - | | +-- generic? rt-types:generalized-label - | +-- direction? te-label-direction - +--:(srlg) - +-- srlg - +-- srlg? uint32 - grouping generic-path-metric-bounds: - +-- path-metric-bounds - +-- path-metric-bound* [metric-type] - +-- metric-type? identityref - +-- upper-bound? uint64 - grouping generic-path-optimization: - +-- optimizations - | +-- (algorithm)? - | +--:(metric) {path-optimization-metric}? - | | +-- optimization-metric* [metric-type] - | | | +-- metric-type? identityref - | | | +-- weight? uint8 - | | | +-- explicit-route-exclude-objects - | | | | +-- route-object-exclude-object* [index] - | | | | +-- index? uint32 - | | | | +-- (type)? - | | | | +--:(numbered-node-hop) - | | | | | +-- numbered-node-hop - | | | | | +-- node-id-uri? nw:node-id - | | | | | +-- node-id? te-node-id - | | | | | +-- hop-type? te-hop-type - | | | | +--:(numbered-link-hop) - | | | | | +-- numbered-link-hop - | | | | | +-- link-tp-id te-tp-id - | | | | | +-- hop-type? te-hop-type - | | | | | +-- direction? te-link-direction - | | | | +--:(unnumbered-link-hop) - | | | | | +-- unnumbered-link-hop - | | | | | +-- link-tp-id-uri? nt:tp-id - | | | | | +-- link-tp-id? te-tp-id - | | | | | +-- node-id-uri? nw:node-id - | | | | | +-- node-id? te-node-id - | | | | | +-- hop-type? te-hop-type - | | | | | +-- direction? - | | | | | te-link-direction - | | | | +--:(as-number) - | | | | | +-- as-number-hop - | | | | | +-- as-number inet:as-number - | | | | | +-- hop-type? te-hop-type - | | | | +--:(label) - | | | | | +-- label-hop - | | | | | +-- te-label - | | | | | +-- (technology)? - | | | | | | +--:(generic) - | | | | | | +-- generic? - | | | | | | rt-types:generalized\ --label - | | | | | +-- direction? - | | | | | te-label-direction - | | | | +--:(srlg) - | | | | +-- srlg - | | | | +-- srlg? uint32 - | | | +-- explicit-route-include-objects - | | | +-- route-object-include-object* [index] - | | | +-- index? uint32 - | | | +-- (type)? - | | | +--:(numbered-node-hop) - | | | | +-- numbered-node-hop - | | | | +-- node-id-uri? nw:node-id - | | | | +-- node-id? te-node-id - | | | | +-- hop-type? te-hop-type - | | | +--:(numbered-link-hop) - | | | | +-- numbered-link-hop - | | | | +-- link-tp-id te-tp-id - | | | | +-- hop-type? te-hop-type - | | | | +-- direction? te-link-direction - | | | +--:(unnumbered-link-hop) - | | | | +-- unnumbered-link-hop - | | | | +-- link-tp-id-uri? nt:tp-id - | | | | +-- link-tp-id? te-tp-id - | | | | +-- node-id-uri? nw:node-id - | | | | +-- node-id? te-node-id - | | | | +-- hop-type? te-hop-type - | | | | +-- direction? - | | | | te-link-direction - | | | +--:(as-number) - | | | | +-- as-number-hop - | | | | +-- as-number inet:as-number - | | | | +-- hop-type? te-hop-type - | | | +--:(label) - | | | +-- label-hop - | | | +-- te-label - | | | +-- (technology)? - | | | | +--:(generic) - | | | | +-- generic? - | | | | rt-types:generalized\ --label - | | | +-- direction? - | | | te-label-direction - | | x-- tiebreakers - | | x-- tiebreaker* [tiebreaker-type] - | | x-- tiebreaker-type? identityref - | +--:(objective-function) - | {path-optimization-objective-function}? - | +-- objective-function - | +-- objective-function-type? identityref - +-- tiebreaker? identityref - grouping generic-path-affinities: - +-- path-affinities-values - | +-- path-affinities-value* [usage] - | +-- usage? identityref - | +-- value? admin-groups - +-- path-affinity-names - +-- path-affinity-name* [usage] - +-- usage? identityref - +-- affinity-name* [name] - +-- name? string - grouping generic-path-srlgs: - +-- path-srlgs-lists - | +-- path-srlgs-list* [usage] - | +-- usage? identityref - | +-- values* srlg - +-- path-srlgs-names - +-- path-srlgs-name* [usage] - +-- usage? identityref - +-- names* string - grouping generic-path-disjointness: - +-- disjointness? te-path-disjointness - grouping common-path-constraints-attributes: - +-- te-bandwidth - | +-- (technology)? - | +--:(generic) - | +-- generic? te-bandwidth - +-- link-protection? identityref - +-- setup-priority? uint8 - +-- hold-priority? uint8 - +-- signaling-type? identityref - +-- path-metric-bounds - | +-- path-metric-bound* [metric-type] - | +-- metric-type? identityref - | +-- upper-bound? uint64 - +-- path-affinities-values - | +-- path-affinities-value* [usage] - | +-- usage? identityref - | +-- value? admin-groups - +-- path-affinity-names - | +-- path-affinity-name* [usage] - | +-- usage? identityref - | +-- affinity-name* [name] - | +-- name? string - +-- path-srlgs-lists - | +-- path-srlgs-list* [usage] - | +-- usage? identityref - | +-- values* srlg - +-- path-srlgs-names - +-- path-srlgs-name* [usage] - +-- usage? identityref - +-- names* string - grouping generic-path-constraints: - +-- path-constraints - +-- te-bandwidth - | +-- (technology)? - | +--:(generic) - | +-- generic? te-bandwidth - +-- link-protection? identityref - +-- setup-priority? uint8 - +-- hold-priority? uint8 - +-- signaling-type? identityref - +-- path-metric-bounds - | +-- path-metric-bound* [metric-type] - | +-- metric-type? identityref - | +-- upper-bound? uint64 - +-- path-affinities-values - | +-- path-affinities-value* [usage] - | +-- usage? identityref - | +-- value? admin-groups - +-- path-affinity-names - | +-- path-affinity-name* [usage] - | +-- usage? identityref - | +-- affinity-name* [name] - | +-- name? string - +-- path-srlgs-lists - | +-- path-srlgs-list* [usage] - | +-- usage? identityref - | +-- values* srlg - +-- path-srlgs-names - | +-- path-srlgs-name* [usage] - | +-- usage? identityref - | +-- names* string - +-- disjointness? te-path-disjointness - grouping generic-path-properties: - +--ro path-properties - +--ro path-metric* [metric-type] - | +--ro metric-type? identityref - | +--ro accumulative-value? uint64 - +--ro path-affinities-values - | +--ro path-affinities-value* [usage] - | +--ro usage? identityref - | +--ro value? admin-groups - +--ro path-affinity-names - | +--ro path-affinity-name* [usage] - | +--ro usage? identityref - | +--ro affinity-name* [name] - | +--ro name? string - +--ro path-srlgs-lists - | +--ro path-srlgs-list* [usage] - | +--ro usage? identityref - | +--ro values* srlg - +--ro path-srlgs-names - | +--ro path-srlgs-name* [usage] - | +--ro usage? identityref - | +--ro names* string - +--ro path-route-objects - +--ro path-route-object* [index] - +--ro index? uint32 - +--ro (type)? - +--:(numbered-node-hop) - | +--ro numbered-node-hop - | +--ro node-id-uri? nw:node-id - | +--ro node-id? te-node-id - | +--ro hop-type? te-hop-type - +--:(numbered-link-hop) - | +--ro numbered-link-hop - | +--ro link-tp-id te-tp-id - | +--ro hop-type? te-hop-type - | +--ro direction? te-link-direction - +--:(unnumbered-link-hop) - | +--ro unnumbered-link-hop - | +--ro link-tp-id-uri? nt:tp-id - | +--ro link-tp-id? te-tp-id - | +--ro node-id-uri? nw:node-id - | +--ro node-id? te-node-id - | +--ro hop-type? te-hop-type - | +--ro direction? te-link-direction - +--:(as-number) - | +--ro as-number-hop - | +--ro as-number inet:as-number - | +--ro hop-type? te-hop-type - +--:(label) - +--ro label-hop - +--ro te-label - +--ro (technology)? - | +--:(generic) - | +--ro generic? - | rt-types:generalized-label - +--ro direction? te-label-direction - grouping encoding-and-switching-type: - +-- encoding? identityref - +-- switching-type? identityref - grouping te-generic-node-id: - +-- id? te-gen-node-id - +-- type? enumeration diff --git a/ietf-te-types.yang b/ietf-te-types.yang index 34ce92f..dddd2f4 100644 --- a/ietf-te-types.yang +++ b/ietf-te-types.yang @@ -77,7 +77,7 @@ module ietf-te-types { 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-09-13 { + revision 2024-10-30 { description "This revision adds the following new identities: - lsp-provisioning-error-reason; @@ -452,9 +452,6 @@ module ietf-te-types { 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; @@ -583,10 +580,10 @@ module ietf-te-types { description "Defines the status of a recovery action."; reference - "RFC 4427: Recovery (Protection and Restoration) Terminology + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching - (GMPLS) - RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection"; + (GMPLS)"; } typedef te-template-name { @@ -661,9 +658,6 @@ module ietf-te-types { 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 { @@ -750,9 +744,6 @@ module ietf-te-types { * 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 "Base identity for LSP provisioning errors."; @@ -763,604 +754,589 @@ module ietf-te-types { "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 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 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 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 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 - "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 + "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 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 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 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; - 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 boundary-rerouting-desired { + base lsp-attributes-flags; + 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 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 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 { - 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 contiguous-lsp-desired { + 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 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 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 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; - 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 oob-mapping-flag { + base lsp-attributes-flags; + 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 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-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 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 - Link Group (SRLG) Information"; - } + 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 + 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 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 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 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-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; - description - "Extra-Traffic protected link type."; - reference - "RFC 4427: Recovery (Protection and Restoration) Terminology - for Generalized Multi-Protocol Label Switching - (GMPLS)"; - } + identity link-protection-extra-traffic { + base link-protection-type; + description + "Extra-Traffic 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-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-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-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-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 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; - 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-recovery { + base association-type; + 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-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-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)"; - } + 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; - 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"; - } + 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 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-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-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)"; - } + 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)"; + } - // 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 - 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)"; - } + 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-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)"; - } + 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-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 - Computation Element Communication Protocol (PCEP)"; - } + 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)"; + } + + 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 + 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"; - } + 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"; - } + 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 { - 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 path-explicitly-defined { + 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-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-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"; - } + 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"; + } 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-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 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 @@ -1368,26 +1344,26 @@ module ietf-te-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-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-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."; - } + identity tunnel-action-switchpath { + base tunnel-action-type; + description + "TE tunnel action that switches the tunnel's LSP to use the + specified path."; + } identity te-action-result { description @@ -1395,188 +1371,179 @@ module ietf-te-types { are derived."; } - identity te-action-success { - base te-action-result; - description - "TE action was successful."; - } + 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 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-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-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."; - } + 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; - 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-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."; + } 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-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 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-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-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-path-computation-failed { + base lsp-state-type; + description + "State path computation failed."; + } - identity lsp-state-setting-up { - base lsp-state-type; - description - "State is being set up."; - } + identity lsp-state-setting-up { + 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-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-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-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-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 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"; - } + 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"; + } - 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 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-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 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; description @@ -1585,40 +1552,40 @@ module ietf-te-types { 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)"; + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; } - 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-preconfigured { + base restoration-scheme-type; + description + "Restoration LSP is preconfigured prior to the failure."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; + } - 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-precomputed { + base restoration-scheme-type; + description + "Restoration LSP is precomputed prior to the failure."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; + } - 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 restoration-scheme-presignaled { + base restoration-scheme-type; + description + "Restoration LSP is presignaled prior to the failure."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery"; + } identity lsp-protection-type { description @@ -1629,208 +1596,219 @@ module ietf-te-types { Recovery"; } - identity lsp-protection-unprotected { - base lsp-protection-type; - description - "'Unprotected' 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-unprotected { + base lsp-protection-type; + description + "'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"; - } + 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-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"; - } + 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"; + } - 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-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-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-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-extra-traffic { + base lsp-protection-type; + description + "Extra-Traffic 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-state { description "Base identity of protection states for reporting purposes."; } - identity normal { - base lsp-protection-state; - description - "Normal state."; - } + identity normal { + base lsp-protection-state; + description + "Normal state."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - identity signal-fail-of-protection { - 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 signal-fail-of-protection { + 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 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 lockout-of-protection { + base lsp-protection-state; + description + "A Loss of Protection (LoP) command is active."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 forced-switch { + base lsp-protection-state; + description + "A forced switchover command is active."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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-fail { + base lsp-protection-state; + description + "There is a signal fail condition on either the working path + or the protection path."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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)"; - } + 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 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - 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 manual-switch { + base lsp-protection-state; + description + "A manual switchover command is active."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 wait-to-restore { + base lsp-protection-state; + description + "A Wait-to-Restore (WTR) timer is running."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 do-not-revert { + base lsp-protection-state; + description + "A Do Not Revert (DNR) condition is active because of + non-revertive behavior."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + 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 failure-of-protocol { + base lsp-protection-state; + description + "LSP protection is not working because of a protocol failure + condition."; + reference + "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection + to Match the Operational Expectations of + Synchronous Digital Hierarchy, Optical Transport + Network, and Ethernet Transport Network Operators + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } identity protection-external-commands { description @@ -1838,200 +1816,228 @@ module ietf-te-types { used for troubleshooting purposes are derived."; } - identity action-freeze { - base protection-external-commands; - description - "A temporary configuration action initiated by an operator - 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-freeze { + base protection-external-commands; + description + "A temporary configuration action initiated by an operator + command that prevents any switchover action from being taken + and, as such, freezes the current state."; + reference + "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection + to Match the Operational Expectations of + Synchronous Digital Hierarchy, Optical Transport + Network, and Ethernet Transport Network Operators + 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)"; - } + identity clear-freeze { + base protection-external-commands; + description + "An action that clears the active freeze state."; + reference + "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection + to Match the Operational Expectations of + Synchronous Digital Hierarchy, Optical Transport + Network, and Ethernet Transport Network Operators + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - 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-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 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + 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)"; - } + identity clear-lockout-of-normal { + base protection-external-commands; + description + "An action that clears the active lockout of the + normal state."; + reference + "RFC 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + 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: Generic protection switching - Linear trail and - subnetwork protection - Edition 4.0 (05/2014)"; - } + 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 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - 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 - "RFC 4427: Recovery (Protection and Restoration) Terminology - for Generalized Multi-Protocol Label Switching - (GMPLS)"; - } + 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 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + 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 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 4872: RSVP-TE Extensions in Support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS) + Recovery + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - 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 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 + "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection + to Match the Operational Expectations of + Synchronous Digital Hierarchy, Optical Transport + Network, and Ethernet Transport Network Operators + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - 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 clear { + base protection-external-commands; + description + "An action that clears the active near-end lockout of a + protection, forced switchover, manual switchover, + Wait-to-Restore (WTR) state, or exercise command."; + reference + "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection + RFC 4427: Recovery (Protection and Restoration) Terminology + for Generalized Multi-Protocol Label Switching + (GMPLS)"; + } - identity switching-l2sc { - base switching-capabilities; + identity switching-capabilities { description - "Layer-2 Switch Capable (L2SC)."; + "Base identity for interface switching capabilities."; 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"; - } + 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-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-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-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-l2sc { + base switching-capabilities; + description + "Layer-2 Switch Capable (L2SC)."; + reference + "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) + Signaling Functional Description"; + } - 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-tdm { + base switching-capabilities; + description + "Time-Division-Multiplex Capable (TDM)."; + 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 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 @@ -2041,107 +2047,107 @@ module ietf-te-types { Signaling Functional Description"; } - identity lsp-encoding-packet { - base lsp-encoding-types; - description - "Packet LSP encoding."; - reference - "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) - Signaling Functional Description"; - } + identity lsp-encoding-packet { + base lsp-encoding-types; + description + "Packet LSP encoding."; + 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-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-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-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-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"; - } + 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"; + } - 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 { + 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-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-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-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"; - } + 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"; + } identity path-signaling-type { description @@ -2149,25 +2155,25 @@ module ietf-te-types { are derived."; } - identity path-setup-static { - base path-signaling-type; - description - "Static LSP provisioning path setup."; - } + 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-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-setup-sr { + base path-signaling-type; + description + "Segment-routing path setup."; + } identity path-scope-type { description @@ -2175,63 +2181,57 @@ module ietf-te-types { derived."; } - identity path-scope-segment { - base path-scope-type; - description - "Path scope segment."; - reference - "RFC 4873: GMPLS Segment Recovery"; - } + 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"; - } + identity path-scope-end-to-end { + base path-scope-type; + description + "Path scope end to end."; + reference + "RFC 4873: GMPLS Segment Recovery"; + } identity route-usage-type { description "Base identity for route usage."; } - identity route-include-object { - base route-usage-type; - description - "'Include route' object."; - } + 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-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)"; - } + 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 @@ -2243,10 +2243,6 @@ module ietf-te-types { 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 @@ -2325,10 +2321,6 @@ module ietf-te-types { 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; @@ -2336,10 +2328,6 @@ module ietf-te-types { "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 @@ -2349,10 +2337,6 @@ module ietf-te-types { 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 @@ -2362,10 +2346,6 @@ module ietf-te-types { 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 @@ -2375,10 +2355,6 @@ module ietf-te-types { 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 @@ -2391,26 +2367,18 @@ module ietf-te-types { 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 - "RFC YYYY: Carrying SR-Algorithm information in PCE-based - Networks, Section 3.5.1"; + "I-D.ietf-pce-sid-algo: Carrying SR-Algorithm information + in PCE-based Networks, + draft-ietf-pce-sid-algo-14, + Sections 3.5.1 and 3.5.2"; } - // RFC Editor: replace YYYY with actual RFC number assigned to - // [I-D.ietf-pce-sid-algo] and remove this note - // 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 @@ -2426,9 +2394,6 @@ module ietf-te-types { (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 @@ -2436,9 +2401,6 @@ module ietf-te-types { 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 @@ -2451,69 +2413,66 @@ module ietf-te-types { "Base identity for the path tiebreaker type."; } - identity path-tiebreaker-minfill { - base path-tiebreaker-type; - description - "Min-Fill LSP path placement: selects the path with the most - available bandwidth (load balance LSPs over more links)."; - } + identity path-tiebreaker-minfill { + base path-tiebreaker-type; + description + "Min-Fill LSP path placement: selects the path with the most + available bandwidth (load balance LSPs over more links)."; + } - identity path-tiebreaker-maxfill { - base path-tiebreaker-type; - description - "Max-Fill LSP path placement: selects the path with the least - available bandwidth (packing more LSPs over few links)."; - } + identity path-tiebreaker-maxfill { + base path-tiebreaker-type; + description + "Max-Fill LSP path placement: selects the path with the least + available bandwidth (packing more LSPs over few links)."; + } - identity path-tiebreaker-random { - base path-tiebreaker-type; - description - "Random 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"; + "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels + RFC 2702: Requirements for Traffic Engineering Over MPLS"; } - identity resource-aff-include-all { - base resource-affinities-type; - description - "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-all { + base resource-affinities-type; + description + "The set of attribute filters associated with a + tunnel, all of which must be present for a link + to be acceptable."; + reference + "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels + RFC 2702: Requirements for Traffic Engineering Over MPLS"; + } - 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-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 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels + RFC 2702: Requirements for Traffic Engineering Over MPLS"; + } - 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"; - } + 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 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels + RFC 2702: Requirements for Traffic Engineering Over MPLS"; + } - // 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."; @@ -2522,63 +2481,61 @@ module ietf-te-types { Engineering"; } - identity not-optimized { - base te-optimization-criterion; - description - "Optimization is not applied."; - } + identity not-optimized { + base te-optimization-criterion; + description + "Optimization is not applied."; + } - identity cost { - base te-optimization-criterion; - description - "Optimized on cost."; - reference - "RFC 5541: Encoding of Objective Functions in the Path - Computation Element Communication Protocol (PCEP)"; - } + identity cost { + 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 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-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-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-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."; - } + 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 - // 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."; @@ -2842,10 +2799,6 @@ module ietf-te-types { /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."; @@ -2876,10 +2829,6 @@ module ietf-te-types { "RFC 9012: The BGP Tunnel Encapsulation Attribute"; } - // 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."; @@ -2965,10 +2914,6 @@ module ietf-te-types { 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."; @@ -3138,10 +3083,10 @@ module ietf-te-types { PM."; reference "RFC 7471: OSPF Traffic Engineering (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"; + Extensions"; leaf one-way-delay { type uint32 { range "0..16777215"; @@ -3163,10 +3108,10 @@ module ietf-te-types { generic TE PM as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (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"; + Extensions"; leaf two-way-delay { type uint32 { range "0..16777215"; @@ -3188,10 +3133,10 @@ module ietf-te-types { as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (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"; + Extensions"; leaf one-way-residual-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; @@ -3320,10 +3265,10 @@ module ietf-te-types { "One-way link performance information in real time."; reference "RFC 7471: OSPF Traffic Engineering (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"; + Extensions"; uses performance-metrics-one-way-delay-loss; uses performance-metrics-one-way-bandwidth; } @@ -3352,10 +3297,10 @@ module ietf-te-types { "Link performance information in real time."; reference "RFC 7471: OSPF Traffic Engineering (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"; + Extensions"; leaf one-way-delay-offset { type uint32 { range "0..16777215"; @@ -3423,9 +3368,6 @@ module ietf-te-types { * 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."; @@ -3576,9 +3518,6 @@ module ietf-te-types { } } - // 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."; @@ -3864,9 +3803,6 @@ module ietf-te-types { } } - // 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."; @@ -3951,9 +3887,6 @@ module ietf-te-types { } } - // 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 @@ -3967,9 +3900,6 @@ module ietf-te-types { 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 @@ -4099,9 +4029,6 @@ module ietf-te-types { } } - // 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."; @@ -4144,9 +4071,6 @@ module ietf-te-types { } } - // 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."; @@ -4410,9 +4334,6 @@ module ietf-te-types { } } - // 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 @@ -4439,9 +4360,6 @@ module ietf-te-types { } } - // CHANGE NOTE: The grouping te-generic-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.";