Internet-Draft | TE Common YANG Types | September 2024 |
Busi, et al. | Expires 31 March 2025 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 31 March 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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].¶
This document adds new common data types, identities, and groupings to both the "ietf-te-types" and the "ietf-te-packet-types" YANG models and obsoletes [RFC8776]. For further details, refer to Appendix B.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 used in this document follow the notation defined in [RFC8340].¶
Names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in Table 1.¶
Prefix | YANG module | Reference |
---|---|---|
yang | ietf-yang-types | Section 3 of [RFC6991] |
inet | ietf-inet-types | Section 4 of [RFC6991] |
rt-types | ietf-routing-types | [RFC8294] |
te-types | ietf-te-types | RFCXXXX |
te-packet-types | ietf-te-packet-types | RFCXXXX |
RFC Editor: Please replace XXXX through this document with the RFC number assigned to this document. Please remove this note.¶
Automatic Protection Switching¶
Differentiated Services Traffic Engineering¶
Generalized Multiprotocol Label Switching¶
Label Edge Router¶
Label Switched Path¶
Label Switching Router¶
Multiprotocol Label Switching¶
Non-Broadcast Multi-Access¶
Performance Metrics¶
Resource Reservation Protocol¶
Signal Degrade¶
Signal Fail¶
Shared Risk Link Group¶
Traffic Engineering¶
Wait-to-Restore¶
This document defines two YANG modules for common TE types: "ietf-te-types" for TE generic types and "ietf-te-packet-types" for packet-specific types. Other technology-specific TE types are outside the scope of this document.¶
The "ietf-te-types" module (Section 4) contains common TE types that are independent and agnostic of any specific technology or control-plane instance.¶
The "ietf-te-types" module contains the following YANG reusable groupings:¶
A YANG grouping that defines the generic TE bandwidth. The modeling structure allows augmentation for each technology. For unspecified technologies, the string-encoded "te-bandwidth" type is used.¶
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.¶
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 configurable thresholds for advertisement suppression and measurement intervals.¶
The "ietf-te-types" module contains the following YANG reusable data types:¶
A type representing the Differentiated Services (DS) Class-Type of traffic as defined in [RFC4124].¶
An enumerated type for specifying the forward or reverse direction of a label.¶
An enumerated type for specifying that a hop is loose or strict.¶
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 [RFC6370] and Section 3 of [RFC5003]. This attribute type is used solely to provide a globally unique context for TE topologies.¶
A type representing the identifier for a node in a TE topology. The identifier is represented either as 4 octets in dotted-quad notation or as 16 octets in full, mixed, shortened, or shortened-mixed IPv6 address notation.¶
This attribute MAY be mapped to the Router Address TLV described in Section 2.4.1 of [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 described in Section 3.2.1 of [RFC6119].¶
The reachability of such a TE node MAY be achieved by a mechanism such as that described in Section 6.2 of [RFC6827].¶
A type representing the identifier for a topology. It is optional to have one or more prefixes at the beginning, separated by colons. The prefixes can be "network-types" as defined in the "ietf-network" module in [RFC8345], to help the user better understand the topology before further inquiry is made.¶
A type representing the identifier of a TE interface Link Termination Point (LTP) on a specific TE node where the TE link connects. This attribute is mapped to a local or remote link identifier [RFC3630] [RFC5305].¶
A type representing the different resource disjointness options for a TE tunnel path as defined in [RFC4872].¶
A union type for a TE link's classic or extended administrative groups as defined in [RFC3630], [RFC5305], and [RFC7308].¶
A type representing the Shared Risk Link Group (SRLG) as defined in [RFC4203] and [RFC5307].¶
An enumerated type for the different statuses of a recovery action as defined in [RFC4427] and [RFC6378].¶
The "ietf-te-types" module contains the following YANG reusable identities:¶
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 link protection types as defined in [RFC4872] and [RFC4427].¶
A base YANG identity for supported LSP restoration schemes as defined in [RFC4872].¶
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 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.¶
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.¶
A base YANG identity for supported TE tunnel types as defined in [RFC3209] and [RFC4875].¶
A base YANG identity for supported LSP encoding types as defined in [RFC3471].¶
A base YANG identity for supported LSP protection types as defined in [RFC4872] and [RFC4873].¶
A base YANG identity for supported interface switching capabilities as defined in [RFC3471].¶
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 path metric types as defined in [RFC3630], [RFC3785], [RFC5440], [RFC7471], [RFC8233], [RFC8570] and [I-D.ietf-pce-sid-algo].¶
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].¶
A YANG grouping that defines supported explicit routes as defined in [RFC3209] and [RFC3477].¶
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.¶
A base YANG identity for reporting LSP provisioning error reasons. No standard LPS provisioning error reasons are defined in this document.¶
A base YANG identity for reporting path computation error reasons as defined in Section 3.1.1.¶
A base YANG identity for the type of protocol origin as defined in Section 3.1.2.¶
A base YANG identity for supported SVEC objective functions as defined in [RFC5541] and [RFC8685].¶
A base YANG identity for supported SVEC objective functions as defined in [RFC5541].¶
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.¶
The "ietf-te-types" module contains the YANG reusable identities for reporting path computation error reasons as defined in [RFC5440], [RFC5441], [RFC5520], [RFC5557], [RFC8306], and [RFC8685].¶
It also defines the following additional YANG reusable identities for reporting also the following path computation error reasons:¶
A YANG identity for reporting path computation error when there is no topology with the provided topology identifier.¶
A YANG identity for reporting path computation error when 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.¶
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).¶
The "ietf-te-types" module contains the YANG reusable identities for the type of protocol origin as defined in [RFC5440] and [RFC9012].¶
It also defines the following additional YANG reusable identities for the type of protocol origin:¶
A YANG identity to be used when the type of protocol origin is an Application Programmable Interface (API).¶
The "ietf-te-packet-types" module (Section 5) covers the common types and groupings that are specific to packet technology.¶
The "ietf-te-packet-types" module contains the following YANG reusable types and groupings:¶
A base YANG identity for supported protection types that a backup or bypass tunnel can provide as defined in [RFC4090].¶
A type that represents the Diffserv-TE Class-Type as defined in [RFC4124].¶
A type that represents Diffserv-TE Bandwidth Constraints (BCs) as defined in [RFC4124].¶
A base YANG identity for supported Diffserv-TE Bandwidth Constraints Models as defined in [RFC4125], [RFC4126], and [RFC4127].¶
An enumerated type for the different options to request bandwidth for a specific tunnel.¶
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.¶
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 YANG grouping that defines common parameters for bandwidth profiles in packet networks.¶
A YANG grouping that defines the path bandwidth information and could be used in any Packet TE model (e.g., MPLS-TE topology model) for the path bandwidth representation (e.g., the bandwidth of an MPLS-TE LSP).¶
All the path and LSP bandwidth related sections in the "ietf-te-types" generic module, Section 4, need to be augmented with this grouping for the usage of Packet TE technologies.¶
A YANG grouping that defines the link bandwidth information and could be used in any Packet TE model (e.g., MPLS-TE topology) for link bandwidth representation.¶
All the link bandwidth related sections in the "ietf-te-types" generic module, Section 4, need to be augmented with this grouping for the usage of Packet TE technologies.¶
The "ietf-te-types" module imports from the following modules:¶
In addition to [RFC6991] and [RFC8294], this module references the following documents in defining the types and YANG groupings: [RFC9522], [RFC4090], [RFC4202], [RFC4328], [RFC4561], [RFC4657], [RFC4736], [RFC6004], [RFC6511], [RFC7139], [RFC7308], [RFC7551], [RFC7571], [RFC7579], and [ITU-T_G.709].¶
CHANGE NOTE: Please focus your review only on the updates to the YANG model: see also Appendix B.1.¶
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.¶
This document requests IANA to update the following URIs in the "IETF XML Registry" [RFC3688] to refer to this document:¶
URI: urn:ietf:params:xml:ns:yang:ietf-te-types Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-te-packet-types Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
This document also requests IANA to update the following YANG modules to the "YANG Module Names" registry [RFC7950]:¶
name: ietf-te-types Maintained by IANA? N namespace: urn:ietf:params:xml:ns:yang:ietf-te-types prefix: te-types reference: RFC XXXX name: ietf-te-packet-types Maintained by IANA? N namespace: urn:ietf:params:xml:ns:yang:ietf-te-packet-types prefix: te-packet-types reference: RFC XXXX¶
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 appendix presents the complete tree of the TE and Packet TE types data 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.¶
=============== 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¶
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¶
This version adds new common data types, identities, and groupings to the YANG modules. It also updates some of the existing data types, identities, and groupings in the YANG modules and fixes few bugs in [RFC8776].¶
The following new identities have been added to the 'ietf-te-types' module:¶
lsp-provisioning-error-reason;¶
association-type-diversity;¶
tunnel-admin-state-auto;¶
lsp-restoration-restore-none;¶
restoration-scheme-rerouting;¶
path-metric-optimization-type;¶
link-path-metric-type;¶
link-metric-type and its derived identities;¶
path-computation-error-reason and its derived identities;¶
protocol-origin-type and its derived identities;¶
svec-objective-function-type and its derived identities;¶
svec-metric-type and its derived identities.¶
The following new data types have been added to the 'ietf-te-types' module:¶
The following new groupings have been added to the 'ietf-te-types' module:¶
The following new identities have been added to the 'ietf-te-packet-types' module:¶
bandwidth-profile-type;¶
link-metric-delay-variation;¶
link-metric-loss;¶
path-metric-delay-variation;¶
path-metric-loss.¶
The following new groupings have been added to the 'ietf-te-packet-types' module:¶
The following identities, already defined in [RFC8776], have been updated in the 'ietf-te-types' module:¶
objective-function-type (editorial);¶
action-exercise (bug fix);¶
path-metric-type:¶
new base identities have been added;¶
path-metric-te (bug fix);¶
path-metric-igp (bug fix);¶
path-metric-hop (bug fix);¶
path-metric-delay-average (bug fix);¶
path-metric-delay-minimum (bug fix);¶
path-metric-residual-bandwidth (bug fix);¶
path-metric-optimize-includes (bug fix);¶
path-metric-optimize-excludes (bug fix);¶
te-optimization-criterion (editorial).¶
The following data type, already defined in [RFC8776], has been updated in the 'ietf-te-types' module:¶
The following groupings, already defined in [RFC8776], have been updated in the 'ietf-te-types' module:¶
explicit-route-hop¶
The following new leaves have been added to the 'explicit-route-hop' grouping:¶
The following leaves, already defined in [RFC8776], have been updated in the 'explicit-route-hop':¶
explicit-route-hop¶
The following new leaves have been added to the 'explicit-route-hop' grouping:¶
The following leaves, already defined in [RFC8776], have been updated in the 'explicit-route-hop':¶
optimization-metric-entry:¶
The following leaves, already defined in [RFC8776], have been updated in the 'optimization-metric-entry':¶
tunnel-constraints;¶
The following new leaf have been added to the 'tunnel-constraints' grouping:¶
network-id;¶
path-constraints-route-objects:¶
The following container, already defined in [RFC8776], has been updated in the 'path-constraints-route-objects':¶
generic-path-metric-bounds:¶
The following leaves, already defined in [RFC8776], have been updated in the 'optimization-metric-entry':¶
generic-path-optimization¶
The following new leaf have been added to the 'generic-path-optimization' grouping:¶
tiebreaker;¶
The following container, already defined in [RFC8776], has been deprecated:¶
tiebreakers.¶
The following identities, already defined in [RFC8776], have been obsoletes in the 'ietf-te-types' module for bug fixing:¶
of-minimize-agg-bandwidth-consumption;¶
of-minimize-load-most-loaded-link;¶
of-minimize-cost-path-set;¶
lsp-protection-reroute-extra;¶
lsp-protection-reroute.¶
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 < <mailto:tsaad@juniper.net> --- > <mailto:tsaad.net@gmail.com> 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.";¶
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 < "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 < <mailto:tsaad@juniper.net> --- > <mailto:tsaad.net@gmail.com> 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.";¶
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.¶
The authors would like to thank Robert Wilton, Lou Berger, Mahesh Jethanandani and Jeff Haas for their valuable input to the discussion about the process to follow to provide tiny updates to a YANG module already published as an RFC.¶
The authors would like to thank Mohamed Boucadair and Sergio Belotti for their valuable comments and suggestions on this document.¶
This document was prepared using kramdown.¶