Common YANG Data Types for Traffic Engineering
draft-ietf-teas-rfc8776-update-22
| Document | Type | Active Internet-Draft (teas WG) | |
|---|---|---|---|
| Authors | Italo Busi , Aihua Guo , Xufeng Liu , Tarek Saad , Igor Bryskin | ||
| Last updated | 2026-02-18 | ||
| Replaces | draft-busi-teas-te-types-update | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Yang Validation | 0 errors, 0 warnings | ||
| Reviews |
TSVART IETF Last Call review
(of
-19)
by David Black
Ready w/nits
YANGDOCTORS Early review
(of
-14)
by Joe Clarke
On the right track
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Oscar Gonzalez de Dios | ||
| Shepherd write-up | Show Last changed 2025-11-04 | ||
| IESG | IESG state | IESG Evaluation::AD Followup | |
| Action Holder |
Jim Guichard
65
|
||
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass. |
||
| Responsible AD | Jim Guichard | ||
| Send notices to | lberger@labn.net, oscar.gonzalezdedios@telefonica.com | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-teas-rfc8776-update-22
TEAS Working Group I. Busi
Internet-Draft Huawei
Obsoletes: 8776 (if approved) A. Guo
Intended status: Standards Track Futurewei Technologies
Expires: 22 August 2026 X. Liu
Alef Edge
T. Saad
Cisco Systems Inc.
I. Bryskin
Individual
18 February 2026
Common YANG Data Types for Traffic Engineering
draft-ietf-teas-rfc8776-update-22
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 August 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Busi, et al. Expires 22 August 2026 [Page 1]
Internet-Draft TE Common YANG Types February 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Editorial Note (To be removed by Editors of this document
before sending it to the RFC Editor) . . . . . . . . . . 3
1.2. Editorial Note (To be removed by the RFC Editor) . . . . 3
1.2.1. References to RFCs . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
1.5. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. TE Types Module Contents . . . . . . . . . . . . . . . . 6
3.1.1. Identities . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Data Types . . . . . . . . . . . . . . . . . . . . . 9
3.1.3. Groupings . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Packet TE Types Module Contents . . . . . . . . . . . . . 11
3.2.1. Identities . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Data Types . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Groupings . . . . . . . . . . . . . . . . . . . . . . 12
4. TE Types YANG Module . . . . . . . . . . . . . . . . . . . . 12
5. Packet TE Types YANG Module . . . . . . . . . . . . . . . . . 107
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125
7. Security Considerations . . . . . . . . . . . . . . . . . . . 126
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.1. Normative References . . . . . . . . . . . . . . . . . . 126
8.2. Informative References . . . . . . . . . . . . . . . . . 135
Appendix A. The Complete Schema Trees . . . . . . . . . . . . . 138
A.1. TE Types Schema Tree . . . . . . . . . . . . . . . . . . 138
A.2. Packet TE Types Schema Tree . . . . . . . . . . . . . . . 153
Appendix B. Changes from RFC 8776 . . . . . . . . . . . . . . . 156
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 161
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162
Busi, et al. Expires 22 August 2026 [Page 2]
Internet-Draft TE Common YANG Types February 2026
1. Introduction
YANG [RFC6020] [RFC7950] is a data modeling language used to model
configuration data, state data, Remote Procedure Calls, and
notifications for network management protocols such as the Network
Configuration Protocol (NETCONF) [RFC6241] 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 models defined outside of this document. Nevertheless, these
common definitions can be used by any other module per the guidance
in Sections 4.12 and 4.13 of [I-D.ietf-netmod-rfc8407bis].
Note: Some groupings defined in this document do not follow the
guidelines of Section 4.13 of [I-D.ietf-netmod-rfc8407bis] not to
include "default" statements. This is due to the fact that they
were already defined in [RFC8776] and removing "default"
statements is not a backward compatible change, as defined in
Section 11 of [RFC7950].
This document adds new common data types, identities, and groupings
to both the "ietf-te-types" and the "ietf-te-packet-types" YANG
modules and obsoletes [RFC8776]. For further details, refer to
Appendix B.
1.1. Editorial Note (To be removed by Editors of this document before
sending it to the RFC Editor)
Note to the RFC Editor: This section is to be removed this
document is sent to the RFC Editor.
The YANG trees in Appendix A have been generated by pyang and have
some bugs to be fixed before publication. Please manually fix the
YANG tree before sending the document to the RFC Editor.
1.2. Editorial Note (To be removed by the RFC Editor)
Note to the RFC Editor: This section is to be removed prior to
publication.
This document contains placeholder values that need to be replaced
with finalized values at the time of publication. This note
summarizes all of the substitutions that are needed.
Busi, et al. Expires 22 August 2026 [Page 3]
Internet-Draft TE Common YANG Types February 2026
Please apply the following replacements:
* XXXX --> the assigned RFC number for this I-D
* draft-ietf-pce-sid-algo-29, Sections 4.5.1 and 4.5.2 --> the draft
version and section number as in the latest version of
[I-D.ietf-pce-sid-algo] at the time this document is published as
an RFC
* 2026-01-15 --> the actual date of the publication of this document
* 2026-02-06 --> the actual date of the publication of this document
1.2.1. References to RFCs
This document references a huge number of RFCs only by the RFC number
which makes it really hard to follow.
A preference has been expressed to replace the references with the
RFC title in the text and just use RFC number as a reference.
For example:
In section 1 change:
Section 4.12 of [I-D.ietf-netmod-rfc8407bis] and Section 4.13 of
[I-D.ietf-netmod-rfc8407bis].
to
Section 4.12 and Section 4.13 of YANG Data Models guidelines
document [I-D.ietf-netmod-rfc8407bis].
It is suggested that the RFC Editor and the tooling team identify a
way to expand the references as proposed in a programmatic way.
1.3. Terminology
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].
Busi, et al. Expires 22 August 2026 [Page 4]
Internet-Draft TE Common YANG Types February 2026
1.4. Prefixes in Data Node Names
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 [RFC9911] |
+-----------------+----------------------+------------------------+
| inet | ietf-inet-types | Section 4 of [RFC9911] |
+-----------------+----------------------+------------------------+
| rt-types | ietf-routing-types | [RFC8294] |
+-----------------+----------------------+------------------------+
| te-types | ietf-te-types | RFC XXXX |
+-----------------+----------------------+------------------------+
| te-packet-types | ietf-te-packet-types | RFC XXXX |
+-----------------+----------------------+------------------------+
Table 1: Prefixes and corresponding YANG modules
1.5. Tree Diagrams
Tree diagrams used in this document follow the notation defined in
[RFC8340].
2. Acronyms and Abbreviations
APS: Automatic Protection Switching [RFC7271]
GMPLS: Generalized Multiprotocol Label Switching [RFC3945]
LER: Label Edge Router [RFC5921]
LSP: Label Switched Path [RFC3031]
Note: in this document, "LSP" refers to a TE LSP or a TE path.
LSR: Label Switching Router [RFC3031]
MPLS: Multiprotocol Label Switching [RFC3031]
NBMA: Non-Broadcast Multi-Access [RFC2328]
PM: Performance Metrics [RFC2330]
RSVP: Resource Reservation Protocol [RFC2205]
Busi, et al. Expires 22 August 2026 [Page 5]
Internet-Draft TE Common YANG Types February 2026
SRLG: Shared Risk Link Group [RFC4203]
TE: Traffic Engineering [RFC9522]
WTR: Wait-to-Restore [RFC6378]
3. Overview
This document defines two YANG modules for common TE types: "ietf-te-
types" (Section 4) for TE generic types and "ietf-te-packet-types"
(Section 5) for packet-specific types. Other technology-specific TE
types are outside the scope of this document.
3.1. TE Types Module Contents
The "ietf-te-types" module (Section 4) contains TE types that are
commonly used across multiple TE technology-specific modules.
3.1.1. Identities
The "ietf-te-types" module contains the following YANG reusable
identities:
path-attribute-flags: A base identity for supported LSP path flags
as defined in [RFC3209], [RFC4090], [RFC4736], [RFC5712],
[RFC4920], [RFC5420], [RFC7570], [RFC4875], [RFC5151], [RFC5150],
[RFC6001], [RFC6790], [RFC7260], [RFC8001], [RFC8149], and
[RFC8169].
link-protection-type: A base identity for supported link protection
types as defined in [RFC4872].
restoration-scheme-type: A base identity for supported LSP
restoration schemes as defined in [RFC4872].
protection-external-commands: A base identity for supported
protection-related external commands used for troubleshooting
purposes, as defined in [RFC4872], [RFC6368], [RFC7271], and
[RFC4427].
association-type: A base identity for supported LSP association
types as defined in [RFC6780], [RFC4872], [RFC4873], and
[RFC8800].
objective-function-type: A base identity for supported path
objective functions as defined in [RFC5541].
te-tunnel-type: A base identity for supported TE tunnel types as
Busi, et al. Expires 22 August 2026 [Page 6]
Internet-Draft TE Common YANG Types February 2026
defined in [RFC3209] and [RFC4875].
lsp-encoding-types: A base identity for supported LSP encoding types
as defined in [RFC3471], [RFC4328], and [RFC6004]. These defined
identities includes also technology-specific LSP encoding types
for backward compatibility with [RFC8776].
Additional technology-specific LSP encoding types can be defined
in specific technology-specific modules.
lsp-protection-type: A base identity for supported LSP protection
types as defined in [RFC4872] and [RFC4873].
switching-capabilities: A base identity for supported interface
switching capabilities as defined in [RFC3471], [RFC6002],
[RFC6004], [RFC7074], and [RFC7138]. These defined identities
includes also technology-specific interface switching capabilities
for backward compatibility with [RFC8776].
Additional technology-specific interface switching capabilities
can be defined in specific technology-specific modules.
resource-affinities-type: A base identity for supported attribute
filters associated with a tunnel that must be satisfied for a link
to be acceptable as defined in [RFC3209] and [RFC2702].
path-metric-type: A base 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 MUST describe the
unit and maximum value of the path metric types they define.
For example, the measurement unit is not applicable for the number
of hops metric ('path-metric-hop'). Conversely, 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].
lsp-provisioning-error-reason: A base identity for indicating LSP
provisioning error reasons. No standard LSP provisioning error
reasons are defined in this document.
path-computation-error-reason: A base identity for indicating path
computation error reasons as defined in Section 3.1.1.1.
protocol-origin-type: A base identity for the type of protocol
Busi, et al. Expires 22 August 2026 [Page 7]
Internet-Draft TE Common YANG Types February 2026
origin as defined in Section 3.1.1.2.
svec-objective-function-type: A base identity for supported SVEC
objective functions as defined in [RFC5541] and [RFC8685].
svec-metric-type: A base identity for supported SVEC metric types as
defined in [RFC5541].
3.1.1.1. Path Computation Errors
The "ietf-te-types" module contains the YANG reusable identities for
indicating path computation error reasons as defined in [RFC5440],
[RFC5441], [RFC5520], [RFC5557], [RFC8306], and [RFC8685].
It also defines the following additional YANG reusable identities for
indicating the following path computation error reasons:
path-computation-error-no-topology: A base identity for indicating
path computation error when there is no topology with the provided
topology identifier.
path-computation-error-no-dependent-server: A base identity for
indicating 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, as defined in
[RFC5441], or a child PCE, as defined in [RFC8685].
The derived identities are defined in the "ietf-te-types" module,
instead of an IANA-maintained module, because there are error reasons
which are:
1. applicable only to the TE YANG modules and not to PCEP
environments (e.g., path-computation-error-no-topology);
2. technology-specific which are better defined in technology-
specific YANG modules;
3. match more than one PCEP number in order to hide the details of
the underlay PCE architecture (e.g., path-computation-error-no-
dependent-server).
Busi, et al. Expires 22 August 2026 [Page 8]
Internet-Draft TE Common YANG Types February 2026
3.1.1.2. Protocol Origin
The protocol origin identifies the protocol or mechanism a controller
uses to instantiate a TE tunnel. To model this, the "ietf-te-types"
module provides a set of reusable YANG identities. In addition to
identities for protocols like PCEP [RFC5440] and BGP [RFC9012], the
module defines the following identity for tunnels created via an
Application Programmable Interface (API):
protocol-origin-api: A YANG identity used when the TE tunnel is
instantiated through an API.
3.1.2. Data Types
The "ietf-te-types" module contains the following YANG reusable data
types:
te-ds-class: A type representing the Differentiated Services (DS)
Class-Type of traffic as defined in [RFC4124].
te-label-direction: An enumerated type for specifying the forward or
reverse direction of a label.
te-hop-type: An enumerated type for specifying that a hop is loose
or strict.
te-global-id: A type representing the identifier that uniquely
identifies an operator, which can be either a provider or a
client. The definition of this type is taken from Section 3 of
[RFC6370] and Section 3 of [RFC5003]. This attribute type is used
solely to provide a globally unique context for TE topologies.
te-node-id: A type representing the identifier for a node in a TE
topology. The identifier is represented either as 4-octet in
dotted-quad notation or as 16-octet in an [RFC5952] 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].
te-topology-id: A type representing the identifier for a topology.
Busi, et al. Expires 22 August 2026 [Page 9]
Internet-Draft TE Common YANG Types February 2026
It is optional to have one or more prefixes at the beginning,
separated by colons. The prefixes can be "network-types" as
defined in the "ietf-network" module in [RFC8345], to help the
user better understand the topology before further inquiry is
made.
te-tp-id: A type representing the identifier of a TE interface Link
Termination Point (LTP) on a specific TE node where the TE link
connects. This attribute is mapped to a local or remote link
identifier [RFC3630] [RFC5305].
te-path-disjointness: A type representing the different resource
disjointness options for a TE tunnel path as defined in [RFC4872].
admin-groups: A union type for a TE link's classic administrative
groups, as defined in [RFC3630] and [RFC5305], or extended
administrative groups, as defined in [RFC7308].
srlg: A type representing the Shared Risk Link Group (SRLG) as
defined in [RFC4203] and [RFC5307].
te-metric: A type representing the TE metric as defined in
[RFC3785].
te-recovery-status: An enumerated type for the different status of a
recovery action as defined in [RFC6378] and [RFC4427].
te-link-access-type: An enumerated type for the different TE link
access types as defined in [RFC3630].
3.1.3. Groupings
The "ietf-te-types" module contains the following YANG reusable
groupings:
te-bandwidth: A grouping that defines the generic TE bandwidth. The
modeling structure allows augmentation for each technology. For
unspecified technologies, the string-encoded "te-bandwidth" type
is used.
te-label: A grouping that defines the generic TE label. The
modeling structure allows augmentation for each technology. For
unspecified technologies, "rt-types:generalized-label" is used.
performance-metrics-attributes: A grouping that defines one-way and
two-way measured Performance Metrics (PM) and indications of
anomalies on links or the path as defined in [RFC7471], [RFC8570],
[RFC7823], [RFC7679] and [RFC2681].
Busi, et al. Expires 22 August 2026 [Page 10]
Internet-Draft TE Common YANG Types February 2026
performance-metrics-throttle-container: A grouping that defines
thresholds for advertisement suppression and measurement
intervals.
explicit-route-hop: A grouping that defines supported explicit
routes as defined in [RFC3209] and [RFC3477].
explicit-route-hop-with-srlg: A grouping that augments the
'explicit-route-hop' to specify also SRLG hops.
encoding-and-switching-type: A grouping that defines the LSP
encoding and switching types.
3.2. Packet TE Types Module Contents
The "ietf-te-packet-types" module (Section 5) covers the common types
and groupings that are specific to packet technology.
3.2.1. Identities
The "ietf-te-packet-types" module contains the following YANG
reusable identities:
backup-protection-type: A base identity for supported protection
types that a backup or bypass tunnel can provide as defined in
[RFC4090].
bc-model-type: A base identity for supported Diffserv-TE Bandwidth
Constraints Models as defined in [RFC4125], [RFC4126], and
[RFC4127].
bandwidth-profile-type: A base identity for various bandwidth
profiles, also known as traffic profiles in Section 2.3.2 of
[RFC2475], that may be used to specify the temporal properties of
a packet stream (e.g., MPLS-TE LSPs), e.g., as specified in
[MEF_10.3], [RFC2697] and [RFC2698].
3.2.2. Data Types
The "ietf-te-packet-types" module contains the following YANG
reusable data type:
te-bandwidth-requested-type: An enumerated type for the different
options to request bandwidth for a specific tunnel.
Busi, et al. Expires 22 August 2026 [Page 11]
Internet-Draft TE Common YANG Types February 2026
3.2.3. Groupings
The "ietf-te-packet-types" module contains the following YANG
reusable groupings:
performance-metrics-attributes-packet: A grouping that contains the
generic performance metrics and additional packet-specific
metrics.
bandwidth-profile-parameters: A grouping that defines common
parameters for bandwidth profiles in packet networks.
te-packet-path-bandwidth: A 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.
te-packet-link-bandwidth: A grouping that defines the link bandwidth
information and could be used in any Packet TE model (e.g., MPLS-
TE topology) for link bandwidth representation.
All the link bandwidth related sections in the "ietf-te-types"
generic module, Section 4, need to be augmented with this grouping
for the usage of Packet TE technologies.
4. TE Types YANG Module
The "ietf-te-types" module imports the following modules:
* "ietf-yang-types" and "ietf-inet-types" as defined in [RFC9911]
* "ietf-routing-types" as defined in [RFC8294]
* "ietf-network" and "ietf-network-topology" as defined in [RFC8345]
In addition to [RFC9911] and [RFC8294], this module references the
following documents in defining the types and YANG groupings:
[RFC9522], [RFC4090], [RFC4202], [RFC4328], [RFC4561], [RFC4657],
[RFC4736], [RFC6004], [RFC6378], [RFC6511], [RFC7139], [RFC7271],
[RFC7308], [RFC7551], [RFC7571], [RFC7579], and [ISOIEC_9899].
Busi, et al. Expires 22 August 2026 [Page 12]
Internet-Draft TE Common YANG Types February 2026
<CODE BEGINS> file "ietf-te-types@2026-02-06.yang"
module ietf-te-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-types";
prefix te-types;
import ietf-inet-types {
prefix inet;
reference
"RFC 9911: Common YANG Data Types, Section 4";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 9911: Common YANG Data Types, Section 3";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Tarek Saad
<mailto:tsaad.net@gmail.com>
Editor: Rakesh Gandhi
<mailto:rgandhi@cisco.com>
Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>
Busi, et al. Expires 22 August 2026 [Page 13]
Internet-Draft TE Common YANG Types February 2026
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>
Editor: Igor Bryskin
<mailto:i_bryskin@yahoo.com>";
description
"This YANG module contains a collection of generally useful
YANG data type definitions specific to TE.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2026-02-06 {
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.
Busi, et al. Expires 22 August 2026 [Page 14]
Internet-Draft TE Common YANG Types February 2026
This revision adds the following new data types:
- path-type.
This revision adds the following new groupings:
- explicit-route-hop-with-srlg;
- 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:
Busi, et al. Expires 22 August 2026 [Page 15]
Internet-Draft TE Common YANG Types February 2026
- 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";
}
revision 2020-06-10 {
description
"Initial Version of TE types.";
reference
"RFC 8776: Common YANG Data Types for Traffic Engineering";
}
/*
* Features
*/
feature p2mp-te {
description
"Indicates support for Point-to-Multipoint TE (P2MP-TE).";
reference
"RFC 4875: Extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for
Point-to-Multipoint TE Label Switched Paths (LSPs)";
}
feature frr-te {
description
"Indicates support for TE Fast Reroute (FRR).";
reference
"RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels";
}
Busi, et al. Expires 22 August 2026 [Page 16]
Internet-Draft TE Common YANG Types February 2026
feature extended-admin-groups {
description
"Indicates support for TE link extended administrative
groups.";
reference
"RFC 7308: Extended Administrative Groups in MPLS Traffic
Engineering (MPLS-TE)";
}
feature named-path-affinities {
description
"Indicates support for named path affinities.";
}
feature named-extended-admin-groups {
description
"Indicates support for named extended administrative groups.";
}
feature named-srlg-groups {
description
"Indicates support for named Shared Risk Link Group (SRLG).";
}
feature named-path-constraints {
description
"Indicates support for named path constraints.";
}
feature path-optimization-metric {
description
"Indicates support for path optimization metrics.";
}
feature path-optimization-objective-function {
description
"Indicates support for path optimization objective functions.";
}
/*
* Identities
*/
identity lsp-provisioning-error-reason {
description
"Base identity for LSP provisioning errors.";
}
Busi, et al. Expires 22 August 2026 [Page 17]
Internet-Draft TE Common YANG Types February 2026
identity session-attributes-flags {
description
"Base identity for the RSVP-TE session attributes flags.";
}
identity local-protection-desired {
base session-attributes-flags;
description
"Local protection is desired.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 4.7.1";
}
identity se-style-desired {
base session-attributes-flags;
description
"Shared explicit style, to allow the LSP to be established
and share resources with the old LSP.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
}
identity local-recording-desired {
base session-attributes-flags;
description
"Label recording is desired.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 4.7.1";
}
identity bandwidth-protection-desired {
base session-attributes-flags;
description
"Requests FRR bandwidth protection on LSRs, if present.";
reference
"RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
Tunnels";
}
identity node-protection-desired {
base session-attributes-flags;
description
"Requests FRR node protection on LSRs, if present.";
reference
"RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
Tunnels";
Busi, et al. Expires 22 August 2026 [Page 18]
Internet-Draft TE Common YANG Types February 2026
}
identity path-reevaluation-request {
base session-attributes-flags;
description
"Indicates that a path re-evaluation (of the
current path in use) is requested.
Note that this does not trigger any LSP reroutes but
instead just signals a request to evaluate whether a
preferable path exists.";
reference
"RFC 4736: Reoptimization of Multiprotocol Label Switching
(MPLS) Traffic Engineering (TE) Loosely Routed
Label Switched Path (LSP)";
}
identity soft-preemption-desired {
base session-attributes-flags;
description
"Soft preemption of LSP resources is desired.";
reference
"RFC 5712: MPLS Traffic Engineering Soft Preemption";
}
identity lsp-attributes-flags {
description
"Base identity for LSP attributes flags.";
}
identity end-to-end-rerouting-desired {
base lsp-attributes-flags;
description
"Indicates end-to-end rerouting behavior for an LSP
undergoing establishment.
This MAY also be used to specify the behavior of end-to-end
LSP recovery for established LSPs.";
reference
"RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
RSVP-TE
RFC 5420: Encoding of Attributes for MPLS LSP Establishment
Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
Busi, et al. Expires 22 August 2026 [Page 19]
Internet-Draft TE Common YANG Types February 2026
identity boundary-rerouting-desired {
base lsp-attributes-flags;
description
"Indicates boundary rerouting behavior for an LSP undergoing
establishment.
This MAY also be used to specify segment-based LSP recovery
through nested crankback for established LSPs.
The boundary Area Border Router (ABR) / Autonomous System
Border Router (ASBR) can decide to forward the PathErr
message upstream to either an upstream boundary ABR/ASBR or
the ingress LSR.
Alternatively, it can try to select another egress boundary
LSR.";
reference
"RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
RSVP-TE
RFC 5420: Encoding of Attributes for MPLS LSP Establishment
Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity segment-based-rerouting-desired {
base lsp-attributes-flags;
description
"Indicates segment-based rerouting behavior for an LSP
undergoing establishment.
This MAY also be used to specify segment-based LSP recovery
for established LSPs.";
reference
"RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
RSVP-TE
RFC 5420: Encoding of Attributes for MPLS LSP Establishment
Using Resource Reservation Protocol
Traffic Engineering (RSVP-TE)
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity lsp-integrity-required {
base lsp-attributes-flags;
description
"Indicates that LSP integrity is required.";
Busi, et al. Expires 22 August 2026 [Page 20]
Internet-Draft TE Common YANG Types February 2026
reference
"RFC 4875: Extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for
Point-to-Multipoint TE Label Switched Paths (LSPs)
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity contiguous-lsp-desired {
base lsp-attributes-flags;
description
"Indicates that a contiguous LSP is desired.";
reference
"RFC 5151: Inter-Domain MPLS and GMPLS Traffic Engineering --
Resource Reservation Protocol-Traffic Engineering
(RSVP-TE) Extensions
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity lsp-stitching-desired {
base lsp-attributes-flags;
description
"Indicates that LSP stitching is desired.";
reference
"RFC 5150: Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering
(GMPLS TE)
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity pre-planned-lsp-flag {
base lsp-attributes-flags;
description
"Indicates that the LSP MUST be provisioned in the
control plane only.";
reference
"RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for
Multi-Layer and Multi-Region Networks (MLN/MRN)
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity non-php-behavior-flag {
base lsp-attributes-flags;
description
"Indicates that non-PHP (non-Penultimate Hop Popping)
Busi, et al. Expires 22 August 2026 [Page 21]
Internet-Draft TE Common YANG Types February 2026
behavior for the LSP is desired.";
reference
"RFC 6511: Non-Penultimate Hop Popping Behavior and
Out-of-Band Mapping for RSVP-TE Label Switched
Paths
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity oob-mapping-flag {
base lsp-attributes-flags;
description
"Indicates that signaling of the egress binding information
is out of band (e.g., via the Border Gateway Protocol
(BGP)).";
reference
"RFC 6511: Non-Penultimate Hop Popping Behavior and
Out-of-Band Mapping for RSVP-TE Label Switched
Paths
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity entropy-label-capability {
base lsp-attributes-flags;
description
"Indicates entropy label capability.";
reference
"RFC 6790: The Use of Entropy Labels in MPLS Forwarding
RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)";
}
identity oam-mep-entity-desired {
base lsp-attributes-flags;
description
"OAM Maintenance Entity Group End Point (MEP) entities
desired.";
reference
"RFC 7260: GMPLS RSVP-TE Extensions for Operations,
Administration, and Maintenance (OAM)
Configuration";
}
identity oam-mip-entity-desired {
base lsp-attributes-flags;
description
"OAM Maintenance Entity Group Intermediate Points (MIP)
Busi, et al. Expires 22 August 2026 [Page 22]
Internet-Draft TE Common YANG Types February 2026
entities desired.";
reference
"RFC 7260: GMPLS RSVP-TE Extensions for Operations,
Administration, and Maintenance (OAM)
Configuration";
}
identity srlg-collection-desired {
base lsp-attributes-flags;
description
"Shared Risk Link Group (SRLG) collection desired.";
reference
"RFC 7570: Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)
RFC 8001: RSVP-TE Extensions for Collecting Shared Risk
Link Group (SRLG) Information";
}
identity loopback-desired {
base lsp-attributes-flags;
description
"Indicates that a particular node on the LSP is
required to enter loopback mode.
This can also be used to specify the loopback state of the
node.";
reference
"RFC 7571: GMPLS RSVP-TE Extensions for Lock Instruct and
Loopback";
}
identity p2mp-te-tree-eval-request {
base lsp-attributes-flags;
description
"P2MP-TE tree re-evaluation request.";
reference
"RFC 8149: RSVP Extensions for Reoptimization of Loosely
Routed Point-to-Multipoint Traffic Engineering
Label Switched Paths (LSPs)";
}
identity rtm-set-desired {
base lsp-attributes-flags;
description
"Residence Time Measurement (RTM) attribute flag requested.";
reference
"RFC 8169: Residence Time Measurement in MPLS Networks";
}
Busi, et al. Expires 22 August 2026 [Page 23]
Internet-Draft TE Common YANG Types February 2026
identity link-protection-type {
description
"Base identity for the link protection type.";
reference
"RFC 4202: Routing Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS),
section 2.2
RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, section 7";
}
identity link-protection-unprotected {
base link-protection-type;
description
"'Unprotected' link protection type.";
reference
"RFC 4202: Routing Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS),
section 2.2
RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, section 7";
}
identity link-protection-extra-traffic {
base link-protection-type;
description
"'Extra-Traffic' link protection type.";
reference
"RFC 4202: Routing Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS),
section 2.2
RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, section 7";
}
identity link-protection-shared {
base link-protection-type;
description
"'Shared' link protection type.";
reference
"RFC 4202: Routing Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS),
section 2.2
RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, section 7";
}
identity link-protection-1-for-1 {
Busi, et al. Expires 22 August 2026 [Page 24]
Internet-Draft TE Common YANG Types February 2026
base link-protection-type;
description
"'Dedicated 1:1' link protection type.";
reference
"RFC 4202: Routing Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS),
section 2.2
RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, section 7";
}
identity link-protection-1-plus-1 {
base link-protection-type;
description
"'Dedicated 1+1' link protection type.";
reference
"RFC 4202: Routing Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS),
section 2.2
RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, section 7";
}
identity link-protection-enhanced {
base link-protection-type;
description
"'Enhanced' link protection type.";
reference
"RFC 4202: Routing Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS),
section 2.2
RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, section 7";
}
identity association-type {
description
"Base identity for the tunnel association.";
}
identity association-type-recovery {
base association-type;
description
"Association type for recovery, used to associate LSPs of the
same tunnel for recovery.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Busi, et al. Expires 22 August 2026 [Page 25]
Internet-Draft TE Common YANG Types February 2026
Recovery
RFC 6780: RSVP ASSOCIATION Object Extensions";
}
identity association-type-resource-sharing {
base association-type;
description
"Association type for resource sharing, used to enable
resource sharing during make-before-break.";
reference
"RFC 4873: GMPLS Segment Recovery
RFC 6780: RSVP ASSOCIATION Object Extensions";
}
identity association-type-double-sided-bidir {
base association-type;
description
"Association type for double-sided bidirectional LSPs,
used to associate two LSPs of two tunnels that are
independently configured on either endpoint.";
reference
"RFC 7551: RSVP-TE Extensions for Associated Bidirectional
Label Switched Paths (LSPs)";
}
identity association-type-single-sided-bidir {
base association-type;
description
"Association type for single-sided bidirectional LSPs,
used to associate two LSPs of two tunnels, where one
tunnel is configured on one side/endpoint and the other
tunnel is dynamically created on the other endpoint.";
reference
"RFC 6780: RSVP ASSOCIATION Object Extensions
RFC 7551: RSVP-TE Extensions for Associated Bidirectional
Label Switched Paths (LSPs)";
}
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";
}
Busi, et al. Expires 22 August 2026 [Page 26]
Internet-Draft TE Common YANG Types February 2026
identity objective-function-type {
description
"Base identity for path objective function types.";
}
identity of-minimize-cost-path {
base objective-function-type;
description
"Objective function for minimizing path cost.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity of-minimize-load-path {
base objective-function-type;
description
"Objective function for minimizing the load on one or more
paths.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity of-maximize-residual-bandwidth {
base objective-function-type;
description
"Objective function for maximizing residual bandwidth.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity of-minimize-agg-bandwidth-consumption {
base objective-function-type;
status obsolete;
description
"Objective function for minimizing aggregate bandwidth
consumption.
This identity has been obsoleted: the
'svec-of-minimize-agg-bandwidth-consumption' identity SHOULD
be used instead.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Busi, et al. Expires 22 August 2026 [Page 27]
Internet-Draft TE Common YANG Types February 2026
Computation Element Communication Protocol
(PCEP)";
}
identity of-minimize-load-most-loaded-link {
base objective-function-type;
status obsolete;
description
"Objective function for minimizing the load on the link that
is carrying the highest load.
This identity has been obsoleted: the
'svec-of-minimize-load-most-loaded-link' identity SHOULD
be used instead.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity of-minimize-cost-path-set {
base objective-function-type;
status obsolete;
description
"Objective function for minimizing the cost on a path set.
This identity has been obsoleted: the
'svec-of-minimize-cost-path-set' identity SHOULD
be used instead.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity path-computation-method {
description
"Base identity for supported path computation mechanisms.";
}
identity path-locally-computed {
base path-computation-method;
description
"Indicates a constrained-path LSP in which the
path is computed by the local LER.";
reference
"RFC 9522: Overview and Principles of Internet Traffic
Engineering, Section 4.4";
Busi, et al. Expires 22 August 2026 [Page 28]
Internet-Draft TE Common YANG Types February 2026
}
identity path-externally-queried {
base path-computation-method;
description
"Constrained-path LSP in which the path is obtained by
querying an external source, such as a PCE server.
In the case that an LSP is defined to be externally queried,
it may also have associated explicit definitions (provided
to the external source to aid computation).
The path that is returned by the external source may
require further local computation on the device.";
reference
"RFC 9522: Overview and Principles of Internet Traffic
Engineering
RFC 4657: Path Computation Element (PCE) Communication
Protocol Generic Requirements";
}
identity path-explicitly-defined {
base path-computation-method;
description
"Constrained-path LSP in which the path is
explicitly specified as a collection of strict and/or loose
hops.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 9522: Overview and Principles of Internet Traffic
Engineering";
}
identity lsp-metric-type {
description
"Base identity for the LSP metric specification types.";
}
identity lsp-metric-relative {
base lsp-metric-type;
description
"The metric specified for the LSPs to which this identity
refers is specified as a value relative to the IGP metric
cost to the LSP's tail end.";
reference
"RFC 4657: Path Computation Element (PCE) Communication
Protocol Generic Requirements";
}
Busi, et al. Expires 22 August 2026 [Page 29]
Internet-Draft TE Common YANG Types February 2026
identity lsp-metric-absolute {
base lsp-metric-type;
description
"The metric specified for the LSPs to which this identity
refers is specified as an absolute value.";
reference
"RFC 4657: Path Computation Element (PCE) Communication
Protocol Generic Requirements";
}
identity lsp-metric-inherited {
base lsp-metric-type;
description
"The metric for the LSPs to which this identity refers is
not specified explicitly; rather, it is directly inherited
from the IGP cost.";
reference
"RFC 4657: Path Computation Element (PCE) Communication
Protocol Generic Requirements";
}
identity te-tunnel-type {
description
"Base identity from which specific tunnel types are derived.";
}
identity te-tunnel-p2p {
base te-tunnel-type;
description
"TE Point-to-Point (P2P) tunnel type.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
}
identity te-tunnel-p2mp {
base te-tunnel-type;
description
"TE P2MP tunnel type.";
reference
"RFC 4875: Extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for
Point-to-Multipoint TE Label Switched Paths
(LSPs)";
}
identity tunnel-action-type {
description
"Base identity from which specific tunnel action types
Busi, et al. Expires 22 August 2026 [Page 30]
Internet-Draft TE Common YANG Types February 2026
are derived.";
}
identity tunnel-action-resetup {
base tunnel-action-type;
description
"TE tunnel action that tears down the tunnel's current LSP
(if any) and attempts to re-establish a new LSP.";
}
identity tunnel-action-reoptimize {
base tunnel-action-type;
description
"TE tunnel action that reoptimizes the placement of the
tunnel LSP(s).";
}
identity tunnel-action-switchpath {
base tunnel-action-type;
description
"TE tunnel action that switches the tunnel's LSP to use the
specified path.";
}
identity te-action-result {
description
"Base identity from which specific TE action results
are derived.";
}
identity te-action-success {
base te-action-result;
description
"TE action was successful.";
}
identity te-action-fail {
base te-action-result;
description
"TE action failed.";
}
identity tunnel-action-inprogress {
base te-action-result;
description
"TE action is in progress.";
}
Busi, et al. Expires 22 August 2026 [Page 31]
Internet-Draft TE Common YANG Types February 2026
identity tunnel-admin-state-type {
description
"Base identity for TE tunnel administrative states.";
}
identity tunnel-admin-state-up {
base tunnel-admin-state-type;
description
"Tunnel's administrative state is up.";
}
identity tunnel-admin-state-down {
base tunnel-admin-state-type;
description
"Tunnel's administrative state is down.";
}
identity tunnel-admin-state-auto {
base tunnel-admin-state-type;
description
"Tunnel administrative auto state. The administrative status
in state datastore transitions to 'tunnel-admin-up' when the
tunnel used by the client layer, and to 'tunnel-admin-down'
when it is not used by the client layer.";
}
identity tunnel-state-type {
description
"Base identity for TE tunnel states.";
}
identity tunnel-state-up {
base tunnel-state-type;
description
"Tunnel's state is up.";
}
identity tunnel-state-down {
base tunnel-state-type;
description
"Tunnel's state is down.";
}
identity lsp-state-type {
description
"Base identity for TE LSP states.";
}
Busi, et al. Expires 22 August 2026 [Page 32]
Internet-Draft TE Common YANG Types February 2026
identity lsp-path-computing {
base lsp-state-type;
description
"State path computation is in progress.";
}
identity lsp-path-computation-ok {
base lsp-state-type;
description
"State path computation was successful.";
}
identity lsp-path-computation-failed {
base lsp-state-type;
description
"State path computation failed.";
}
identity lsp-state-setting-up {
base lsp-state-type;
description
"State is being set up.";
}
identity lsp-state-setup-ok {
base lsp-state-type;
description
"State setup was successful.";
}
identity lsp-state-setup-failed {
base lsp-state-type;
description
"State setup failed.";
}
identity lsp-state-up {
base lsp-state-type;
description
"State is up.";
}
identity lsp-state-tearing-down {
base lsp-state-type;
description
"State is being torn down.";
}
Busi, et al. Expires 22 August 2026 [Page 33]
Internet-Draft TE Common YANG Types February 2026
identity lsp-state-down {
base lsp-state-type;
description
"State is down.";
}
identity path-invalidation-action-type {
description
"Base identity for TE path invalidation action types.";
}
identity path-invalidation-action-drop {
base path-invalidation-action-type;
description
"Upon invalidation of the TE tunnel path, the tunnel remains
valid, but any packet mapped over the tunnel is dropped.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 2.5";
}
identity path-invalidation-action-teardown {
base path-invalidation-action-type;
description
"TE path invalidation action teardown.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 2.5";
}
identity lsp-restoration-type {
description
"Base identity from which LSP restoration types are derived.";
}
identity lsp-restoration-restore-none {
base lsp-restoration-type;
description
"No LSP affected by a failure is restored.";
}
identity lsp-restoration-restore-any {
base lsp-restoration-type;
description
"Any LSP affected by a failure is restored.";
}
identity lsp-restoration-restore-all {
Busi, et al. Expires 22 August 2026 [Page 34]
Internet-Draft TE Common YANG Types February 2026
base lsp-restoration-type;
description
"Affected LSPs are restored after all LSPs of the tunnel are
broken.";
}
identity restoration-scheme-type {
description
"Base identity for LSP restoration schemes.";
}
identity restoration-scheme-rerouting {
base restoration-scheme-type;
description
"Restoration LSP is computed, signalled and configured after
the failure detection.
This restoration scheme is also known as
'Full LSP Re-routing', with the alternate route being
computed after the failure occurs.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 11";
}
identity restoration-scheme-preconfigured {
base restoration-scheme-type;
description
"Restoration LSP is precomputed, presignalled and
preconfigured prior to the failure.";
}
identity restoration-scheme-precomputed {
base restoration-scheme-type;
description
"Restoration LSP is precomputed, but not presignalled nor
preconfigured, prior to the failure.
This restoration scheme is also known as
'Full LSP Re-routing', with the alternate route being
precomputed and stored for use when the failure occurs.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 11";
}
Busi, et al. Expires 22 August 2026 [Page 35]
Internet-Draft TE Common YANG Types February 2026
identity restoration-scheme-presignaled {
base restoration-scheme-type;
description
"Restoration LSP is presignaled, but not preconfigured,
prior to the failure.
This restoration scheme is also known as
'Pre-planned LSP Re-routing'.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 8";
}
identity lsp-protection-type {
description
"Base identity from which LSP protection types are derived.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery";
}
identity lsp-protection-unprotected {
base lsp-protection-type;
description
"'Unprotected' LSP protection type.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery";
}
identity lsp-protection-reroute-extra {
base lsp-protection-type;
status obsolete;
description
"'(Full) Rerouting' LSP protection type.
This identity has been obsoleted: the
'restoration-scheme-rerouting' or
'restoration-scheme-precomputed' identity SHOULD be used
instead.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 11";
}
Busi, et al. Expires 22 August 2026 [Page 36]
Internet-Draft TE Common YANG Types February 2026
identity lsp-protection-reroute {
base lsp-protection-type;
status obsolete;
description
"'Rerouting without Extra-Traffic' LSP protection type.
This identity has been obsoleted: the
'restoration-scheme-presignaled' identity SHOULD be used
instead.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 8";
}
identity lsp-protection-1-for-n {
base lsp-protection-type;
description
"'1:N Protection with Extra-Traffic' LSP protection type.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 7.3";
}
identity lsp-protection-1-for-1 {
base lsp-protection-type;
description
"LSP protection '1:1 Protection Type'.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 7";
}
identity lsp-protection-unidir-1-plus-1 {
base lsp-protection-type;
description
"'1+1 Unidirectional Protection' LSP protection type.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 5";
}
identity lsp-protection-bidir-1-plus-1 {
base lsp-protection-type;
description
Busi, et al. Expires 22 August 2026 [Page 37]
Internet-Draft TE Common YANG Types February 2026
"'1+1 Bidirectional Protection' LSP protection type.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 6";
}
identity lsp-protection-extra-traffic {
base lsp-protection-type;
description
"Extra-Traffic LSP protection type.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery, section 7";
}
identity lsp-protection-state {
description
"Base identity of protection states for reporting purposes.";
}
identity normal {
base lsp-protection-state;
description
"Normal state.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity signal-fail-of-protection {
base lsp-protection-state;
description
"The protection transport entity has a signal fail condition
that is of higher priority than the forced switchover
command.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity lockout-of-protection {
base lsp-protection-state;
Busi, et al. Expires 22 August 2026 [Page 38]
Internet-Draft TE Common YANG Types February 2026
description
"A Loss of Protection (LoP) command is active.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity forced-switch {
base lsp-protection-state;
description
"A forced switchover command is active.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity signal-fail {
base lsp-protection-state;
description
"There is a signal fail condition on either the working path
or the protection path.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity signal-degrade {
base lsp-protection-state;
description
"There is a signal degrade condition on either the working
path or the protection path.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity manual-switch {
base lsp-protection-state;
description
"A manual switchover command is active.";
Busi, et al. Expires 22 August 2026 [Page 39]
Internet-Draft TE Common YANG Types February 2026
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity wait-to-restore {
base lsp-protection-state;
description
"A Wait-to-Restore (WTR) timer is running.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity do-not-revert {
base lsp-protection-state;
description
"A Do Not Revert (DNR) condition is active because of
non-revertive behavior.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity failure-of-protocol {
base lsp-protection-state;
description
"LSP protection is not working because of a protocol failure
condition.";
reference
"RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection
to Match the Operational Expectations of
Synchronous Digital Hierarchy, Optical Transport
Network, and Ethernet Transport Network Operators
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity protection-external-commands {
description
"Base identity from which protection-related external commands
Busi, et al. Expires 22 August 2026 [Page 40]
Internet-Draft TE Common YANG Types February 2026
used for troubleshooting purposes are derived.";
}
identity action-freeze {
base protection-external-commands;
description
"A temporary configuration action initiated by an operator
command that prevents any switchover action from being taken
and, as such, freezes the current state.";
reference
"RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection
to Match the Operational Expectations of
Synchronous Digital Hierarchy, Optical Transport
Network, and Ethernet Transport Network Operators
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity clear-freeze {
base protection-external-commands;
description
"An action that clears the active freeze state.";
reference
"RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection
to Match the Operational Expectations of
Synchronous Digital Hierarchy, Optical Transport
Network, and Ethernet Transport Network Operators
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity action-lockout-of-normal {
base protection-external-commands;
description
"A temporary configuration action initiated by an operator
command to ensure that the normal traffic is not allowed
to use the protection transport entity.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
Busi, et al. Expires 22 August 2026 [Page 41]
Internet-Draft TE Common YANG Types February 2026
identity clear-lockout-of-normal {
base protection-external-commands;
description
"An action that clears the active lockout of the
normal state.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity action-lockout-of-protection {
base protection-external-commands;
description
"A temporary configuration action initiated by an operator
command to ensure that the protection transport entity is
temporarily not available to transport a traffic signal
(either normal or Extra-Traffic).";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity action-forced-switch {
base protection-external-commands;
description
"A switchover action initiated by an operator command to
switch the Extra-Traffic signal, the normal traffic signal,
or the null signal to the protection transport entity,
unless a switchover command of equal or higher priority is
in effect.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity action-manual-switch {
Busi, et al. Expires 22 August 2026 [Page 42]
Internet-Draft TE Common YANG Types February 2026
base protection-external-commands;
description
"A switchover action initiated by an operator command to
switch the Extra-Traffic signal, the normal traffic signal,
or the null signal to the protection transport entity,
unless a fault condition exists on other transport entities
or a switchover command of equal or higher priority is in
effect.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity action-exercise {
base protection-external-commands;
description
"An action that starts testing whether or not Automatic
Protection Switching (APS) communication is operating
correctly.
It is of lower priority than any other state or command.";
reference
"RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection
to Match the Operational Expectations of
Synchronous Digital Hierarchy, Optical Transport
Network, and Ethernet Transport Network Operators
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
identity clear {
base protection-external-commands;
description
"An action that clears the active near-end lockout of a
protection, forced switchover, manual switchover,
Wait-to-Restore (WTR) state, or exercise command.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
Busi, et al. Expires 22 August 2026 [Page 43]
Internet-Draft TE Common YANG Types February 2026
identity switching-capabilities {
description
"Base identity for interface switching capabilities.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity switching-psc1 {
base switching-capabilities;
description
"Packet-Switch Capable-1 (PSC-1).";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity switching-evpl {
base switching-capabilities;
description
"Ethernet Virtual Private Line (EVPL).";
reference
"RFC 6004: Generalized MPLS (GMPLS) Support for Metro
Ethernet Forum and G.8011 Ethernet Service
Switching";
}
identity switching-l2sc {
base switching-capabilities;
description
"Layer-2 Switch Capable (L2SC).";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity switching-tdm {
base switching-capabilities;
description
"Time-Division-Multiplex Capable (TDM).";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity switching-otn {
base switching-capabilities;
description
Busi, et al. Expires 22 August 2026 [Page 44]
Internet-Draft TE Common YANG Types February 2026
"OTN-TDM capable.";
reference
"RFC 7138: Traffic Engineering Extensions to OSPF for GMPLS
Control of Evolving G.709 Optical Transport
Networks";
}
identity switching-dcsc {
base switching-capabilities;
description
"Data Channel Switching Capable (DCSC).";
reference
"RFC 6002: Generalized MPLS (GMPLS) Data Channel
Switching Capable (DCSC) and Channel Set Label
Extensions";
}
identity switching-lsc {
base switching-capabilities;
description
"Lambda-Switch Capable (LSC).";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity switching-fsc {
base switching-capabilities;
description
"Fiber-Switch Capable (FSC).";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-types {
description
"Base identity for encoding types.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-packet {
base lsp-encoding-types;
description
"Packet LSP encoding.";
reference
Busi, et al. Expires 22 August 2026 [Page 45]
Internet-Draft TE Common YANG Types February 2026
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-ethernet {
base lsp-encoding-types;
description
"Ethernet LSP encoding.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-pdh {
base lsp-encoding-types;
description
"ANSI/ETSI PDH LSP encoding.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-sdh {
base lsp-encoding-types;
description
"SDH ITU-T G.707 / SONET ANSI T1.105 LSP encoding.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-digital-wrapper {
base lsp-encoding-types;
description
"Digital Wrapper LSP encoding.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-lambda {
base lsp-encoding-types;
description
"Lambda (photonic) LSP encoding.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
Busi, et al. Expires 22 August 2026 [Page 46]
Internet-Draft TE Common YANG Types February 2026
identity lsp-encoding-fiber {
base lsp-encoding-types;
description
"Fiber LSP encoding.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-fiber-channel {
base lsp-encoding-types;
description
"FiberChannel LSP encoding.";
reference
"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description";
}
identity lsp-encoding-oduk {
base lsp-encoding-types;
description
"G.709 ODUk (Digital Path) LSP encoding.";
reference
"RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Extensions for G.709 Optical Transport
Networks Control";
}
identity lsp-encoding-optical-channel {
base lsp-encoding-types;
description
"G.709 Optical Channel LSP encoding.";
reference
"RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Extensions for G.709 Optical Transport
Networks Control";
}
identity lsp-encoding-line {
base lsp-encoding-types;
description
"Line (e.g., 8B/10B) LSP encoding.";
reference
"RFC 6004: Generalized MPLS (GMPLS) Support for Metro
Ethernet Forum and G.8011 Ethernet Service
Switching";
}
Busi, et al. Expires 22 August 2026 [Page 47]
Internet-Draft TE Common YANG Types February 2026
identity path-signaling-type {
description
"Base identity from which specific LSP path setup types
are derived.";
}
identity path-setup-static {
base path-signaling-type;
description
"Static LSP provisioning path setup.";
}
identity path-setup-rsvp {
base path-signaling-type;
description
"RSVP-TE signaling path setup.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
}
identity path-setup-sr {
base path-signaling-type;
description
"Segment-routing path setup.";
}
identity path-scope-type {
description
"Base identity from which specific path scope types are
derived.";
}
identity path-scope-segment {
base path-scope-type;
description
"Path scope segment.";
reference
"RFC 4873: GMPLS Segment Recovery";
}
identity path-scope-end-to-end {
base path-scope-type;
description
"Path scope end to end.";
reference
"RFC 4873: GMPLS Segment Recovery";
}
Busi, et al. Expires 22 August 2026 [Page 48]
Internet-Draft TE Common YANG Types February 2026
identity route-usage-type {
description
"Base identity for route usage.";
}
identity route-include-object {
base route-usage-type;
description
"'Include route' object.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 4.3.2
RFC 5440: Path Computation Element (PCE) Communication
Protocol (PCEP), Section 7.12
RFC 7896: Update to the Include Route Object (IRO)
Specification in the Path Computation Element
Communication Protocol (PCEP)";
}
identity route-exclude-object {
base route-usage-type;
description
"'Exclude route' object.";
reference
"RFC 4874: Exclude Routes - Extension to Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE)";
}
identity route-exclude-srlg {
base route-usage-type;
description
"Excludes Shared Risk Link Groups (SRLGs).";
reference
"RFC 4874: Exclude Routes - Extension to Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE)";
}
identity path-metric-optimization-type {
description
"Base identity used to define the path metric optimization
types.";
}
identity link-path-metric-type {
description
"Base identity used to define the link and the path metric
types.
Busi, et al. Expires 22 August 2026 [Page 49]
Internet-Draft TE Common YANG Types February 2026
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.";
}
identity link-metric-type {
base link-path-metric-type;
description
"Base identity for the link metric types.";
}
identity link-metric-te {
base link-metric-type;
description
"Traffic Engineering (TE) Link Metric.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2, Section 2.5.5
RFC 5305: IS-IS Extensions for Traffic Engineering,
Section 3.7";
}
identity link-metric-igp {
base link-metric-type;
description
"Interior Gateway Protocol (IGP) Link Metric.";
reference
"RFC 3785: Use of Interior Gateway Protocol (IGP) Metric
as a second MPLS Traffic Engineering (TE)
Metric";
}
identity link-metric-delay-average {
base link-metric-type;
description
"Unidirectional Link Delay, measured in units of
microseconds.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions, Section 4.1
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions, Section 4.1";
}
identity link-metric-delay-minimum {
base link-metric-type;
description
Busi, et al. Expires 22 August 2026 [Page 50]
Internet-Draft TE Common YANG Types February 2026
"Minimum unidirectional Link Delay, measured in units of
microseconds.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions, Section 4.2
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions, Section 4.2";
}
identity link-metric-delay-maximum {
base link-metric-type;
description
"Maximum unidirectional Link Delay, measured in units of
microseconds.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions, Section 4.2
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions, Section 4.2";
}
identity link-metric-residual-bandwidth {
base link-metric-type;
description
"Unidirectional Residual Bandwidth, measured in units of
bytes per second.
It is defined to be Maximum Bandwidth minus the bandwidth
currently allocated to LSPs.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions, Section 4.5
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions, Section 4.5";
}
identity path-metric-type {
base link-path-metric-type;
base path-metric-optimization-type;
description
"Base identity for the path metric types.";
}
identity path-metric-te {
base path-metric-type;
description
"Traffic Engineering (TE) Path Metric.";
reference
Busi, et al. Expires 22 August 2026 [Page 51]
Internet-Draft TE Common YANG Types February 2026
"RFC 5440: Path Computation Element (PCE) Communication
Protocol (PCEP), Section 7.8";
}
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";
}
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";
}
identity path-metric-delay-average {
base path-metric-type;
description
"The Path Delay 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.1";
}
identity path-metric-delay-minimum {
base path-metric-type;
description
"The Path Min Delay Metric, measured in units of
microseconds.";
reference
"I-D.ietf-pce-sid-algo: Carrying SR-Algorithm information
in PCE-based Networks,
draft-ietf-pce-sid-algo-29,
Sections 4.5.1 and 4.5.2";
}
identity path-metric-residual-bandwidth {
base path-metric-type;
Busi, et al. Expires 22 August 2026 [Page 52]
Internet-Draft TE Common YANG Types February 2026
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)";
}
identity path-metric-optimize-includes {
base path-metric-optimization-type;
description
"A metric that optimizes the number of included resources
specified in a set.";
}
identity path-metric-optimize-excludes {
base path-metric-optimization-type;
description
"A metric that optimizes to a maximum the number of excluded
resources specified in a set.";
}
identity path-tiebreaker-type {
description
"Base identity for the path tiebreaker type.";
}
identity path-tiebreaker-minfill {
base path-tiebreaker-type;
description
"Min-Fill LSP path placement: selects the path with the most
available bandwidth (load balance LSPs over more links).";
}
identity path-tiebreaker-maxfill {
base path-tiebreaker-type;
description
"Max-Fill LSP path placement: selects the path with the least
available bandwidth (packing more LSPs over few links).";
}
identity path-tiebreaker-random {
base path-tiebreaker-type;
Busi, et al. Expires 22 August 2026 [Page 53]
Internet-Draft TE Common YANG Types February 2026
description
"Random LSP path placement.";
}
identity resource-affinities-type {
description
"Base identity for resource class affinities.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 2702: Requirements for Traffic Engineering Over MPLS";
}
identity resource-aff-include-all {
base resource-affinities-type;
description
"The set of attribute filters associated with a
tunnel, all of which must be present for a link
to be acceptable.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 2702: Requirements for Traffic Engineering Over MPLS";
}
identity resource-aff-include-any {
base resource-affinities-type;
description
"The set of attribute filters associated with a
tunnel, any of which must be present for a link
to be acceptable.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 2702: Requirements for Traffic Engineering Over MPLS";
}
identity resource-aff-exclude-any {
base resource-affinities-type;
description
"The set of attribute filters associated with a
tunnel, any of which renders a link unacceptable.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 2702: Requirements for Traffic Engineering Over MPLS";
}
identity te-optimization-criterion {
description
"Base identity for the TE optimization criteria.";
reference
Busi, et al. Expires 22 August 2026 [Page 54]
Internet-Draft TE Common YANG Types February 2026
"RFC 9522: Overview and Principles of Internet Traffic
Engineering";
}
identity not-optimized {
base te-optimization-criterion;
description
"Optimization is not applied.";
}
identity cost {
base te-optimization-criterion;
description
"Optimized on cost.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity delay {
base te-optimization-criterion;
description
"Optimized on delay.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity path-computation-srlg-type {
description
"Base identity for Shared Risk Link Group (SRLG) path
computation.";
}
identity srlg-ignore {
base path-computation-srlg-type;
description
"Ignores Shared Risk Link Groups (SRLGs) in the path
computation.";
}
identity srlg-strict {
base path-computation-srlg-type;
description
"Includes a strict Shared Risk Link Group (SRLG) check in
the path computation.";
Busi, et al. Expires 22 August 2026 [Page 55]
Internet-Draft TE Common YANG Types February 2026
}
identity srlg-preferred {
base path-computation-srlg-type;
description
"Includes a preferred Shared Risk Link Group (SRLG) check in
the path computation.";
}
identity srlg-weighted {
base path-computation-srlg-type;
description
"Includes a weighted Shared Risk Link Group (SRLG) check in
the path computation.";
}
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
Busi, et al. Expires 22 August 2026 [Page 56]
Internet-Draft TE Common YANG Types February 2026
"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";
}
Busi, et al. Expires 22 August 2026 [Page 57]
Internet-Draft TE Common YANG Types February 2026
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
Busi, et al. Expires 22 August 2026 [Page 58]
Internet-Draft TE Common YANG Types February 2026
/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
Busi, et al. Expires 22 August 2026 [Page 59]
Internet-Draft TE Common YANG Types February 2026
(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.
Busi, et al. Expires 22 August 2026 [Page 60]
Internet-Draft TE Common YANG Types February 2026
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 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)";
}
Busi, et al. Expires 22 August 2026 [Page 61]
Internet-Draft TE Common YANG Types February 2026
identity protocol-origin-bgp {
base protocol-origin-type;
description
"Protocol origin is Border Gateway Protocol (BGP).";
reference
"RFC 9012: The BGP Tunnel Encapsulation Attribute";
}
identity svec-objective-function-type {
description
"Base identity for SVEC objective function type.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol (PCEP)";
}
identity svec-of-minimize-agg-bandwidth-consumption {
base svec-objective-function-type;
description
"Objective function for minimizing aggregate bandwidth
consumption (MBC).";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity svec-of-minimize-load-most-loaded-link {
base svec-objective-function-type;
description
"Objective function for minimizing the load on the link that
is carrying the highest load (MLL).";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity svec-of-minimize-cost-path-set {
base svec-objective-function-type;
description
"Objective function for minimizing the cost on a path set
(MCC).";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
Busi, et al. Expires 22 August 2026 [Page 62]
Internet-Draft TE Common YANG Types February 2026
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.";
}
identity svec-metric-type {
description
"Base identity for SVEC metric type.";
reference
Busi, et al. Expires 22 August 2026 [Page 63]
Internet-Draft TE Common YANG Types February 2026
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol (PCEP)";
}
identity svec-metric-cumulative-te {
base svec-metric-type;
description
"Cumulative TE cost.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity svec-metric-cumulative-igp {
base svec-metric-type;
description
"Cumulative IGP cost.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity svec-metric-cumulative-hop {
base svec-metric-type;
description
"Cumulative Hop path metric.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity svec-metric-aggregate-bandwidth-consumption {
base svec-metric-type;
description
"Aggregate bandwidth consumption.";
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
identity svec-metric-load-of-the-most-loaded-link {
base svec-metric-type;
description
"Load of the most loaded link.";
Busi, et al. Expires 22 August 2026 [Page 64]
Internet-Draft TE Common YANG Types February 2026
reference
"RFC 5541: Encoding of Objective Functions in the Path
Computation Element Communication Protocol
(PCEP)";
}
/*
* Typedefs
*/
typedef admin-group {
type yang:hex-string {
/* 01:02:03:04 */
length "1..11";
}
description
"Administrative group / resource class / color representation
in 'hex-string' type.
The most significant byte in the hex-string is the farthest
to the left in the byte sequence.
Leading zero bytes in the configured value may be omitted
for brevity.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2
RFC 5305: IS-IS Extensions for Traffic Engineering
RFC 7308: Extended Administrative Groups in MPLS Traffic
Engineering (MPLS-TE)";
}
typedef admin-groups {
type union {
type admin-group;
type extended-admin-group;
}
description
"Derived types for TE administrative groups.";
}
typedef extended-admin-group {
type yang:hex-string;
description
"Extended administrative group / resource class / color
representation in 'hex-string' type.
The most significant byte in the hex-string is the farthest
Busi, et al. Expires 22 August 2026 [Page 65]
Internet-Draft TE Common YANG Types February 2026
to the left in the byte sequence.
Leading zero bytes in the configured value may be omitted
for brevity.";
reference
"RFC 7308: Extended Administrative Groups in MPLS Traffic
Engineering (MPLS-TE)";
}
typedef path-attribute-flags {
type union {
type identityref {
base session-attributes-flags;
}
type identityref {
base lsp-attributes-flags;
}
}
description
"Path attributes flags type.";
}
typedef performance-metrics-normality {
type enumeration {
enum unknown {
value 0;
description
"Unknown.";
}
enum normal {
value 1;
description
"Normal.
Indicates that the anomalous bit is not set.";
}
enum abnormal {
value 2;
description
"Abnormal.
Indicates that the anomalous bit is set.";
}
}
description
"Indicates whether a performance metric is normal (anomalous
bit not set), abnormal (anomalous bit set), or unknown.";
reference
Busi, et al. Expires 22 August 2026 [Page 66]
Internet-Draft TE Common YANG Types February 2026
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
}
typedef srlg {
type uint32;
description
"Shared Risk Link Group (SRLG) type.";
reference
"RFC 4203: OSPF Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS)
RFC 5307: IS-IS Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS)";
}
typedef te-common-status {
type enumeration {
enum up {
description
"Enabled.";
}
enum down {
description
"Disabled.";
}
enum testing {
description
"In some test mode.";
}
enum preparing-maintenance {
description
"The resource is disabled in the control plane to prepare
for a graceful shutdown for maintenance purposes.";
reference
"RFC 5817: Graceful Shutdown in MPLS and Generalized MPLS
Traffic Engineering Networks";
}
enum maintenance {
description
"The resource is disabled in the data plane for maintenance
purposes.";
}
enum unknown {
description
"Status is unknown.";
Busi, et al. Expires 22 August 2026 [Page 67]
Internet-Draft TE Common YANG Types February 2026
}
}
description
"Defines a type representing the common states of a TE
resource.";
}
typedef te-bandwidth {
type string {
pattern '0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|'
+ '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?'
+ '[pP](\+)?(12[0-7]|'
+ '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+'
+ '(,(0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|'
+ '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?'
+ '[pP](\+)?(12[0-7]|'
+ '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+))*';
}
description
"This is the generic bandwidth type.
It is a string containing a list of numbers separated by
commas, where each of these numbers can be non-negative
decimal, hex integer, or hex float, as defined in
ISO/IEC 9899:
(dec | hex | float)[*(','(dec | hex | float))]
For the packet-switching type, the string encoding MUST follow
the type 'bandwidth-ieee-float32' as defined in RFC 8294
(e.g., 0x1p10), where the units are in bytes per second.
Canonically, the string is represented as all lowercase and in
hex, where the prefix '0x' precedes the hex number.";
reference
"ISO/IEC 9899:2024: Information Technology - Programming
Languages - C, Section 6.4.4.2
RFC 8294: Common YANG Data Types for the Routing Area";
}
typedef te-ds-class {
type uint8 {
range "0..7";
}
description
"The Differentiated Services Class-Type of traffic.";
reference
"RFC 4124: Protocol Extensions for Support of Diffserv-aware
Busi, et al. Expires 22 August 2026 [Page 68]
Internet-Draft TE Common YANG Types February 2026
MPLS Traffic Engineering, Section 4.3.1";
}
typedef te-global-id {
type uint32;
description
"An identifier to uniquely identify an operator, which can be
either a provider or a client.
The definition of this type is taken from RFCs 6370 and 5003.
This attribute type is used solely to provide a globally
unique context for TE topologies.";
reference
"RFC 5003: Attachment Individual Identifier (AII) Types for
Aggregation
RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers";
}
typedef te-hop-type {
type enumeration {
enum loose {
description
"A loose hop in an explicit path.";
}
enum strict {
description
"A strict hop in an explicit path.";
}
}
description
"Enumerated type for specifying loose or strict paths.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 4.3.3";
}
typedef te-link-access-type {
type enumeration {
enum point-to-point {
description
"The link is point-to-point.";
}
enum multi-access {
description
"The link is multi-access, including broadcast and NBMA.";
}
}
Busi, et al. Expires 22 August 2026 [Page 69]
Internet-Draft TE Common YANG Types February 2026
description
"The access types of a TE link.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2";
}
typedef te-label-direction {
type enumeration {
enum forward {
description
"Label allocated for the forward LSP direction.";
}
enum reverse {
description
"Label allocated for the reverse LSP direction.";
}
}
description
"Enumerated type for specifying the forward or reverse
label.";
}
typedef te-link-direction {
type enumeration {
enum incoming {
description
"The explicit route represents an incoming link on
a node.";
}
enum outgoing {
description
"The explicit route represents an outgoing link on
a node.";
}
}
description
"Enumerated type for specifying the direction of a link on
a node.";
}
typedef te-metric {
type uint32;
description
"Traffic Engineering (TE) metric.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2, Section 2.5.5
Busi, et al. Expires 22 August 2026 [Page 70]
Internet-Draft TE Common YANG Types February 2026
RFC 5305: IS-IS Extensions for Traffic Engineering,
Section 3.7";
}
typedef te-node-id {
type union {
type yang:dotted-quad;
type inet:ipv6-address-no-zone;
}
description
"A type representing the identifier for a node in a TE
topology.
The identifier is represented either as 4 octets in
dotted-quad notation, or 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 RFC 3630, the TE Router ID
described in Section 3 of RFC 6827, the Traffic Engineering
Router ID TLV described in Section 4.3 of RFC 5305, the TE
Router ID TLV described in Section 3.2.1 of RFC 6119, or the
IPv6 TE Router ID TLV described in Section 4.1 of RFC 6119.
The reachability of such a TE node MAY be achieved by a
mechanism such as that described in Section 6.2 of RFC 6827.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2, Section 2.4.1
RFC 5305: IS-IS Extensions for Traffic Engineering,
Section 4.3
RFC 6119: IPv6 Traffic Engineering in IS-IS, Section 3.2.1
RFC 6827: Automatically Switched Optical Network (ASON)
Routing for OSPFv2 Protocols, Section 3";
}
typedef te-oper-status {
type te-common-status;
description
"Defines a type representing the operational status of
a TE resource.";
}
typedef te-admin-status {
type te-common-status;
description
"Defines a type representing the administrative status of
a TE resource.";
Busi, et al. Expires 22 August 2026 [Page 71]
Internet-Draft TE Common YANG Types February 2026
}
typedef te-path-disjointness {
type bits {
bit node {
position 0;
description
"Node disjoint.";
}
bit link {
position 1;
description
"Link disjoint.";
}
bit srlg {
position 2;
description
"Shared Risk Link Group (SRLG) disjoint.";
}
}
description
"Type of the resource disjointness for a TE tunnel path.";
reference
"RFC 4872: RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery";
}
typedef te-recovery-status {
type enumeration {
enum normal {
description
"Both the recovery span and the working span are fully
allocated and active, data traffic is being
transported over (or selected from) the working
span, and no trigger events are reported.";
}
enum recovery-started {
description
"The recovery action has been started but not completed.";
}
enum recovery-succeeded {
description
"The recovery action has succeeded.
The working span has reported a failure/degrade condition,
and the user traffic is being transported (or selected)
on the recovery span.";
Busi, et al. Expires 22 August 2026 [Page 72]
Internet-Draft TE Common YANG Types February 2026
}
enum recovery-failed {
description
"The recovery action has failed.";
}
enum reversion-started {
description
"The reversion has started.";
}
enum reversion-succeeded {
description
"The reversion action has succeeded.";
}
enum reversion-failed {
description
"The reversion has failed.";
}
enum recovery-unavailable {
description
"The recovery is unavailable, as a result of either an
operator's lockout command or a failure condition
detected on the recovery span.";
}
enum recovery-admin {
description
"The operator has issued a command to switch the user
traffic to the recovery span.";
}
enum wait-to-restore {
description
"The recovery domain is recovering from a failure/degrade
condition on the working span that is being controlled by
the Wait-to-Restore (WTR) timer.";
}
}
description
"Defines the status of a recovery action.";
reference
"RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
RFC 4427: Recovery (Protection and Restoration) Terminology
for Generalized Multi-Protocol Label Switching
(GMPLS)";
}
typedef te-template-name {
type string {
pattern '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*';
}
Busi, et al. Expires 22 August 2026 [Page 73]
Internet-Draft TE Common YANG Types February 2026
description
"A type for the name of a TE node template or TE link
template.";
}
typedef te-topology-event-type {
type enumeration {
enum add {
value 0;
description
"A TE node or TE link has been added.";
}
enum remove {
value 1;
description
"A TE node or TE link has been removed.";
}
enum update {
value 2;
description
"A TE node or TE link has been updated.";
}
}
description
"TE event type for notifications.";
}
typedef te-topology-id {
type union {
type string {
length "0";
// empty string
}
type string {
pattern '([a-zA-Z0-9\-_.]+:)*'
+ '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*';
}
}
description
"An identifier for a topology.
It is optional to have one or more prefixes at the beginning,
separated by colons.
The prefixes can be 'network-types' as defined in the
'ietf-network' module in RFC 8345, to help the user better
understand the topology before further inquiry is made.";
reference
Busi, et al. Expires 22 August 2026 [Page 74]
Internet-Draft TE Common YANG Types February 2026
"RFC 8345: A YANG Data Model for Network Topologies";
}
typedef te-tp-id {
type union {
type uint32;
// Unnumbered
type inet:ip-address;
// IPv4 or IPv6 address
}
description
"An identifier for a TE link endpoint on a node.
This attribute is mapped to a local or remote link identifier
as defined in RFCs 3630 and 5305.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2
RFC 5305: IS-IS Extensions for Traffic Engineering";
}
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.";
}
/*
* TE bandwidth groupings
Busi, et al. Expires 22 August 2026 [Page 75]
Internet-Draft TE Common YANG Types February 2026
*/
grouping te-bandwidth {
description
"This grouping defines the generic TE bandwidth.
For some known data-plane technologies, specific modeling
structures are specified.
The string-encoded 'te-bandwidth' type is used for
unspecified technologies.
The modeling structure can be augmented later for other
technologies.";
container te-bandwidth {
description
"Container that specifies TE bandwidth.
The choices can be augmented for specific data-plane
technologies.";
choice technology {
default "generic";
description
"Data-plane technology type.";
case generic {
leaf generic {
type te-bandwidth;
description
"Bandwidth specified in a generic format.";
}
}
}
}
}
/*
* TE label groupings
*/
grouping te-label {
description
"This grouping defines the generic TE label.
The modeling structure can be augmented for each technology.
For unspecified technologies, 'rt-types:generalized-label'
is used.";
container te-label {
Busi, et al. Expires 22 August 2026 [Page 76]
Internet-Draft TE Common YANG Types February 2026
description
"Container that specifies the TE label.
The choices can be augmented for specific data-plane
technologies.";
choice technology {
default "generic";
description
"Data-plane technology type.";
case generic {
leaf generic {
type rt-types:generalized-label;
description
"TE label specified in a generic format.";
}
}
}
leaf direction {
type te-label-direction;
default "forward";
description
"Label direction.";
}
}
}
grouping te-topology-identifier {
description
"Augmentation for a TE topology.";
container te-topology-identifier {
description
"TE topology identifier container.";
leaf provider-id {
type te-global-id;
default "0";
description
"An identifier to uniquely identify a provider.
If omitted, it assumes that the topology provider ID
value = 0 (the default).";
}
leaf client-id {
type te-global-id;
default "0";
description
"An identifier to uniquely identify a client.
If omitted, it assumes that the topology client ID
value = 0 (the default).";
}
Busi, et al. Expires 22 August 2026 [Page 77]
Internet-Draft TE Common YANG Types February 2026
leaf topology-id {
type te-topology-id;
default "";
description
"When the datastore contains several topologies,
'topology-id' distinguishes between them.
If omitted, the default (empty) string for this leaf is
assumed.";
}
}
}
/*
* TE performance metrics groupings
*/
grouping performance-metrics-one-way-delay-loss {
description
"Performance Metrics (PM) information in real time that can
be applicable to links or connections.
PM defined in this grouping are applicable to generic TE PM
as well as packet TE PM.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions";
leaf one-way-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
description
"One-way delay or latency, also known as Unidirectional Link
Delay.";
reference
"RFC 7679: A One-Way Delay Metric for IP Performance
Metrics (IPPM)";
}
leaf one-way-delay-normality {
type te-types:performance-metrics-normality;
description
"The normality of the 'one-way-delay' metric.";
}
}
Busi, et al. Expires 22 August 2026 [Page 78]
Internet-Draft TE Common YANG Types February 2026
grouping performance-metrics-two-way-delay-loss {
description
"Performance Metrics (PM) information in real time that can be
applicable to links or connections.
PM defined in this grouping are applicable to generic TE PM
as well as packet TE PM.";
leaf two-way-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
description
"Two-way delay or latency, also known as Roudn-trip Delay.";
reference
"RFC 2681: A Round-trip Delay Metric for IPPM";
}
leaf two-way-delay-normality {
type te-types:performance-metrics-normality;
description
"The normality of the 'two-way-delay' metric.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions";
}
}
grouping performance-metrics-one-way-bandwidth {
description
"Performance Metrics (PM) information in real time that can be
applicable to links.
PM defined in this grouping are applicable to generic TE PM
as well as packet TE PM.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions";
leaf one-way-residual-bandwidth {
type rt-types:bandwidth-ieee-float32;
units "bytes per second";
default "0x0p0";
description
Busi, et al. Expires 22 August 2026 [Page 79]
Internet-Draft TE Common YANG Types February 2026
"Residual bandwidth that subtracts tunnel reservations from
Maximum Bandwidth (or link capacity) (RFC 3630) and
provides an aggregated remainder across QoS classes.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2";
}
leaf one-way-residual-bandwidth-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"Residual bandwidth normality.";
}
leaf one-way-available-bandwidth {
type rt-types:bandwidth-ieee-float32;
units "bytes per second";
default "0x0p0";
description
"Available bandwidth that is defined to be residual
bandwidth minus the measured bandwidth used for the
actual forwarding of non-RSVP-TE LSP packets.
For a bundled link, available bandwidth is defined to be
the sum of the component link available bandwidths.";
}
leaf one-way-available-bandwidth-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"Available bandwidth normality.";
}
leaf one-way-utilized-bandwidth {
type rt-types:bandwidth-ieee-float32;
units "bytes per second";
default "0x0p0";
description
"Bandwidth utilization that represents the actual
utilization of the link (i.e., as measured in the router).
For a bundled link, bandwidth utilization is defined to
be the sum of the component link bandwidth utilizations.";
}
leaf one-way-utilized-bandwidth-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"Bandwidth utilization normality.";
}
}
Busi, et al. Expires 22 August 2026 [Page 80]
Internet-Draft TE Common YANG Types February 2026
grouping one-way-performance-metrics {
description
"One-way Performance Metrics (PM) throttle grouping.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions";
leaf one-way-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"One-way delay or latency, also known as Unidirectional Link
Delay.";
reference
"RFC 7679: A One-Way Delay Metric for IP Performance
Metrics (IPPM)";
}
leaf one-way-residual-bandwidth {
type rt-types:bandwidth-ieee-float32;
units "bytes per second";
default "0x0p0";
description
"Residual bandwidth that subtracts tunnel reservations from
Maximum Bandwidth (or link capacity) (RFC 3630) and
provides an aggregated remainder across QoS classes.";
reference
"RFC 3630: Traffic Engineering (TE) Extensions to OSPF
Version 2";
}
leaf one-way-available-bandwidth {
type rt-types:bandwidth-ieee-float32;
units "bytes per second";
default "0x0p0";
description
"Available bandwidth that is defined to be residual
bandwidth minus the measured bandwidth used for the
actual forwarding of non-RSVP-TE LSP packets.
For a bundled link, available bandwidth is defined to be
the sum of the component link available bandwidths.";
}
leaf one-way-utilized-bandwidth {
type rt-types:bandwidth-ieee-float32;
Busi, et al. Expires 22 August 2026 [Page 81]
Internet-Draft TE Common YANG Types February 2026
units "bytes per second";
default "0x0p0";
description
"Bandwidth utilization that represents the actual
utilization of the link (i.e., as measured in the router).
For a bundled link, bandwidth utilization is defined to
be the sum of the component link bandwidth utilizations.";
}
}
grouping two-way-performance-metrics {
description
"Two-way Performance Metrics (PM) throttle grouping.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions";
leaf two-way-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"Two-way delay or latency, also known as Roudn-trip Delay.";
reference
"RFC 2681: A Round-trip Delay Metric for IPPM";
}
}
grouping performance-metrics-thresholds {
description
"Grouping for configurable thresholds for measured
attributes.";
uses one-way-performance-metrics;
uses two-way-performance-metrics;
}
grouping performance-metrics-attributes {
description
"Contains Performance Metrics (PM) attributes.";
container performance-metrics-one-way {
description
"One-way link performance information in real time.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
Busi, et al. Expires 22 August 2026 [Page 82]
Internet-Draft TE Common YANG Types February 2026
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions";
uses performance-metrics-one-way-delay-loss;
uses performance-metrics-one-way-bandwidth;
}
container performance-metrics-two-way {
description
"Two-way link performance information in real time.";
reference
"RFC 6374: Packet Loss and Delay Measurement for MPLS
Networks";
uses performance-metrics-two-way-delay-loss;
}
}
grouping performance-metrics-throttle-container {
description
"Controls Performance Metrics (PM) throttling.";
container throttle {
must 'suppression-interval >= measure-interval' {
error-message "'suppression-interval' cannot be less than "
+ "'measure-interval'.";
description
"Constraint on 'suppression-interval' and
'measure-interval'.";
}
description
"Link performance information in real time.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions";
leaf one-way-delay-offset {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"Offset value to be added to the measured delay value.";
}
leaf measure-interval {
type uint32;
units "seconds";
Busi, et al. Expires 22 August 2026 [Page 83]
Internet-Draft TE Common YANG Types February 2026
default "30";
description
"Interval to measure the extended metric values.";
}
leaf advertisement-interval {
type uint32;
units "seconds";
default "0";
description
"Interval to advertise the extended metric values.";
}
leaf suppression-interval {
type uint32 {
range "1..max";
}
units "seconds";
default "120";
description
"Interval to suppress advertisement of the extended metric
values.";
reference
"RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions, Section 6";
}
container threshold-out {
description
"If the measured parameter falls outside an upper bound
for all but the minimum-delay metric (or a lower bound
for the minimum-delay metric only) and the advertised
value is not already outside that bound, an 'anomalous'
announcement (anomalous bit set) will be triggered.";
uses performance-metrics-thresholds;
}
container threshold-in {
description
"If the measured parameter falls inside an upper bound
for all but the minimum-delay metric (or a lower bound
for the minimum-delay metric only) and the advertised
value is not already inside that bound, a 'normal'
announcement (anomalous bit cleared) will be triggered.";
uses performance-metrics-thresholds;
}
container threshold-accelerated-advertisement {
description
"When the difference between the last advertised value and
the current measured value exceeds this threshold, an
'anomalous' announcement (anomalous bit set) will be
triggered.";
Busi, et al. Expires 22 August 2026 [Page 84]
Internet-Draft TE Common YANG Types February 2026
uses performance-metrics-thresholds;
}
}
}
/*
* TE tunnel generic groupings
*/
grouping explicit-route-hop {
description
"The explicit route entry grouping.";
choice type {
description
"The explicit route entry type.";
case numbered-node-hop {
container numbered-node-hop {
must 'node-id-uri or node-id' {
description
"At least one node identifier needs to be present.";
}
description
"Numbered node route hop.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 4.3, EXPLICIT_ROUTE in RSVP-TE
RFC 3477: Signalling Unnumbered Links in Resource
ReSerVation Protocol - Traffic Engineering
(RSVP-TE)";
leaf node-id-uri {
type nw:node-id;
description
"The identifier of a node in the topology.";
}
leaf node-id {
type te-node-id;
description
"The identifier of a node in the TE topology.";
}
leaf hop-type {
type te-hop-type;
default "strict";
description
"Strict or loose hop.";
}
}
}
case numbered-link-hop {
Busi, et al. Expires 22 August 2026 [Page 85]
Internet-Draft TE Common YANG Types February 2026
container numbered-link-hop {
description
"Numbered link explicit route hop.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 4.3, EXPLICIT_ROUTE in RSVP-TE
RFC 3477: Signalling Unnumbered Links in Resource
ReSerVation Protocol - Traffic Engineering
(RSVP-TE)";
leaf link-tp-id {
type te-tp-id;
mandatory true;
description
"TE Link Termination Point (LTP) identifier.";
}
leaf hop-type {
type te-hop-type;
default "strict";
description
"Strict or loose hop.";
}
leaf direction {
type te-link-direction;
default "outgoing";
description
"Link route object direction.";
}
}
}
case unnumbered-link-hop {
container unnumbered-link-hop {
must '(link-tp-id-uri or link-tp-id) and '
+ '(node-id-uri or node-id)' {
description
"At least one node identifier and at least one Link
Termination Point (LTP) identifier need to be
present.";
}
description
"Unnumbered link explicit route hop.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
Section 4.3, EXPLICIT_ROUTE in RSVP-TE
RFC 3477: Signalling Unnumbered Links in Resource
ReSerVation Protocol - Traffic Engineering
(RSVP-TE)";
leaf link-tp-id-uri {
type nt:tp-id;
Busi, et al. Expires 22 August 2026 [Page 86]
Internet-Draft TE Common YANG Types February 2026
description
"Link Termination Point (LTP) identifier.";
}
leaf link-tp-id {
type te-tp-id;
description
"TE LTP identifier.
The combination of the TE link ID and the TE node ID
is used to identify an unnumbered TE link.";
}
leaf node-id-uri {
type nw:node-id;
description
"The identifier of a node in the topology.";
}
leaf node-id {
type te-node-id;
description
"The identifier of a node in the TE topology.";
}
leaf hop-type {
type te-hop-type;
default "strict";
description
"Strict or loose hop.";
}
leaf direction {
type te-link-direction;
default "outgoing";
description
"Link route object direction.";
}
}
}
case as-number {
container as-number-hop {
description
"Autonomous System (AS) explicit route hop.";
leaf as-number {
type inet:as-number;
mandatory true;
description
"The Autonomous System (AS) number.";
}
leaf hop-type {
type te-hop-type;
default "strict";
Busi, et al. Expires 22 August 2026 [Page 87]
Internet-Draft TE Common YANG Types February 2026
description
"Strict or loose hop.";
}
}
}
case label {
description
"The label explicit route hop type.";
container label-hop {
description
"Label hop type.";
uses te-label;
}
}
}
}
grouping explicit-route-hop-with-srlg {
description
"Augments the explicit route entry grouping with Shared Risk
Link Group (SRLG) hop type.";
uses explicit-route-hop {
augment "type" {
description
"Augmentation for a generic explicit route for Shared
Risk Link Group (SRLG) inclusion or exclusion.";
case srlg {
description
"An Shared Risk Link Group (SRLG) value to be
included or excluded.";
container srlg {
description
"Shared Risk Link Group (SRLG) container.";
leaf srlg {
type uint32;
description
"Shared Risk Link Group (SRLG) value.";
}
}
}
}
}
}
grouping record-route-state {
description
"The Record Route grouping.";
leaf index {
Busi, et al. Expires 22 August 2026 [Page 88]
Internet-Draft TE Common YANG Types February 2026
type uint32;
description
"Record Route hop index.
The index is used to identify an entry in the list.
The order of entries is defined by the user without relying
on key values.";
}
choice type {
description
"The Record Route entry type.";
case numbered-node-hop {
description
"Numbered node route hop.";
container numbered-node-hop {
must 'node-id-uri or node-id' {
description
"At least one node identifier need to be present.";
}
description
"Numbered node route hop container.";
leaf node-id-uri {
type nw:node-id;
description
"The identifier of a node in the topology.";
}
leaf node-id {
type te-node-id;
description
"The identifier of a node in the TE topology.";
}
leaf-list flags {
type path-attribute-flags;
description
"Path attributes flags.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
Tunnels
RFC 4561: Definition of a Record Route Object (RRO)
Node-Id Sub-Object";
}
}
}
case numbered-link-hop {
description
"Numbered link route hop.";
Busi, et al. Expires 22 August 2026 [Page 89]
Internet-Draft TE Common YANG Types February 2026
container numbered-link-hop {
description
"Numbered link route hop container.";
leaf link-tp-id {
type te-tp-id;
mandatory true;
description
"Numbered TE LTP identifier.";
}
leaf-list flags {
type path-attribute-flags;
description
"Path attributes flags.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
Tunnels
RFC 4561: Definition of a Record Route Object (RRO)
Node-Id Sub-Object";
}
}
}
case unnumbered-link-hop {
description
"Unnumbered link route hop.";
container unnumbered-link-hop {
must '(link-tp-id-uri or link-tp-id) and '
+ '(node-id-uri or node-id)' {
description
"At least one node identifier and at least one Link
Termination Point (LTP) identifier need to be
present.";
}
description
"Unnumbered link Record Route hop.";
reference
"RFC 3477: Signalling Unnumbered Links in Resource
ReSerVation Protocol - Traffic Engineering
(RSVP-TE)";
leaf link-tp-id-uri {
type nt:tp-id;
description
"Link Termination Point (LTP) identifier.";
}
leaf link-tp-id {
type te-tp-id;
description
"TE LTP identifier.
Busi, et al. Expires 22 August 2026 [Page 90]
Internet-Draft TE Common YANG Types February 2026
The combination of the TE link ID and the TE node ID
is used to identify an unnumbered TE link.";
}
leaf node-id-uri {
type nw:node-id;
description
"The identifier of a node in the topology.";
}
leaf node-id {
type te-node-id;
description
"The identifier of a node in the TE topology.";
}
leaf-list flags {
type path-attribute-flags;
description
"Path attributes flags.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
Tunnels
RFC 4561: Definition of a Record Route Object (RRO)
Node-Id Sub-Object";
}
}
}
case label {
description
"The label Record Route entry types.";
container label-hop {
description
"Label route hop type.";
uses te-label;
leaf-list flags {
type path-attribute-flags;
description
"Path attributes flags.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
Tunnels
RFC 4561: Definition of a Record Route Object (RRO)
Node-Id Sub-Object";
}
}
}
}
}
Busi, et al. Expires 22 August 2026 [Page 91]
Internet-Draft TE Common YANG Types February 2026
grouping label-restriction-info {
description
"Label set item information.";
leaf restriction {
type enumeration {
enum inclusive {
description
"The label or label range is inclusive.";
}
enum exclusive {
description
"The label or label range is exclusive.";
}
}
default "inclusive";
description
"Indicates whether the list item is inclusive or exclusive.";
}
leaf index {
type uint32;
description
"The index of the label restriction list entry.";
}
container label-start {
must "(not(../label-end/te-label/direction) and"
+ " not(te-label/direction))"
+ " or "
+ "(../label-end/te-label/direction = te-label/direction)"
+ " or "
+ "(not(te-label/direction) and"
+ " (../label-end/te-label/direction = 'forward'))"
+ " or "
+ "(not(../label-end/te-label/direction) and"
+ " (te-label/direction = 'forward'))" {
error-message "'label-start' and 'label-end' must have the "
+ "same direction.";
}
description
"This is the starting label if a label range is specified.
This is the label value if a single label is specified,
in which case the 'label-end' attribute is not set.";
uses te-label;
}
container label-end {
must "(not(../label-start/te-label/direction) and"
+ " not(te-label/direction))"
+ " or "
+ "(../label-start/te-label/direction = "
Busi, et al. Expires 22 August 2026 [Page 92]
Internet-Draft TE Common YANG Types February 2026
+ "te-label/direction)"
+ " or "
+ "(not(te-label/direction) and"
+ " (../label-start/te-label/direction = 'forward'))"
+ " or "
+ "(not(../label-start/te-label/direction) and"
+ " (te-label/direction = 'forward'))" {
error-message "'label-start' and 'label-end' must have the "
+ "same direction.";
}
description
"This is the ending label if a label range is specified.
This attribute is not set if a single label is specified.";
uses te-label;
}
container label-step {
description
"The step increment between labels in the label range.
The label start/end values MUST be consistent with the sign
of label step.
For example:
'label-start' < 'label-end' enforces 'label-step' > 0
'label-start' > 'label-end' enforces 'label-step' < 0.";
choice technology {
default "generic";
description
"Data-plane technology type.";
case generic {
leaf generic {
type int32;
default "1";
description
"Label range step.";
}
}
}
}
leaf range-bitmap {
type yang:hex-string;
description
"When there are gaps between 'label-start' and 'label-end',
this attribute is used to specify the positions
of the used labels.
This is represented in big endian as 'hex-string'.
Busi, et al. Expires 22 August 2026 [Page 93]
Internet-Draft TE Common YANG Types February 2026
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.
The most significant byte in the hex-string is the farthest
to the left in the byte sequence.
Leading zero bytes in the configured value may be omitted
for brevity.
Each bit position in the 'range-bitmap' 'hex-string' maps
to a label in the range derived from 'label-start'.
For example, assuming that 'label-start' = 16000 and
'range-bitmap' = 0x01000001, then:
- bit position (0) is set, and the corresponding mapped
label from the range is 16000 + (0 * 'label-step') or
16000 for default 'label-step' = 1.
- bit position (24) is set, and the corresponding mapped
label from the range is 16000 + (24 * 'label-step') or
16024 for default 'label-step' = 1.";
}
}
grouping label-set-info {
description
"Grouping for the list of label restrictions specifying what
labels may or may not be used.";
container label-restrictions {
description
"The label restrictions container.";
list label-restriction {
key "index";
description
"The absence of the label restrictions container implies
that all labels are acceptable; otherwise, only restricted
labels are available.";
reference
"RFC 7579: General Network Element Constraint Encoding
for GMPLS-Controlled Networks";
uses label-restriction-info;
}
Busi, et al. Expires 22 August 2026 [Page 94]
Internet-Draft TE Common YANG Types February 2026
}
}
grouping optimization-metric-entry {
description
"Optimization metrics configuration grouping.";
leaf metric-type {
type identityref {
base path-metric-optimization-type;
}
description
"Identifies the 'metric-type' that the path computation
process uses for optimization.";
}
leaf weight {
type uint8;
default "1";
description
"TE path metric normalization weight.";
}
container explicit-route-exclude-objects {
when "../metric-type = "
+ "'te-types:path-metric-optimize-excludes'";
description
"Container for the 'exclude route' object list.";
uses path-route-exclude-objects;
}
container explicit-route-include-objects {
when "../metric-type = "
+ "'te-types:path-metric-optimize-includes'";
description
"Container for the 'include route' object list.";
uses path-route-include-objects;
}
}
grouping common-constraints {
description
"Common constraints grouping that can be set on
a constraint set or directly on the tunnel.";
uses te-bandwidth {
description
"A requested bandwidth to use for path computation.";
}
leaf link-protection {
type identityref {
base link-protection-type;
}
Busi, et al. Expires 22 August 2026 [Page 95]
Internet-Draft TE Common YANG Types February 2026
default "te-types:link-protection-unprotected";
description
"Link protection type required for the links included
in the computed path.";
reference
"RFC 4202: Routing Extensions in Support of
Generalized Multi-Protocol Label Switching
(GMPLS)";
}
leaf setup-priority {
type uint8 {
range "0..7";
}
default "7";
description
"TE LSP requested setup priority.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
}
leaf hold-priority {
type uint8 {
range "0..7";
}
default "7";
description
"TE LSP requested hold priority.";
reference
"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
}
leaf signaling-type {
type identityref {
base path-signaling-type;
}
default "te-types:path-setup-rsvp";
description
"TE tunnel path signaling type.";
}
}
grouping tunnel-constraints {
description
"Tunnel constraints grouping that can be set on
a constraint set or directly on the tunnel.";
leaf network-id {
type nw:network-id;
description
"The network topology identifier.";
}
Busi, et al. Expires 22 August 2026 [Page 96]
Internet-Draft TE Common YANG Types February 2026
uses te-topology-identifier;
uses common-constraints;
}
grouping path-constraints-route-objects {
description
"List of route entries to be included or excluded when
performing the path computation.";
container explicit-route-objects {
description
"Container for the explicit route object lists.";
list route-object-exclude-always {
key "index";
ordered-by user;
description
"List of route objects to always exclude from the path
computation.";
leaf index {
type uint32;
description
"Explicit Route Object index.
The index is used to identify an entry in the list.
The order of entries is defined by the user without
relying on key values.";
}
uses explicit-route-hop {
refine "type/numbered-node-hop/numbered-node-hop"
+ "/hop-type" {
must '. = "strict"' {
description
"Loose hops can only be used for 'include' route
objects.";
reference
"RFC 4874: Exclude Routes - Extension to Resource
ReserVation Protocol-Traffic Engineering
(RSVP-TE), Section 3.1";
}
}
}
}
list route-object-include-exclude {
key "index";
ordered-by user;
description
"List of route objects to include or exclude in the path
computation.";
Busi, et al. Expires 22 August 2026 [Page 97]
Internet-Draft TE Common YANG Types February 2026
leaf explicit-route-usage {
type identityref {
base route-usage-type;
}
default "te-types:route-include-object";
description
"Indicates whether to include or exclude the
route object.
The default is to include it.";
}
leaf index {
type uint32;
description
"Route object include-exclude index.
The index is used to identify an entry in the list.
The order of entries is defined by the user without
relying on key values.";
}
uses explicit-route-hop-with-srlg {
refine "type/numbered-node-hop/numbered-node-hop"
+ "/hop-type" {
must '(. = "strict") or '
+ 'derived-from-or-self(../../explicit-route-usage,'
+ '"te-types:route-include-object")' {
description
"Loose hops can only be used for 'include' route
objects.";
reference
"RFC 4874: Exclude Routes - Extension to Resource
ReserVation Protocol-Traffic Engineering
(RSVP-TE), Section 3.1";
}
}
}
}
}
}
grouping path-route-include-objects {
description
"List of route objects to be included when performing
the path computation.";
list route-object-include-object {
key "index";
ordered-by user;
Busi, et al. Expires 22 August 2026 [Page 98]
Internet-Draft TE Common YANG Types February 2026
description
"List of Explicit Route Objects to be included in the
path computation.";
leaf index {
type uint32;
description
"Route object entry index.
The index is used to identify an entry in the list.
The order of entries is defined by the user without
relying on key values.";
}
uses explicit-route-hop;
}
}
grouping path-route-exclude-objects {
description
"List of route objects to be excluded when performing
the path computation.";
list route-object-exclude-object {
key "index";
ordered-by user;
description
"List of Explicit Route Objects to be excluded in the
path computation.";
leaf index {
type uint32;
description
"Route object entry index.
The index is used to identify an entry in the list.
The order of entries is defined by the user without
relying on key values.";
}
uses explicit-route-hop-with-srlg;
}
}
grouping generic-path-metric-bounds {
description
"TE path metric bounds grouping.";
container path-metric-bounds {
description
"Top-level container for the list of path metric bounds.";
list path-metric-bound {
Busi, et al. Expires 22 August 2026 [Page 99]
Internet-Draft TE Common YANG Types February 2026
key "metric-type";
description
"List of path metric bounds, which can apply to link and
path metrics.
TE paths which have at least one path metric which
exceeds the specified bounds MUST NOT be selected.
TE paths that traverse TE links which have at least one
link metric which exceeds the specified bounds MUST NOT
be selected.";
leaf metric-type {
type identityref {
base link-path-metric-type;
}
description
"Identifies an entry in the list of 'metric-type' items
bound for the TE path.";
}
leaf upper-bound {
type uint64;
default "0";
description
"Upper bound on the specified 'metric-type'.
A zero indicates an unbounded upper limit for the
specified 'metric-type'.
The unit of is interpreted in the context of the
'metric-type' identity.";
}
}
}
}
grouping generic-path-optimization {
description
"TE generic path optimization grouping.";
container optimizations {
description
"The objective function container that includes
attributes to impose when computing a TE path.";
choice algorithm {
description
"Optimizations algorithm.";
case metric {
if-feature "path-optimization-metric";
/* Optimize by metric */
Busi, et al. Expires 22 August 2026 [Page 100]
Internet-Draft TE Common YANG Types February 2026
list optimization-metric {
key "metric-type";
description
"TE path metric type.";
uses optimization-metric-entry;
}
/* Tiebreakers */
container tiebreakers {
status deprecated;
description
"Container for the list of tiebreakers.
This container has been deprecated by the tiebreaker
leaf.";
list tiebreaker {
key "tiebreaker-type";
status deprecated;
description
"The list of tiebreaker criteria to apply on an
equally favored set of paths, in order to pick
the best.";
leaf tiebreaker-type {
type identityref {
base path-metric-type;
}
status deprecated;
description
"Identifies an entry in the list of tiebreakers.";
}
}
}
}
case objective-function {
if-feature "path-optimization-objective-function";
/* Objective functions */
container objective-function {
description
"The objective function container that includes
attributes to impose when computing a TE path.";
leaf objective-function-type {
type identityref {
base objective-function-type;
}
default "te-types:of-minimize-cost-path";
description
"Objective function entry.";
}
}
Busi, et al. Expires 22 August 2026 [Page 101]
Internet-Draft TE Common YANG Types February 2026
}
}
}
leaf tiebreaker {
type identityref {
base path-tiebreaker-type;
}
default "te-types:path-tiebreaker-random";
description
"The tiebreaker criteria to apply on an equally favored set
of paths, in order to pick the best.";
}
}
grouping generic-path-affinities {
description
"Path affinities grouping.";
container path-affinities-values {
description
"Path affinities represented as values.";
list path-affinities-value {
key "usage";
description
"List of named affinity constraints.";
leaf usage {
type identityref {
base resource-affinities-type;
}
description
"Identifies an entry in the list of value affinity
constraints.";
}
leaf value {
type admin-groups;
default "";
description
"The affinity value.
The default is empty.";
}
}
}
container path-affinity-names {
description
"Path affinities represented as names.";
list path-affinity-name {
key "usage";
description
Busi, et al. Expires 22 August 2026 [Page 102]
Internet-Draft TE Common YANG Types February 2026
"List of named affinity constraints.";
leaf usage {
type identityref {
base resource-affinities-type;
}
description
"Identifies an entry in the list of named affinity
constraints.";
}
list affinity-name {
key "name";
description
"List of named affinities.";
leaf name {
type string;
description
"Identifies a named affinity entry.";
}
}
}
}
}
grouping generic-path-srlgs {
description
"Path Shared Risk Link Group (SRLG) grouping.";
container path-srlgs-lists {
description
"Path Shared Risk Link Group (SRLG) properties container.";
list path-srlgs-list {
key "usage";
description
"List of Shared Risk Link Group (SRLG) values to be
included or excluded.";
leaf usage {
type identityref {
base route-usage-type;
}
description
"Identifies an entry in a list of Shared Risk Link Groups
(SRLGs) to either include or exclude.";
}
leaf-list values {
type srlg;
description
"List of Shared Risk Link Group (SRLG) values.";
}
}
Busi, et al. Expires 22 August 2026 [Page 103]
Internet-Draft TE Common YANG Types February 2026
}
container path-srlgs-names {
description
"Container for the list of named Shared Risk Link Groups
(SRLGs).";
list path-srlgs-name {
key "usage";
description
"List of named Shared Risk Link Groups (SRLGs) to be
included or excluded.";
leaf usage {
type identityref {
base route-usage-type;
}
description
"Identifies an entry in a list of named Shared Risk Link
Groups (SRLGs) to either include or exclude.";
}
leaf-list names {
type string;
description
"List of named Shared Risk Link Groups (SRLGs).";
}
}
}
}
grouping generic-path-disjointness {
description
"Path disjointness grouping.";
leaf disjointness {
type te-path-disjointness;
description
"The type of resource disjointness.
When configured for a primary path, the disjointness level
applies to all secondary LSPs.
When configured for a secondary path, the disjointness
level overrides the level configured for the primary path.";
}
}
grouping common-path-constraints-attributes {
description
"Common path constraints configuration grouping.";
uses common-constraints;
uses generic-path-metric-bounds;
uses generic-path-affinities;
Busi, et al. Expires 22 August 2026 [Page 104]
Internet-Draft TE Common YANG Types February 2026
uses generic-path-srlgs;
}
grouping generic-path-constraints {
description
"Global named path constraints configuration grouping.";
container path-constraints {
description
"TE named path constraints container.";
uses common-path-constraints-attributes;
uses generic-path-disjointness;
}
}
grouping generic-path-properties {
description
"TE generic path properties grouping.";
container path-properties {
config false;
description
"The TE path properties.";
list path-metric {
key "metric-type";
description
"TE path metric type.";
leaf metric-type {
type identityref {
base path-metric-type;
}
description
"TE path metric type.";
}
leaf accumulative-value {
type uint64;
description
"TE path metric accumulative value.";
}
}
uses generic-path-affinities;
uses generic-path-srlgs;
container path-route-objects {
description
"Container for the list of route objects either returned by
the computation engine or actually used by an LSP.";
list path-route-object {
key "index";
ordered-by user;
description
Busi, et al. Expires 22 August 2026 [Page 105]
Internet-Draft TE Common YANG Types February 2026
"List of route objects either returned by the computation
engine or actually used by an LSP.";
leaf index {
type uint32;
description
"Route object entry index.
The index is used to identify an entry in the list.
The order of entries is defined by the user without
relying on key values.";
}
uses explicit-route-hop;
}
}
}
}
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";
}
}
grouping te-generic-node-id {
description
"A reusable grouping for a TE generic node identifier.";
leaf id {
Busi, et al. Expires 22 August 2026 [Page 106]
Internet-Draft TE Common YANG Types February 2026
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 a 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.";
}
}
}
<CODE ENDS>
Figure 1: TE Types YANG module
5. Packet TE Types YANG Module
The "ietf-te-packet-types" module imports the following modules:
* "ietf-yang-types" as defined in [RFC9911]
* "ietf-te-types" as defined in Section 4 of this document
Busi, et al. Expires 22 August 2026 [Page 107]
Internet-Draft TE Common YANG Types February 2026
<CODE BEGINS> file "ietf-te-packet-types@2026-01-15.yang"
module ietf-te-packet-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-packet-types";
prefix te-packet-types;
import ietf-yang-types {
prefix yang;
reference
"RFC 9911: Common YANG Data Types";
}
import ietf-te-types {
prefix te-types;
reference
"RFC XXXX: Common YANG Data Types for Traffic Engineering";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Tarek Saad
<mailto:tsaad.net@gmail.com>
Editor: Rakesh Gandhi
<mailto:rgandhi@cisco.com>
Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>
Editor: Igor Bryskin
<mailto:i_bryskin@yahoo.com>";
description
"This YANG module contains a collection of generally useful YANG
data type definitions specific to Packet Traffic Engineering
(TE).
The model conforms to the Network Management Datastore
Architecture (NMDA).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
Busi, et al. Expires 22 August 2026 [Page 108]
Internet-Draft TE Common YANG Types February 2026
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
revision 2026-01-15 {
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";
}
revision 2020-06-10 {
description
"Latest revision of TE MPLS types.";
reference
"RFC 8776: Common YANG Data Types for Traffic Engineering";
}
/*
* Identities
Busi, et al. Expires 22 August 2026 [Page 109]
Internet-Draft TE Common YANG Types February 2026
*/
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";
}
// Derived identities from te-types:link-metric-type
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";
}
identity link-metric-loss {
base te-types:link-metric-type;
description
Busi, et al. Expires 22 August 2026 [Page 110]
Internet-Draft TE Common YANG Types February 2026
"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";
}
// Derived identities from te-types:path-metric-type
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";
}
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";
}
identity backup-protection-type {
description
"Base identity for the backup protection type.";
}
identity backup-protection-link {
base backup-protection-type;
description
"Backup provides link protection only.";
}
identity backup-protection-node-link {
base backup-protection-type;
description
Busi, et al. Expires 22 August 2026 [Page 111]
Internet-Draft TE Common YANG Types February 2026
"Backup offers node (preferred) or link protection.";
}
identity bc-model-type {
description
"Base identity for the Diffserv-TE Bandwidth Constraints
Model type.";
reference
"RFC 4124: Protocol Extensions for Support of Diffserv-aware
MPLS Traffic Engineering";
}
identity bc-model-rdm {
base bc-model-type;
description
"Russian Dolls Bandwidth Constraints Model type.";
reference
"RFC 4127: Russian Dolls Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering";
}
identity bc-model-mam {
base bc-model-type;
description
"Maximum Allocation Bandwidth Constraints Model type.";
reference
"RFC 4125: Maximum Allocation Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering";
}
identity bc-model-mar {
base bc-model-type;
description
"Maximum Allocation with Reservation Bandwidth Constraints
Model type.";
reference
"RFC 4126: Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons";
}
/*
* Typedefs
*/
typedef te-bandwidth-requested-type {
type enumeration {
enum specified-value {
Busi, et al. Expires 22 August 2026 [Page 112]
Internet-Draft TE Common YANG Types February 2026
description
"Bandwidth value is explicitly specified.";
}
enum specified-profile {
description
"Bandwidth profile is explicitly specified.";
}
enum auto {
description
"Bandwidth is automatically computed.";
}
}
description
"Enumerated type for specifying whether bandwidth is
explicitly specified or automatically computed.";
}
typedef te-class-type {
type uint8;
description
"Diffserv-TE Class-Type.
Defines a set of Traffic Trunks crossing a link that is
governed by a specific set of bandwidth constraints.
Class-Type is used for the purposes of link bandwidth
allocation, constraint-based routing, and admission control.";
reference
"RFC 4124: Protocol Extensions for Support of Diffserv-aware
MPLS Traffic Engineering";
}
typedef bc-type {
type uint8 {
range "0..7";
}
description
"Diffserv-TE bandwidth constraints as defined in RFC 4124.";
reference
"RFC 4124: Protocol Extensions for Support of Diffserv-aware
MPLS Traffic Engineering";
}
typedef bandwidth-kbps {
type uint64;
units "kilobits per second";
description
"Bandwidth values, expressed in kilobits per second.";
}
Busi, et al. Expires 22 August 2026 [Page 113]
Internet-Draft TE Common YANG Types February 2026
typedef bandwidth-mbps {
type uint64;
units "megabits per second";
description
"Bandwidth values, expressed in megabits per second.";
}
typedef bandwidth-gbps {
type uint64;
units "gigabits per second";
description
"Bandwidth values, expressed in gigabits per second.";
}
/*
* Groupings
*/
grouping performance-metrics-attributes-packet {
description
"Contains Performance Metrics (PM) information.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE Metric
Extensions";
uses te-types:performance-metrics-attributes {
augment "performance-metrics-one-way" {
description
"Performance Metrics (PM) one-way packet-specific
augmentation for a generic PM grouping.";
leaf one-way-min-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
description
"One-way minimum delay or latency.";
}
leaf one-way-min-delay-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"One-way minimum delay or latency normality.";
}
leaf one-way-max-delay {
type uint32 {
Busi, et al. Expires 22 August 2026 [Page 114]
Internet-Draft TE Common YANG Types February 2026
range "0..16777215";
}
units "microseconds";
description
"One-way maximum delay or latency.";
}
leaf one-way-max-delay-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"One-way maximum delay or latency normality.";
}
leaf one-way-delay-variation {
type uint32 {
range "0..16777215";
}
units "microseconds";
description
"One-way delay variation.";
reference
"RFC 5481: Packet Delay Variation Applicability
Statement, Section 4.2";
}
leaf one-way-delay-variation-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"One-way delay variation normality.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions
RFC 7823: Performance-Based Path Selection for
Explicitly Routed Label Switched Paths (LSPs)
Using TE Metric Extensions";
}
leaf one-way-packet-loss {
type decimal64 {
fraction-digits 6;
range "0..50.331642";
}
units "percent";
description
"One-way packet loss as a percentage of the total traffic
sent over a configurable interval.
The finest precision is 0.000003%.";
Busi, et al. Expires 22 August 2026 [Page 115]
Internet-Draft TE Common YANG Types February 2026
reference
"RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions, Section 4.4";
}
leaf one-way-packet-loss-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"Packet loss normality.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions
RFC 7823: Performance-Based Path Selection for
Explicitly Routed Label Switched Paths (LSPs)
Using TE Metric Extensions";
}
}
augment "performance-metrics-two-way" {
description
"Performance Metrics (PM) two-way packet-specific
augmentation for a generic PM grouping.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
RFC 7823: Performance-Based Path Selection for Explicitly
Routed Label Switched Paths (LSPs) Using TE
Metric Extensions";
leaf two-way-min-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"Two-way minimum delay or latency.";
}
leaf two-way-min-delay-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"Two-way minimum delay or latency normality.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions
Busi, et al. Expires 22 August 2026 [Page 116]
Internet-Draft TE Common YANG Types February 2026
RFC 7823: Performance-Based Path Selection for
Explicitly Routed Label Switched Paths (LSPs)
Using TE Metric Extensions";
}
leaf two-way-max-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"Two-way maximum delay or latency.";
}
leaf two-way-max-delay-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"Two-way maximum delay or latency normality.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Extensions
RFC 7823: Performance-Based Path Selection for
Explicitly Routed Label Switched Paths (LSPs)
Using TE Metric Extensions";
}
leaf two-way-delay-variation {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"Two-way delay variation.";
reference
"RFC 5481: Packet Delay Variation Applicability
Statement, Section 4.2";
}
leaf two-way-delay-variation-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"Two-way delay variation normality.";
reference
"RFC 7471: OSPF Traffic Engineering (TE) Metric
Extensions
RFC 8570: IS-IS Traffic Engineering (TE) Metric
Busi, et al. Expires 22 August 2026 [Page 117]
Internet-Draft TE Common YANG Types February 2026
Extensions
RFC 7823: Performance-Based Path Selection for
Explicitly Routed Label Switched Paths (LSPs)
Using TE Metric Extensions";
}
leaf two-way-packet-loss {
type decimal64 {
fraction-digits 6;
range "0..50.331642";
}
units "percent";
default "0";
description
"Two-way packet loss as a percentage of the total traffic
sent over a configurable interval.
The finest precision is 0.000003%.";
}
leaf two-way-packet-loss-normality {
type te-types:performance-metrics-normality;
default "normal";
description
"Two-way packet loss normality.";
}
}
}
}
grouping one-way-performance-metrics-packet {
description
"One-way packet Performance Metrics (PM) throttle grouping.";
leaf one-way-min-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"One-way minimum delay or latency.";
}
leaf one-way-max-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"One-way maximum delay or latency.";
Busi, et al. Expires 22 August 2026 [Page 118]
Internet-Draft TE Common YANG Types February 2026
}
leaf one-way-delay-variation {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"One-way delay variation.";
}
leaf one-way-packet-loss {
type decimal64 {
fraction-digits 6;
range "0..50.331642";
}
units "percent";
default "0";
description
"One-way packet loss as a percentage of the total traffic
sent over a configurable interval.
The finest precision is 0.000003%.";
}
}
grouping one-way-performance-metrics-gauge-packet {
description
"One-way packet Performance Metrics (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;
units "microseconds";
description
"One-way minimum delay or latency.";
}
leaf one-way-max-delay {
type yang:gauge64;
units "microseconds";
description
"One-way maximum delay or latency.";
reference
"RFC 7679: A One-Way Delay Metric for IP Performance
Metrics (IPPM)";
}
Busi, et al. Expires 22 August 2026 [Page 119]
Internet-Draft TE Common YANG Types February 2026
leaf one-way-delay-variation {
type yang:gauge64;
units "microseconds";
description
"One-way delay variation.";
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)";
}
}
grouping two-way-performance-metrics-packet {
description
"Two-way packet Performance Metrics (PM) throttle grouping.";
leaf two-way-min-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"Two-way minimum delay or latency.";
}
leaf two-way-max-delay {
type uint32 {
range "0..16777215";
}
units "microseconds";
default "0";
description
"Two-way maximum delay or latency.";
}
leaf two-way-delay-variation {
type uint32 {
range "0..16777215";
}
Busi, et al. Expires 22 August 2026 [Page 120]
Internet-Draft TE Common YANG Types February 2026
units "microseconds";
default "0";
description
"Two-way delay variation.";
}
leaf two-way-packet-loss {
type decimal64 {
fraction-digits 6;
range "0..50.331642";
}
units "percent";
default "0";
description
"Two-way packet loss as a percentage of the total traffic
sent over a configurable interval.
The finest precision is 0.000003%.";
}
}
grouping two-way-performance-metrics-gauge-packet {
description
"Two-way packet Performance Metrics (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;
units "microseconds";
description
"Two-way minimum delay or latency.";
reference
"RFC 2681: A Round-trip Delay Metric for IPPM";
}
leaf two-way-max-delay {
type yang:gauge64;
units "microseconds";
description
"Two-way maximum delay or latency.";
reference
"RFC 2681: A Round-trip Delay Metric for IPPM";
}
leaf two-way-delay-variation {
type yang:gauge64;
units "microseconds";
description
Busi, et al. Expires 22 August 2026 [Page 121]
Internet-Draft TE Common YANG Types February 2026
"Two-way delay variation.";
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.";
}
}
grouping performance-metrics-throttle-container-packet {
description
"Packet Performance Metrics (PM) threshold grouping.";
uses te-types:performance-metrics-throttle-container {
augment "throttle/threshold-out" {
description
"Performance Metrics (PM) threshold-out packet
augmentation for a generic grouping.";
uses one-way-performance-metrics-packet;
uses two-way-performance-metrics-packet;
}
augment "throttle/threshold-in" {
description
"Performance Metrics (PM) threshold-in packet augmentation
for a generic grouping.";
uses one-way-performance-metrics-packet;
uses two-way-performance-metrics-packet;
}
augment "throttle/threshold-accelerated-advertisement" {
description
"Performance Metrics (PM) accelerated advertisement packet
augmentation for a generic grouping.";
uses one-way-performance-metrics-packet;
uses two-way-performance-metrics-packet;
}
}
}
grouping bandwidth-profile-parameters {
description
"Common parameters to define bandwidth profiles, also known as
traffic profiles in RFC 2475, that may be used to specify the
temporal properties of a packet stream (e.g., MPLS-TE LSPs),
Busi, et al. Expires 22 August 2026 [Page 122]
Internet-Draft TE Common YANG Types February 2026
e.g., as specified in MEF 10, RFC 2697 or RFC 2698.";
reference
"RFC 2475: An Architecture for Differentiated Services
MEF 10.3: Ethernet Services Attributes Phase 3
RFC 2697: A Single Rate Three Color Marker
RFC 2698: A Two Rate Three Color Marker";
leaf cir {
type uint64;
units "bits per second";
description
"Committed Information Rate (CIR).";
}
leaf cbs {
type uint64;
units "bytes";
description
"Committed Burst Size (CBS).";
}
leaf eir {
type uint64;
units "bits per second";
description
"Excess Information Rate (EIR).";
}
leaf ebs {
type uint64;
units "bytes";
description
"Excess Burst Size (EBS).";
}
leaf pir {
type uint64;
units "bits per second";
description
"Peak Information Rate (PIR).";
}
leaf pbs {
type uint64;
units "bytes";
description
"Peak Burst Size (PBS).";
}
}
grouping te-packet-path-bandwidth {
description
"Bandwidth attributes for TE Packet paths.";
container packet-bandwidth {
Busi, et al. Expires 22 August 2026 [Page 123]
Internet-Draft TE Common YANG Types February 2026
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";
}
Busi, et al. Expires 22 August 2026 [Page 124]
Internet-Draft TE Common YANG Types February 2026
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.";
}
}
}
grouping te-packet-link-bandwidth {
description
"Bandwidth attributes for Packet TE links.";
leaf packet-bandwidth {
type uint64;
units "bits per second";
description
"Bandwidth value for Packet TE links.";
}
}
}
<CODE ENDS>
Figure 2: Packet TE Types YANG module
6. IANA Considerations
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 requests IANA to register the following YANG modules in
the "YANG Module Names" registry [RFC6020][RFC9890] within the "YANG
Parameters" registry group.
Busi, et al. Expires 22 August 2026 [Page 125]
Internet-Draft TE Common YANG Types February 2026
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
7. Security Considerations
This section is modeled after the template described in Section 3.7
of [I-D.ietf-netmod-rfc8407bis].
The "ietf-te-types" and the "ietf-te-packet-types" YANG modules
define data models that are designed to be accessed via YANG-based
management protocols, such as NETCONF [RFC6241] and RESTCONF
[RFC8040]. These YANG-based management protocols (1) have to use a
secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC
[RFC9000]) and (2) have to use mutual authentication.
The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.
The YANG modules define a set of identities, types, and groupings.
These nodes are intended to be reused by other YANG modules. The
modules by themselves do not expose any data nodes that are writable,
data nodes that contain read-only state, or RPCs. As such, there are
no additional security issues related to the YANG module that need to
be considered.
Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example using 'explicit-route-hop', 'record-route-state' or 'te-
topology-identifier' (which includes the 'client-id') groupings may
expose sensitive topology information.
8. References
8.1. Normative References
Busi, et al. Expires 22 August 2026 [Page 126]
Internet-Draft TE Common YANG Types February 2026
[ISOIEC_9899]
International Organization for Standardization (ISO) and
International Electrotechnical Commission (IEC),
"Information Technology - Programming Languages - C", ISO/
IEC 9899:2024 , October 2024,
<https://www.iso.org/standard/82075.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/rfc/rfc2681>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/rfc/rfc3209>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003,
<https://www.rfc-editor.org/rfc/rfc3471>.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
<https://www.rfc-editor.org/rfc/rfc3477>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/rfc/rfc3630>.
[RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and
T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric
as a second MPLS Traffic Engineering (TE) Metric", BCP 87,
RFC 3785, DOI 10.17487/RFC3785, May 2004,
<https://www.rfc-editor.org/rfc/rfc3785>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/rfc/rfc4090>.
Busi, et al. Expires 22 August 2026 [Page 127]
Internet-Draft TE Common YANG Types February 2026
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
DOI 10.17487/RFC4124, June 2005,
<https://www.rfc-editor.org/rfc/rfc4124>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<https://www.rfc-editor.org/rfc/rfc4202>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/rfc/rfc4203>.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328,
DOI 10.17487/RFC4328, January 2006,
<https://www.rfc-editor.org/rfc/rfc4328>.
[RFC4561] Vasseur, J.-P., Ed., Ali, Z., and S. Sivabalan,
"Definition of a Record Route Object (RRO) Node-Id Sub-
Object", RFC 4561, DOI 10.17487/RFC4561, June 2006,
<https://www.rfc-editor.org/rfc/rfc4561>.
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/rfc/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/rfc/rfc4873>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/rfc/rfc4875>.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N.,
and G. Ash, "Crankback Signaling Extensions for MPLS and
GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007,
<https://www.rfc-editor.org/rfc/rfc4920>.
Busi, et al. Expires 22 August 2026 [Page 128]
Internet-Draft TE Common YANG Types February 2026
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, DOI 10.17487/RFC5003, September
2007, <https://www.rfc-editor.org/rfc/rfc5003>.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
<https://www.rfc-editor.org/rfc/rfc5150>.
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
Domain MPLS and GMPLS Traffic Engineering -- Resource
Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 5151, DOI 10.17487/RFC5151, February
2008, <https://www.rfc-editor.org/rfc/rfc5151>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/rfc/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/rfc/rfc5307>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangar, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <https://www.rfc-editor.org/rfc/rfc5420>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<https://www.rfc-editor.org/rfc/rfc5441>.
Busi, et al. Expires 22 August 2026 [Page 129]
Internet-Draft TE Common YANG Types February 2026
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", RFC 5520,
DOI 10.17487/RFC5520, April 2009,
<https://www.rfc-editor.org/rfc/rfc5520>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/rfc/rfc5541>.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557,
July 2009, <https://www.rfc-editor.org/rfc/rfc5557>.
[RFC5712] Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic
Engineering Soft Preemption", RFC 5712,
DOI 10.17487/RFC5712, January 2010,
<https://www.rfc-editor.org/rfc/rfc5712>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/rfc/rfc5952>.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
Extensions for Multi-Layer and Multi-Region Networks (MLN/
MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010,
<https://www.rfc-editor.org/rfc/rfc6001>.
[RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
Channel Switching Capable (DCSC) and Channel Set Label
Extensions", RFC 6002, DOI 10.17487/RFC6002, October 2010,
<https://www.rfc-editor.org/rfc/rfc6002>.
[RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support
for Metro Ethernet Forum and G.8011 Ethernet Service
Switching", RFC 6004, DOI 10.17487/RFC6004, October 2010,
<https://www.rfc-editor.org/rfc/rfc6004>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/rfc/rfc6020>.
Busi, et al. Expires 22 August 2026 [Page 130]
Internet-Draft TE Common YANG Types February 2026
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/rfc/rfc6119>.
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, DOI 10.17487/RFC6368, September 2011,
<https://www.rfc-editor.org/rfc/rfc6368>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370,
DOI 10.17487/RFC6370, September 2011,
<https://www.rfc-editor.org/rfc/rfc6370>.
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
October 2011, <https://www.rfc-editor.org/rfc/rfc6378>.
[RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
Label Switched Paths", RFC 6511, DOI 10.17487/RFC6511,
February 2012, <https://www.rfc-editor.org/rfc/rfc6511>.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
ASSOCIATION Object Extensions", RFC 6780,
DOI 10.17487/RFC6780, October 2012,
<https://www.rfc-editor.org/rfc/rfc6780>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/rfc/rfc6790>.
[RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou,
Ed., "Automatically Switched Optical Network (ASON)
Routing for OSPFv2 Protocols", RFC 6827,
DOI 10.17487/RFC6827, January 2013,
<https://www.rfc-editor.org/rfc/rfc6827>.
[RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS
Switching Capability and Type Fields", RFC 7074,
DOI 10.17487/RFC7074, November 2013,
<https://www.rfc-editor.org/rfc/rfc7074>.
Busi, et al. Expires 22 August 2026 [Page 131]
Internet-Draft TE Common YANG Types February 2026
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/rfc/rfc7138>.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139,
DOI 10.17487/RFC7139, March 2014,
<https://www.rfc-editor.org/rfc/rfc7139>.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
Extensions for Operations, Administration, and Maintenance
(OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June
2014, <https://www.rfc-editor.org/rfc/rfc7260>.
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
<https://www.rfc-editor.org/rfc/rfc7271>.
[RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
Traffic Engineering (MPLS-TE)", RFC 7308,
DOI 10.17487/RFC7308, July 2014,
<https://www.rfc-editor.org/rfc/rfc7308>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/rfc/rfc7471>.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/rfc/rfc7551>.
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B.
Wright, "Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)", RFC 7570,
DOI 10.17487/RFC7570, July 2015,
<https://www.rfc-editor.org/rfc/rfc7570>.
Busi, et al. Expires 22 August 2026 [Page 132]
Internet-Draft TE Common YANG Types February 2026
[RFC7571] Dong, J., Chen, M., Li, Z., and D. Ceccarelli, "GMPLS
RSVP-TE Extensions for Lock Instruct and Loopback",
RFC 7571, DOI 10.17487/RFC7571, July 2015,
<https://www.rfc-editor.org/rfc/rfc7571>.
[RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and
J. Han, "General Network Element Constraint Encoding for
GMPLS-Controlled Networks", RFC 7579,
DOI 10.17487/RFC7579, June 2015,
<https://www.rfc-editor.org/rfc/rfc7579>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/rfc/rfc7679>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8001] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C.,
Hartley, M., and Z. Ali, "RSVP-TE Extensions for
Collecting Shared Risk Link Group (SRLG) Information",
RFC 8001, DOI 10.17487/RFC8001, January 2017,
<https://www.rfc-editor.org/rfc/rfc8001>.
[RFC8149] Saad, T., Ed., Gandhi, R., Ed., Ali, Z., Venator, R., and
Y. Kamite, "RSVP Extensions for Reoptimization of Loosely
Routed Point-to-Multipoint Traffic Engineering Label
Switched Paths (LSPs)", RFC 8149, DOI 10.17487/RFC8149,
April 2017, <https://www.rfc-editor.org/rfc/rfc8149>.
[RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
and A. Vainshtein, "Residence Time Measurement in MPLS
Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017,
<https://www.rfc-editor.org/rfc/rfc8169>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) to Compute Service-Aware Label Switched
Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
2017, <https://www.rfc-editor.org/rfc/rfc8233>.
Busi, et al. Expires 22 August 2026 [Page 133]
Internet-Draft TE Common YANG Types February 2026
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/rfc/rfc8294>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/rfc/rfc8306>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/rfc/rfc8341>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/rfc/rfc8345>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/rfc/rfc8570>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/rfc/rfc8685>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/rfc/rfc8776>.
[RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element Communication Protocol (PCEP)
Extension for Label Switched Path (LSP) Diversity
Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,
July 2020, <https://www.rfc-editor.org/rfc/rfc8800>.
Busi, et al. Expires 22 August 2026 [Page 134]
Internet-Draft TE Common YANG Types February 2026
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/rfc/rfc9012>.
[RFC9890] Bierman, A., Boucadair, M., Ed., and Q. Wu, "An Update to
YANG Module Names Registration", RFC 9890,
DOI 10.17487/RFC9890, October 2025,
<https://www.rfc-editor.org/rfc/rfc9890>.
[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
DOI 10.17487/RFC9911, December 2025,
<https://www.rfc-editor.org/rfc/rfc9911>.
8.2. Informative References
[I-D.ietf-netmod-rfc8407bis]
Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
Authors and Reviewers of Documents Containing YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-rfc8407bis-28, 5 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-28>.
[I-D.ietf-pce-sid-algo]
Sidor, S., Rose, Z., Peng, S., Peng, S., and A. Stone,
"Carrying SR-Algorithm in Path Computation Element
Communication Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-sid-algo-29, 15 October
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-sid-algo-29>.
[MEF_10.3] MEF, "Ethernet Services Attributes Phase 3", MEF 10.3 ,
October 2013,
<https://www.mef.net/Assets/Technical_Specifications/PDF/
MEF_10.pdf>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/rfc/rfc2205>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/rfc/rfc2328>.
Busi, et al. Expires 22 August 2026 [Page 135]
Internet-Draft TE Common YANG Types February 2026
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/rfc/rfc2330>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/rfc/rfc2475>.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
<https://www.rfc-editor.org/rfc/rfc2697>.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
<https://www.rfc-editor.org/rfc/rfc2698>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999,
<https://www.rfc-editor.org/rfc/rfc2702>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/rfc/rfc3031>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/rfc/rfc3688>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<https://www.rfc-editor.org/rfc/rfc3945>.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005,
<https://www.rfc-editor.org/rfc/rfc4125>.
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126,
DOI 10.17487/RFC4126, June 2005,
<https://www.rfc-editor.org/rfc/rfc4126>.
Busi, et al. Expires 22 August 2026 [Page 136]
Internet-Draft TE Common YANG Types February 2026
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering",
RFC 4127, DOI 10.17487/RFC4127, June 2005,
<https://www.rfc-editor.org/rfc/rfc4127>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/rfc/rfc4252>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006,
<https://www.rfc-editor.org/rfc/rfc4427>.
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/rfc/rfc4657>.
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
"Reoptimization of Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) Loosely Routed Label Switched
Path (LSP)", RFC 4736, DOI 10.17487/RFC4736, November
2006, <https://www.rfc-editor.org/rfc/rfc4736>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<https://www.rfc-editor.org/rfc/rfc5921>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
"Performance-Based Path Selection for Explicitly Routed
Label Switched Paths (LSPs) Using TE Metric Extensions",
RFC 7823, DOI 10.17487/RFC7823, May 2016,
<https://www.rfc-editor.org/rfc/rfc7823>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
Busi, et al. Expires 22 August 2026 [Page 137]
Internet-Draft TE Common YANG Types February 2026
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/rfc/rfc8340>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet
Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
January 2024, <https://www.rfc-editor.org/rfc/rfc9522>.
Appendix A. The Complete Schema Trees
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.
A.1. TE Types Schema Tree
=============== 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
Busi, et al. Expires 22 August 2026 [Page 138]
Internet-Draft TE Common YANG Types February 2026
+-- 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?
Busi, et al. Expires 22 August 2026 [Page 139]
Internet-Draft TE Common YANG Types February 2026
| | 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
Busi, et al. Expires 22 August 2026 [Page 140]
Internet-Draft TE Common YANG Types February 2026
| +-- 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 explicit-route-hop-with-srlg:
+-- (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)
Busi, et al. Expires 22 August 2026 [Page 141]
Internet-Draft TE Common YANG Types February 2026
| +-- 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 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
Busi, et al. Expires 22 August 2026 [Page 142]
Internet-Draft TE Common YANG Types February 2026
| +-- 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
Busi, et al. Expires 22 August 2026 [Page 143]
Internet-Draft TE Common YANG Types February 2026
| | +-- 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)
Busi, et al. Expires 22 August 2026 [Page 144]
Internet-Draft TE Common YANG Types February 2026
| +-- 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
Busi, et al. Expires 22 August 2026 [Page 145]
Internet-Draft TE Common YANG Types February 2026
| +--:(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
Busi, et al. Expires 22 August 2026 [Page 146]
Internet-Draft TE Common YANG Types February 2026
| +-- (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
Busi, et al. Expires 22 August 2026 [Page 147]
Internet-Draft TE Common YANG Types February 2026
| +-- 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
Busi, et al. Expires 22 August 2026 [Page 148]
Internet-Draft TE Common YANG Types February 2026
| | | | | +-- 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
Busi, et al. Expires 22 August 2026 [Page 149]
Internet-Draft TE Common YANG Types February 2026
| | | | +-- 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
Busi, et al. Expires 22 August 2026 [Page 150]
Internet-Draft TE Common YANG Types February 2026
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]
Busi, et al. Expires 22 August 2026 [Page 151]
Internet-Draft TE Common YANG Types February 2026
| +-- 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)
Busi, et al. Expires 22 August 2026 [Page 152]
Internet-Draft TE Common YANG Types February 2026
| +--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? union
+-- type? enumeration
A.2. Packet TE Types Schema Tree
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
Busi, et al. Expires 22 August 2026 [Page 153]
Internet-Draft TE Common YANG Types February 2026
| +-- 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:
Busi, et al. Expires 22 August 2026 [Page 154]
Internet-Draft TE Common YANG Types February 2026
+-- 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
Busi, et al. Expires 22 August 2026 [Page 155]
Internet-Draft TE Common YANG Types February 2026
+-- 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
Appendix B. Changes from RFC 8776
This version adds new common data types, identities, and groupings to
the YANG modules. It also updates some of the existing data types,
identities, and groupings in the YANG modules and fixes few bugs in
[RFC8776].
The following new identities have been added to the 'ietf-te-types'
module:
Busi, et al. Expires 22 August 2026 [Page 156]
Internet-Draft TE Common YANG Types February 2026
* lsp-provisioning-error-reason;
* association-type-diversity;
* tunnel-admin-state-auto;
* lsp-restoration-restore-none;
* restoration-scheme-rerouting;
* path-metric-optimization-type;
* link-path-metric-type;
* link-metric-type and its derived identities;
* path-computation-error-reason and its derived identities;
* protocol-origin-type and its derived identities;
* svec-objective-function-type and its derived identities;
* svec-metric-type and its derived identities.
The following new data types have been added to the 'ietf-te-types'
module:
* path-type.
The following new groupings have been added to the 'ietf-te-types'
module:
* explicit-route-hop-with-srlg;
* encoding-and-switching-type;
* te-generic-node-id.
The following new identities have been added to the 'ietf-te-packet-
types' module:
* bandwidth-profile-type;
* link-metric-delay-variation;
* link-metric-loss;
* path-metric-delay-variation;
Busi, et al. Expires 22 August 2026 [Page 157]
Internet-Draft TE Common YANG Types February 2026
* path-metric-loss.
The following new groupings have been added to the 'ietf-te-packet-
types' module:
* te-packet-path-bandwidth;
* te-packet-link-bandwidth.
The following identities, already defined in [RFC8776], have been
updated in the 'ietf-te-types' module:
* objective-function-type (editorial);
* action-exercise (bug fix);
* path-metric-type:
new base identities have been added;
* path-metric-te (bug fix);
* path-metric-igp (bug fix);
* path-metric-hop (bug fix);
* path-metric-delay-average (bug fix);
* path-metric-delay-minimum (bug fix);
* path-metric-residual-bandwidth (bug fix);
* path-metric-optimize-includes (bug fix);
* path-metric-optimize-excludes (bug fix);
* te-optimization-criterion (editorial).
The following data type, already defined in [RFC8776], has been
updated in the 'ietf-te-types' module:
* te-node-id;
The data type has been changed to be a union.
The following groupings, already defined in [RFC8776], have been
updated in the 'ietf-te-types' module:
Busi, et al. Expires 22 August 2026 [Page 158]
Internet-Draft TE Common YANG Types February 2026
* explicit-route-hop
The following new leaves have been added to the 'explicit-route-
hop' grouping:
- node-id-uri;
- link-tp-id-uri;
The following leaves, already defined in [RFC8776], have been
updated in the 'explicit-route-hop':
- node-id;
- link-tp-id.
The "mandatory true" statements for the node-id and link-tp-id have
been replaced by "must" statements that requires at least the
presence of:
* node-id or node-id-uri;
* link-tp-id or link-tp-id-uri.
* explicit-route-hop
The following new leaves have been added to the 'explicit-route-
hop' grouping:
- node-id-uri;
- link-tp-id-uri;
The following leaves, already defined in [RFC8776], have been
updated in the 'explicit-route-hop':
- node-id;
- link-tp-id.
The "mandatory true" statements for the node-id and link-tp-id have
been replaced by "must" statements that requires at least the
presence of:
* node-id or node-id-uri;
* link-tp-id or link-tp-id-uri.
Busi, et al. Expires 22 August 2026 [Page 159]
Internet-Draft TE Common YANG Types February 2026
* optimization-metric-entry:
The following leaves, already defined in [RFC8776], have been
updated in the 'optimization-metric-entry':
- metric-type;
The base identity has been updated without impacting the set of
derived identities that are allowed.
* tunnel-constraints;
The following new leaf has been added to the 'tunnel-constraints'
grouping:
- network-id;
* path-constraints-route-objects:
The following container, already defined in [RFC8776], has been
updated in the 'path-constraints-route-objects':
- explicit-route-objects-always;
The container has been renamed as 'explicit-route-objects'.
This change is not affecting any IETF standard YANG data models
since this grouping has not yet been used by any YANG data
model defined in existing IETF RFCs.
* generic-path-metric-bounds:
The following leaves, already defined in [RFC8776], have been
updated in the 'optimization-metric-entry':
- metric-type;
The base identity has been updated to:
o increase the set of derived identities that are allowed and;
o remove from this set the 'path-metric-optimize-includes' and
the 'path-metric-optimize-excludes' identities (bug fixing)
* generic-path-optimization
The following new leaf has been added to the 'generic-path-
optimization' grouping:
Busi, et al. Expires 22 August 2026 [Page 160]
Internet-Draft TE Common YANG Types February 2026
- tiebreaker;
The following container, already defined in [RFC8776], has been
deprecated:
- tiebreakers.
The following identities, already defined in [RFC8776], have been
obsoleted in the 'ietf-te-types' module for bug fixing:
* of-minimize-agg-bandwidth-consumption (the 'svec-of-minimize-agg-
bandwidth-consumption' identity should be used instead);
* of-minimize-load-most-loaded-link (the 'svec-of-minimize-load-
most-loaded-link' identity should be used instead);
* of-minimize-cost-path-set (the 'svec-of-minimize-cost-path-set'
identity should be used instead);
* lsp-protection-reroute-extra (the 'restoration-scheme-rerouting'
identity should be used instead);
* lsp-protection-reroute (the 'restoration-scheme-rerouting'
identity should be used instead).
Acknowledgements
The authors would like to thank Robert Wilton, Lou Berger, Mahesh
Jethanandani and Jeff Haas for their valuable input to the discussion
about the process to follow to provide tiny updates to a YANG module
already published as an RFC.
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.
Contributors
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Rakesh Gandhi
Cisco Systems, Inc.
Email: rgandhi@cisco.com
Busi, et al. Expires 22 August 2026 [Page 161]
Internet-Draft TE Common YANG Types February 2026
Authors' Addresses
Italo Busi
Huawei
Email: italo.busi@huawei.com
Aihua Guo
Futurewei Technologies
Email: aihuaguo.ietf@gmail.com
Xufeng Liu
Alef Edge
Email: xufeng.liu.ietf@gmail.com
Tarek Saad
Cisco Systems Inc.
Email: tsaad.net@gmail.com
Igor Bryskin
Individual
Email: i_bryskin@yahoo.com
Busi, et al. Expires 22 August 2026 [Page 162]