A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths, and Interfaces

A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths, and Interfaces Cisco Systems Inc

tsaad.net@gmail.com

Cisco Systems Inc

rgandhi@cisco.com

Alef Edge

xufeng.liu.ietf@gmail.com

Juniper Networks

vbeeram@juniper.net

Individual

i_bryskin@yahoo.com

TEAS Working Group Internet-Draft This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications.

Introduction This document defines a YANG data model intended for the provisioning and management of point-to-point Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The modeling of point-to-multipoint TE Tunnels and Segment-Routing (SR) Policies falls outside the scope of this document. The data model described herein is divided into two YANG modules. The 'ietf-te' module contains generic, device-independent data, and the 'ietf-te-device' module addresses device-specific data. This document outlines the high-level relationships between the YANG modules it defines and other external protocol YANG modules. The TE data model intentionally excludes data specific to any signaling protocol, such as RSVP-TE (, ), or Segment-Routing (, ) with the expectation that such technology models will be defined in separate documents and will augment the TE model as needed.

Terms and Conventions

Terminology The following terms are defined in and are used in this specification: client configuration data state data This document also makes use of the following terminology introduced in the YANG Data Modeling Language : augment data model data node

Prefixes in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in . Prefix YANG module Reference yang ietf-yang-types inet ietf-inet-types rt-types ietf-routing-types te-types ietf-te-types te-packet-types ietf-te-packet-types te ietf-te this document te-dev ietf-te-device this document

Model Tree Diagrams The YANG tree diagrams extracted from the modules defined in this document are given in subsequent sections as per the syntax defined in .

Design Considerations This document describes a TE data model that is independent of any dataplane technology. One of the design objectives is to allow specific data plane technology models to reuse the TE data model and possibly augment it with technology-specific data. The elements of the TE data model, including TE Tunnels, LSPs, and interfaces have leafs that identify the technology layer where they reside. For example, the LSP encoding type can identify the technology associated with a TE Tunnel or LSP. Also, the TE data model does not cover signaling protocol data. The signaling protocols used to instantiate TE LSPs are outside the scope of this document and expected to be covered by augmentations defined in other documents. The following other design considerations are taken into account with respect to data organization: The device independent TE data is defined in the 'ietf-te' module, and can be used to manage data off a device, such as a TE controller. When the model is used to manage a specific device, the model contains the TE Tunnels originating from the specific device. When the model is used to manage a TE controller, the 'tunnel' list contains all TE Tunnels and TE tunnel segments originating from devices that the TE controller manages. The device-specific TE data is defined in the 'ietf-te-device' module. The TE interfaces in the 'ietf-te-device' module are modeled as references to existing interfaces defined in the 'ietf-interfaces' YANG module . This approach ensures consistency by leveraging standardized interface definitions, allowing TE-specific parameters to be associated with interfaces already defined elsewhere, rather than redefining interface structures within the TE module." Minimal elements in the model are designated as "mandatory" to allow freedom to vendors to adapt the data model to their specific product implementation. Suitable defaults are specified for all configurable elements. Where TE functions or features might be optional within the deployed TE network, the model declares them as optional. Some groupings defined in this document include "default" statements, which do not conform to the guidelines specified in Section 4.13 of . This deviation is intentional because these groupings are specifically tailored for use within the YANG modules defined in this document as well as in . The customization ensures appropriate behavior and consistency across these related modules.

Model Overview The data model defined in this document cover the core TE features that are commonly supported by different vendor implementations. The support of extended or vendor specific TE features is expected to either be in augmentations, or deviations to this model that are defined in separate documents.

Module Relationship The TE YANG module 'ietf-te' provides device-independent building blocks that are agnostic of specific technologies or control plane instances. The TE device YANG module, defined in the 'ietf-te-device', augments the 'ietf-te' YANG module as illustrated in by including device-specific data such as TE interface attributes and local TE node timers. The augmentation of the TE data model for specific instances of data plane technology and signaling protocols are outside the scope of this document.

TE YANG Module The TE YANG module 'ietf-te' supports the management and operation of a TE network. This includes creating, modifying, and retrieving information about TE Tunnels, LSPs, and interfaces and their associated attributes (e.g. Administrative-Groups (AGs), Shared Risk Link Groups (SRLGs), etc.). A full tree diagram of the TE data model is shown in .

Relationship Between TE Tunnel, LSP, and Path The TE model is built around several core constructs: TE tunnel, TE path, and LSP. These concepts are central to the model's structure and functionality. TE Tunnel:

In this context, a TE tunnel represents a logical construct that defines an engineered connectivity service between two endpoints in the network, typically an ingress (source) and an egress (destination). A tunnel is characterized by its attributes (such as name, encoding, and constraints) and serves as the container for the forwarding resources used to realize the desired connectivity.

TE Path:

A path refers to a specific sequence of nodes and links through the network that traffic will follow to traverse the TE tunnel from source to destination. A TE tunnel may have one or more associated TE paths, such as a primary TE path (the preferred path) and secondary TE paths (used for protection or restoration). Each path specifies the constraints, preferences, and optimization criteria that guide its computation and selection.

LSP:

An LSP is an actual, instantiated connection in the data plane that follows a computed TE path through the network. It is the result of signaling protocols (such as RSVP-TE or Segment Routing) setting up forwarding state along the TE path, enabling the tunnel to carry traffic.

The relationship among these concepts is as follows: A TE tunnel is the high-level logical object that defines the desired connectivity and its properties. Each TE tunnel can have one or more TE paths, which define candidate or active routes through the network that may be used to realize the tunnel's connectivity, subject to certain constraints and preferences. For each TE path selected for use, one or more LSPs are instantiated in the network to realize the forwarding state necessary to carry traffic along the specified TE path. In summary, a TE tunnel defines the service, a TE path defines how to achieve the service, and an LSP is the instantiated mechanism that actually provides the service in the forwarding plane.

Module Structure The 'te' container is the top level container in the 'ietf-te' module. The presence of the 'te' container enables TE function system-wide. Further descriptions of containers that exist under the 'te' top level container are provided in the following sections. The three containers grouped under the 'te' container are shown in and described below. globals:

The 'globals' container maintains the set of global TE attributes that can be applicable to TE Tunnels and interfaces. Refer to for further details.

tunnels:

The 'tunnels' container includes the list of TE Tunnels that are instantiated. Refer to for further details on the properties of a TE Tunnel.

lsps:

The 'lsps' container includes the list of TE LSPs that are instantiated for TE Tunnels. Refer to for further details on the properties of a TE LSP.

The model also contains two Remote Procedure Calls (RPCs) as shown in and described below. tunnels-path-compute:

An RPC to request path computation for a specific TE Tunnel. The RPC allows requesting path computation using atomic and stateless operation. A tunnel may also be configured in 'compute-only' mode to provide stateful path updates - see for further details.

tunnels-action:

An RPC to request a specific action (e.g. reoptimize, or tear-and-setup) to be taken on a specific tunnel or all tunnels.

TE Globals The 'globals' container covers properties that control a TE feature's behavior system-wide, and its respective state as shown in and described in the text that follows.

named-admin-groups:

A YANG container for the list of named (extended) administrative groups that may be applied to TE links.

named-srlgs:

A YANG container for the list of named SRLGs that may be applied to TE links.

named-path-constraints:

A YANG container for a list of named path constraints. Each named path constraint is composed of a set of constraints that can be applied during path computation. A named path constraint can be applied to multiple TE Tunnels. Path constraints may also be specified directly under the TE Tunnel. The path constraints specified under the TE Tunnel take precedence over the path constraints derived from the referenced named path constraint. A named path constraint entry can be formed of the path constraints shown in :

name: A YANG leaf that holds the named path constraint entry. This is unique in the list and used as a key. te-bandwidth: A YANG container that holds the technology-agnostic TE bandwidth constraint. link-protection: A YANG leaf that holds the link protection type constraint required for the links to be included in the computed path. setup/hold priority: YANG leafs that hold the LSP setup and hold admission priority as defined in . signaling-type: A YANG leaf that holds the LSP setup type, such as RSVP-TE or SR. path-metric-bounds: A YANG container that holds the set of metric bounds applicable on the computed TE tunnel path. path-affinities-values: A YANG container that holds the set of affinity values and mask to be used during path computation. path-affinity-names: A YANG container that holds the set of named affinity constraints and corresponding inclusion or exclusion instructions for each to be used during path computation. path-srlgs-lists: A YANG container that holds the set of SRLG values and corresponding inclusion or exclusion instructions to be used during path computation. path-srlgs-names: A YANG container that holds the set of named SRLG constraints and corresponding inclusion or exclusion instructions for each to be used during path computation. disjointness: The level of resource disjointness constraint that the secondary path of a TE tunnel has to adhere to. explicit-route-objects: A YANG container that holds path constraints in the form of route entries present in the following two lists: 'route-object-exclude-always': a list of route entries that are always excluded from the path computation. The exclusion of a route entry in this list during path computation is not order sensitive. The route entries in this list have a 'strict' hop-type as described in section 3.1. 'route-object-include-exclude': a list of route entries to include or exclude for the path computation. For route entries in this list that are to be excluded, the hop-type is only allowed to be 'strict' as described in section 3.1.
The constraint type (include or exclude) is specified with each route entry. The path computation considers route entry constraints in the order they appear in this list. Once a route entry constraint is consumed from this list, it is not considered any further in the computation of the TE path.
The 'route-object-include-exclude' is used to configure constraints on which route objects (e.g., nodes, links) are included or excluded in the path computation.
The interpretation of an empty 'route-object-include-exclude' list depends on the TE Tunnel (end-to-end or Tunnel Segment) and on the specific path, according to the following rules:
An empty 'route-object-include-exclude' list for the primary path of an end-to-end TE Tunnel indicates that there are no route objects to be included or excluded in the path computation. An empty 'route-object-include-exclude' list for the primary path of a TE Tunnel Segment indicates that no primary LSP is required for that TE Tunnel Segment. An empty 'route-object-include-exclude' list for a reverse path means it always follows the forward path (i.e., the TE Tunnel is co-routed). When the 'route-object-include-exclude' list is not empty, the reverse path is routed independently of the forward path. An empty 'route-object-include-exclude' list for the secondary (forward) path of a TE Tunnel segment indicates that the secondary path has the same endpoints as the primary path. path-in-segment: A YANG container that contains a list of label restrictions that have to be taken into consideration when stitching to another tunnel segment such as at a domain boundary. The TE tunnel segment in this case is being stitched to the upstream TE tunnel segment. path-out-segment: A YANG container that contains a list of label restrictions that have to be taken into consideration when stitching to another tunnel segment such as at a domain boundary. The TE tunnel segment in this case is being stitched to the downstream TE tunnel segment.

TE Tunnels The 'tunnels' container holds the list of TE Tunnels that are provisioned on ingress router devices in the network as shown in .

When the TE model is used to manage a specific device, the 'tunnel' list contains the TE Tunnels originating from the specific device. When the model is used to manage a TE controller, the 'tunnel' list contains all TE Tunnels and TE tunnel segments originating from devices that the TE controller manages. The TE Tunnel model allows the configuration and management of the following TE tunnel objects: TE Tunnel:

A YANG container of one or more TE LSPs established between the source and destination TE Tunnel termination points.

TE Path:

An engineered path that once instantiated in the forwarding plane can be used to forward traffic from the source to the destination TE Tunnel termination points.

TE LSP:

A TE LSP is a connection-oriented service established over a TE Path and that allows the delivery of traffic between the TE Tunnel source and destination termination points.

TE Tunnel Segment:

A segment of a TE Tunnel that is stitched with other segments in order to provision an end-to-end tunnel.

The TE Tunnel has a number of attributes that are set directly under the tunnel (as shown in ). The main attributes of a TE Tunnel are described below: name:

A YANG leaf that holds the name of a TE Tunnel. The name of the TE Tunnel uniquely identifies the tunnel within the TE tunnel list. The name of the TE Tunnel can be formatted as a Uniform Resource Indicator (URI) by including the namespace to ensure uniqueness of the name among all the TE Tunnels present on devices and controllers. The configured TE Tunnels can be reported with the name of the device embedded within the TE Tunnel name. For TE Tunnels initiated by the controller, the controller is responsible to ensure that TE Tunnel names are unique.

alias:

A YANG leaf that holds a user-friendly alternate name to the TE tunnel, which is typically, but not necessarily, unique. Unlike the TE tunnel name, the alias can be modified at any time during the lifetime of the TE tunnel.

identifier:

A YANG leaf that holds an identifier of the tunnel. This identifier is unique among tunnels originated from the same ingress device.

color:

A YANG leaf that holds the color associated with the TE tunnel. The color is used to map or steer services that carry matching color onto the TE tunnel as described in .

admin-state:

A YANG leaf that holds the tunnel administrative state.

operational-state:

A YANG leaf that holds the tunnel operational state.

encoding/switching:

The 'encoding' and 'switching-type' are YANG leafs that define the specific technology in which the tunnel operates in as described in .

source/destination:

YANG containers that hold the tunnel source and destination node endpoint identities, including:

te-node-id: A YANG leaf that holds the TE node identifier (as defined in ) of the source or destination of the TE Tunnel. node-id: A YANG leaf that holds the node identifier (as defined in ) of the source or destination of the TE Tunnel. tunnel-tp-id: A YANG leaf that holds the identifier of the source or destination of the TE Tunnel Termination Points (TTPs) as defined in . The TTP identifiers are optional on nodes that have a single TTP per node. For example, TTP identifiers are optional for packet (IP/MPLS) routers.

bidirectional:

A YANG leaf that when present indicates the LSP of a TE Tunnel is bidirectional as defined in .

controller:

A YANG container that holds tunnel data relevant to an optional external TE controller that may initiate or control a tunnel. This target node may be augmented by external modules, for example, to add data for Path Computation Element Protocol (PCEP) initiated and/or delegated tunnels.

reoptimize-timer:

A YANG leaf to set the interval period for tunnel reoptimization.

association-objects:

A YANG container that holds the set of associations of the TE Tunnel to other TE Tunnels. Associations at the TE Tunnel level apply to all paths of the TE Tunnel. The TE tunnel associations can be overridden by associations configured directly under the TE Tunnel path.

protection:

A YANG container that holds the TE Tunnel protection properties.

restoration:

A YANG container that holds the TE Tunnel restoration properties.

te-topology-identifier:

A YANG container that holds the topology identifier associated with the topology where paths for the TE tunnel are computed as defined in .

network-id:

A YANG leaf that can optionally be used to identify the network topology where paths for the TE tunnel are computed as defined in .

hierarchy:

A YANG container that holds hierarchy related properties of the TE Tunnel. A TE LSP can be set up in MPLS or Generalized MPLS (GMPLS) networks to be used as a TE link to carry traffic in other (client) networks . In this case, the model introduces the TE Tunnel hierarchical link endpoint parameters to identify the specific link in the client layer that the underlying TE Tunnel is associated with. The hierarchy container includes the following:

dependency-tunnels: A hierarchical set of TE Tunnels either provisioned or to be provisioned in the immediate lower layer, upon which the current TE Tunnel relies for multi-layer path computation. A dependency TE Tunnel is provisioned if it has been selected by path computation to support at least one client-layer TE Tunnel. When a dependency TE Tunnel is provisioned, it makes the TE link operational in the client layer's network topology, enabling the provisioning of TE Tunnels in the client layer.

hierarchical-link: A YANG container that holds the identity of the hierarchical link (in the client layer) that is supported by this TE Tunnel. The endpoints of the hierarchical link are defined by TE tunnel source and destination node endpoints. The hierarchical link can be identified by its source and destination link termination point identifiers.

primary-paths:

A YANG container that holds the list of primary paths. A primary path is identified by 'name'. A primary path is selected from the list to instantiate a primary forwarding LSP for the tunnel. The list of primary paths is visited by order of preference. A primary path has the following attributes:

primary-reverse-path: A YANG container that holds properties of the primary reverse path. The reverse path is applicable to bidirectional TE Tunnels.

candidate-secondary-paths: A YANG container that holds a list of candidate secondary paths which may be used for the primary path to support path protection. The candidate secondary paths reference paths from the tunnel secondary paths list. The preference of the secondary paths is specified within the list and dictates the order of visiting the secondary path from the list. The attributes of a secondary path can be defined separately from the primary path. The attributes of a secondary path will be inherited from the associated 'active' primary when not explicitly defined for the secondary path.

secondary-paths:

A YANG container that holds the set of secondary paths. A secondary path is identified by 'name'. A secondary path can be referenced from the TE Tunnel's 'candidate-secondary-path' list.

secondary-reverse-paths:

A YANG container that holds the set of secondary reverse paths. A secondary reverse path is identified by 'name'. A secondary reverse path can be referenced from the TE Tunnel's 'candidate-secondary-reverse-paths' list. A secondary reverse path is modeled with the same data attributes as those of the primary path.

The following set of common path attributes are shared for primary (forward and reverse) and secondary paths: path-computation-method:

A YANG leaf that specifies the method used for computing the TE path.

path-computation-server:

A YANG container that holds the path computation server properties when the path is externally queried.

compute-only:

A path of a TE Tunnel is, by default, provisioned so that it can be instantiated in the forwarding plane so that it can carry traffic. In some cases, a TE path may be configured only for the purpose of computing a path and reporting it without the need to instantiate the LSP or commit any resources. In such a case, the path is configured in 'compute-only' mode to distinguish it from the default behavior. A 'compute-only' path is configured as usual with the associated per-path constraints and properties on a device or TE controller. The device or TE controller computes the feasible paths subject to configured constraints. A client may query the 'compute-only' computed path properties 'on-demand', or alternatively, can subscribe to be notified of computed paths and whenever the path properties change.

use-path-computation:

A YANG leaf that indicates whether or not path computation is to be used for a specified path.

lockdown:

A YANG leaf that when set indicates the existing path should not be globally repaired or reoptimized.

path-scope:

A YANG leaf that specifies whether the path is a segment or an end-to-end path.

preference:

A YANG leaf that specifies the preference for the path, used to choose between paths in a list. The lower the number, the higher the preference. Paths with the same preference are treated as equal and other methods are used to choose between them.

k-requested-paths:

A YANG leaf that specifies the number of k-shortest paths requested from the path computation server, which are returned in order based on their computed optimization objective costs.

association-objects:

A YANG container that holds a list of tunnel association properties.

optimizations:

A YANG container that holds the optimization objectives that path computation will use to select a path.

named-path-constraint:

A YANG leafref that references an entry from the global list of named path constraints.

te-bandwidth:

A YANG container that holds the path bandwidth (see ).

link-protection:

A YANG leaf that specifies the link protection type required for the links to be included in the computed path (see ).

setup/hold-priority:

see description provided in . These values override those provided in the referenced named-path-constraint.

signaling-type:

see description provided in . This value overrides the provided one in the referenced named-path-constraint.

path-metric-bounds:

see description provided in . These values override those provided in the referenced named-path-constraint.

path-affinities-values:

see description provided in . These values override those provided in the referenced named-path-constraint.

path-affinity-names:

see description provided in . These values override those provided in the referenced named-path-constraint.

path-srlgs-lists:

see description provided in . These values override those provided in the referenced named-path-constraint.

path-srlgs-names:

see description provided in . These values override those provided in the referenced named-path-constraint.

disjointness:

see description provided in . These values override those provided in the referenced named-path-constraint.

explicit-route-objects:

see description provided in . These values override those provided in the referenced named-path-constraint.

path-in-segment:

see description provided in . These values override those provided in the referenced named-path-constraint.

path-out-segment:

see description provided in . These values override those provided in the referenced named-path-constraint.

computed-paths-properties:

A YANG container that holds properties for the list of computed paths.

computed-path-error-infos:

A YANG container that holds the list of path computation error information. The TE system populates entries in this list whenever an error is encountered during the computation of the TE path.

path-compute-info:

A YANG grouping that contains leafs representing the path attributes that are passed to the TE path computation engine to be considered during the path computation. This includes: path constraints, path optimization objectives, and path associations Note, unless overridden under a specific path of the TE tunnel, the TE tunnel's primary path constraints, optimization objectives, and associations are inherited by the primary reverse path, secondary path and secondary reverse path.

lsps:

A YANG container that holds a list of LSPs that have been instantiated for this specific path.

In addition to the path common attributes, the primary path has the following attributes that are not present in the secondary path: Only the primary path contains the list of 'candidate-secondary-paths' that can protect the primary path. Only the primary path can contain a primary-reverse-path associated with the primary path (and its associated list of 'candidate-secondary-reverse-path'). lsp-provisioning-error-infos:

A YANG container that holds the list of LSP provisioning error information. The TE system populates entries in this list whenever an error is encountered during the LSP provisioning.

TE LSPs The 'lsps' container includes the set of TE LSPs that have been instantiated. A TE LSP is identified by a 3-tuple ('tunnel-name', 'lsp-id', 'node'). When the model is used to manage a specific device, the 'lsps' list contains all TE LSPs that traverse the device (including ingressing, transiting and egressing the device). When the model is used to manage a TE controller, the 'lsps' list contains the TE LSPs on devices managed by the controller that act as ingress, and may optionally include TE LSPs on devices managed by the controller that act as transit or egress role.

Tree Diagram shows the YANG tree diagram of depth=4 for the TE YANG module 'ietf-te'. The full tree diagram is shown in .

YANG Module The TE YANG module 'ietf-te' imports the following modules: ietf-te-types defined in ietf-yang-types and ietf-inet-types defined in ietf-network and ietf-network-topology defined in This module references the following documents: , , , , , , , , , , , , , , , , and .

file "ietf-te@2026-02-28.yang" yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-te"; prefix te; /* Import TE generic types */ import ietf-te-types { prefix te-types; reference "draft-ietf-teas-rfc8776-update: Common YANG Data Types for Traffic Engineering."; } import ietf-yang-types { prefix yang; reference "RFC 9911: Common YANG Data Types."; } 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: WG List: Editor: Tarek Saad Editor: Rakesh Gandhi Editor: Vishnu Pavan Beeram Editor: Xufeng Liu Editor: Igor Bryskin "; description "YANG data module for TE configuration, state, and RPCs. Copyright (c) 2025 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."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2026-02-28 { description "Initial revision for the TE generic YANG module."; reference "RFCXXXX: A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths, and Interfaces."; } typedef tunnel-ref { type leafref { path "/te:te/te:tunnels/te:tunnel/te:name"; require-instance false; } description "This type is used by data models that need to reference a configured TE tunnel."; } /** * TE tunnel generic groupings */ grouping path-common-properties { description "Common path attributes."; leaf name { type string; description "TE path name."; } leaf symbolic-name { type string; description "The symbolic path name is a human-readable string that identifies an LSP in the network. The symbolic path name must remain constant throughout an LSP's lifetime."; reference "RFC 8231: Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE, Section 7.3.2"; } leaf path-computation-method { type identityref { base te-types:path-computation-method; } default "te-types:path-locally-computed"; description "The method used for computing the path, either locally computed, queried from a server or not computed at all (explicitly configured)."; } container path-computation-server { when "derived-from-or-self(../path-computation-method, " + "'te-types:path-externally-queried')" { description "The IP address or the TE identifier of the external path computation server."; } uses te-types:te-generic-node-id; description "Address of the external path computation server."; } leaf compute-only { when "../use-path-computation = 'true'" { description "Applicable when path computation is requested."; } type empty; description "When present, the path is computed, but no resources are committed or reserved in the network. The path may be recomputed upon topology changes."; } leaf use-path-computation { when "derived-from-or-self(../path-computation-method, " + "'te-types:path-locally-computed')"; type boolean; default "true"; description "When 'true' indicates the path is dynamically computed and/or validated against the Traffic-Engineering Database (TED), and when 'false' indicates no path expansion or validation against the TED is required."; } leaf lockdown { type empty; description "When present, indicates the existing path should not be globally repaired or reoptimized."; } leaf path-scope { type identityref { base te-types:path-scope-type; } default "te-types:path-scope-end-to-end"; config false; description "Indicates whether the path is a segment or portion of the full path, or is an end-to-end path for the TE Tunnel."; } } grouping path-compute-info { description "Attributes used for path computation request."; uses tunnel-associations-properties; uses te-types:generic-path-optimization; leaf named-path-constraint { if-feature "te-types:named-path-constraints"; type leafref { path "/te:te/te:globals/te:named-path-constraints/" + "te:named-path-constraint/te:name"; } description "Reference to a globally defined named path constraint set."; } uses path-constraints-common; } grouping path-forward-properties { description "The path preference."; leaf preference { type uint8 { range "1..255"; } default "1"; description "Specifies a preference for this path. The lower the number higher the preference."; } leaf co-routed { when "/te:te/te:tunnels/te:tunnel/te:bidirectional = 'true'" { description "Applicable to bidirectional tunnels only."; } type boolean; default "false"; description "When set to true, indicates whether the reverse path must be co-routed with the primary."; } } grouping k-requested-paths { description "The k-shortest paths requests."; leaf k-requested-paths { type uint8; default "1"; description "The number of k-shortest paths requested from the path computation server, which are returned in order based on their computed optimization objective costs."; } } grouping path-state { description "TE per path state parameters."; uses path-computation-response; container lsp-provisioning-error-infos { config false; description "LSP provisioning error information."; list lsp-provisioning-error-info { description "List of LSP provisioning error info entries."; leaf error-reason { type identityref { base te-types:lsp-provisioning-error-reason; } description "LSP provision error type."; } leaf error-description { type string; description "The textual representation of the error that occurred during LSP provisioning."; } leaf error-timestamp { type yang:date-and-time; description "Timestamp of when the reported error occurred."; } leaf error-node-id { type te-types:te-node-id; description "Node identifier of node where error occurred."; } leaf error-link-id { type te-types:te-tp-id; description "Link ID where the error occurred."; } leaf lsp-id { type uint16; description "The LSP-ID for which LSP provisioning error was returned."; } } } container lsps { config false; description "The TE LSPs container."; list lsp { key "node lsp-id"; description "List of LSPs associated with the tunnel."; leaf tunnel-name { type leafref { path "/te:te/te:lsps/te:lsp/te:tunnel-name"; } description "TE tunnel name."; } leaf node { type leafref { path "/te:te/te:lsps/te:lsp[tunnel-name=" + "current()/../te:tunnel-name][lsp-id=" + "current()/../te:lsp-id]/te:node"; } description "The node where the LSP state resides."; } leaf lsp-id { type leafref { path "/te:te/te:lsps/te:lsp[tunnel-name=" + "current()/../tunnel-name]/te:lsp-id"; } description "The TE LSP identifier."; } leaf state-change-timestamp { type yang:date-and-time; description "Indicates the time at which the LSP operational state was last updated."; } } } } grouping path-computation-response { description "Attributes reported by path computation response."; container computed-paths-properties { config false; description "Computed path properties container."; list computed-path-properties { key "k-index"; description "List of computed paths."; leaf k-index { type uint8; description "The k-th path returned from the computation server. A lower k value path is more optimal than higher k value paths"; } uses te-types:generic-path-properties { augment "path-properties" { description "additional path properties returned by path computation."; uses te-types:te-bandwidth; leaf disjointness-type { type te-types:te-path-disjointness; description "The type of resource disjointness. When reported for a primary path, it represents the minimum level of disjointness of all the secondary paths. When reported for a secondary path, it represents the disjointness of the secondary path."; } leaf last-computed-timestamp { type yang:date-and-time; description "Timestamp of when the path was last computed."; } } } } } container computed-path-error-infos { config false; description "Path computation information container."; list computed-path-error-info { description "List of path computation info entries."; leaf error-description { type string; description "Textual representation of the error that occurred during path computation."; } leaf error-timestamp { type yang:date-and-time; description "Timestamp of last path computation attempt."; } leaf error-reason { type identityref { base te-types:path-computation-error-reason; } description "Reason for the path computation error."; } } } } grouping protection-restoration-properties { description "Protection and restoration parameters."; container protection { description "Protection parameters."; leaf protection-type { type identityref { base te-types:lsp-protection-type; } default "te-types:lsp-protection-unprotected"; description "LSP protection type."; } leaf protection-reversion-disable { type boolean; default "false"; description "Disable protection reversion to working path."; } leaf hold-off-time { type uint32; units "milliseconds"; description "The time interval from the declaration of a Signal Fail (SF) or Signal Degrade (SD) condition until the protect- ion switching algorithm is initiated to maintain service continuity."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)."; } leaf wait-to-revert { type uint16; units "seconds"; description "Time to wait before attempting LSP reversion."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)."; } leaf aps-signal-id { type uint8 { range "1..255"; } default "1"; description "The Automatic Protection Switching (APS) signal number used to reference the traffic of this tunnel. The default value for normal traffic is 1. The default value for extra-traffic is 255. If not specified, non-default values can be assigned by the server, if and only if, the server controls both endpoints."; reference "ITU_G.808.1: Generic protection switching - Linear trail and subnetwork protection."; } } container restoration { description "Restoration parameters."; leaf restoration-type { type identityref { base te-types:lsp-restoration-type; } description "LSP restoration type."; } leaf restoration-scheme { type identityref { base te-types:restoration-scheme-type; } description "LSP restoration scheme."; } leaf restoration-reversion-disable { type boolean; default "false"; description "When 'true', disables restoration reversion to the working path."; } leaf hold-off-time { type uint32; units "milliseconds"; description "The time interval from the declaration of a Signal Fail (SF) or Signal Degrade (SD) condition until the protect- ion switching algorithm is initiated to maintain service continuity."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)."; } leaf wait-to-restore { type uint16; units "seconds"; description "Time to wait before attempting LSP restoration."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)."; } leaf wait-to-revert { type uint16; units "seconds"; description "Time to wait before attempting LSP reversion."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)."; } } } grouping tunnel-associations-properties { description "TE tunnel association grouping."; container association-objects { description "TE tunnel associations."; list association-object { key "association-key"; unique "type id source/id source/type"; description "List of association base objects."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery."; leaf association-key { type string; description "Association key used to identify a specific association in the list"; } leaf type { type identityref { base te-types:association-type; } description "Association type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery."; } leaf id { type uint16; description "Association identifier."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery."; } container source { uses te-types:te-generic-node-id; description "Association source."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery."; } } list association-object-extended { key "association-key"; unique "type id source/id source/type global-source extended-id"; description "List of extended association objects."; reference "RFC 6780: RSVP ASSOCIATION Object Extensions"; leaf association-key { type string; description "Association key used to identify a specific association in the list"; } leaf type { type identityref { base te-types:association-type; } description "Association type."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) RFC 6780: RSVP ASSOCIATION Object Extensions"; } leaf id { type uint16; description "Association identifier."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) RFC 6780: RSVP ASSOCIATION Object Extensions"; } container source { uses te-types:te-generic-node-id; description "Association source."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) RFC 6780: RSVP ASSOCIATION Object Extensions"; } leaf global-source { type uint32; description "Association global source."; reference "RFC 6780: RSVP ASSOCIATION Object Extensions"; } leaf extended-id { type yang:hex-string; description "Association extended identifier."; reference "RFC 6780: RSVP ASSOCIATION Object Extensions"; } } } } grouping tunnel-end-point { description "Common grouping used to specify the tunnel source and destination end-points."; leaf node-id { type nw:node-id; description "The TE tunnel end-point node identifier"; } leaf te-node-id { type te-types:te-node-id; description "The TE tunnel end-point TE node identifier"; } leaf tunnel-tp-id { when "../node-id or ../te-node-id" { description "The TE tunnel termination point identifier is local to a node"; } type binary; description "The TE tunnel end-point TE tunnel termination point identifier"; } } /* Some of the groupings defined in this module are re-used * in path-computation YANG model * defined in [I-D.ietf-teas-yang-path-computation] */ grouping tunnel-common-attributes { description "Common grouping to define the TE tunnel parameters"; container source { description "TE tunnel source end-point."; uses tunnel-end-point; } container destination { description "TE tunnel destination end-point."; uses tunnel-end-point; } leaf bidirectional { type boolean; default "false"; description "When 'true', it indicates a bidirectional tunnel"; } } /* This grouping is re-used in path-computation YANG * model defined in [I-D.ietf-teas-yang-path-computation] */ grouping tunnel-hierarchy-properties { description "A grouping for TE tunnel hierarchy information."; container hierarchy { description "Container for TE hierarchy related information."; container dependency-tunnels { description "List of tunnels that this tunnel can be potentially dependent on."; list dependency-tunnel { key "name"; description "A tunnel entry that this tunnel can potentially depend on."; leaf name { type tunnel-ref; description "Dependency tunnel name. The tunnel may not have been instantiated yet."; } uses te-types:encoding-and-switching-type; } } container hierarchical-link { description "Identifies a hierarchical link (in client layer) that this tunnel is associated with. By default, the topology of the hierarchical link is the same topology of the tunnel;"; reference "RFC 4206: Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"; leaf enable { type boolean; default "false"; description "When 'true', enables the hierarchical link properties supported by this tunnel"; } leaf local-node-id { type nw:node-id; description "The local node identifier."; } leaf local-te-node-id { type te-types:te-node-id; description "The local TE node identifier."; } leaf local-link-tp-id { type nt:tp-id; description "The local link termination point identifier."; reference "RFC 8345: A YANG Data Model for Network Topologies"; } leaf local-te-link-tp-id { type te-types:te-tp-id; description "The local TE link termination point identifier."; } leaf remote-node-id { type nw:node-id; description "The remote node identifier."; } leaf remote-link-tp-id { type nt:tp-id; description "The remote link termination point identifier."; reference "RFC 8345: A YANG Data Model for Network Topologies"; } leaf remote-te-link-tp-id { type te-types:te-tp-id; description "The remote TE link termination point identifier."; } leaf remote-te-node-id { type te-types:te-node-id; description "Remote TE node identifier."; } leaf link-id { type nt:link-id; description "A network topology assigned identifier to the link"; reference "RFC 8345: A YANG Data Model for Network Topologies"; } leaf network-id { type nw:network-id; description "The network topology identifier where the hierarchical link supported by this TE tunnel is instantiated."; } uses te-types:te-topology-identifier { description "The TE topology identifier where the hierarchical link supported by this TE tunnel is instantiated."; } } } } grouping path-constraints-common { description "Global named path constraints configuration grouping."; uses te-types:common-path-constraints-attributes; uses te-types:generic-path-disjointness; uses te-types:path-constraints-route-objects; container path-in-segment { presence "The end-to-end tunnel starts in a previous domain; this tunnel is a segment in the current domain."; description "If an end-to-end tunnel crosses multiple domains using the same technology, some additional constraints have to be taken in consideration in each domain. This TE tunnel segment is stitched to the upstream TE tunnel segment."; uses te-types:label-set-info; } container path-out-segment { presence "The end-to-end tunnel is not terminated in this domain; this tunnel is a segment in the current domain."; description "If an end-to-end tunnel crosses multiple domains using the same technology, some additional constraints have to be taken in consideration in each domain. This TE tunnel segment is stitched to the downstream TE tunnel segment."; uses te-types:label-set-info; } } /** * TE container */ container te { description "TE global container."; leaf enable { type boolean; description "When 'true', the TE component features are enabled."; } /* TE Global Data */ container globals { description "Globals TE system-wide configuration data container."; container named-admin-groups { description "TE named admin groups container."; list named-admin-group { if-feature "te-types:extended-admin-groups"; if-feature "te-types:named-extended-admin-groups"; key "name"; description "List of named TE admin-groups."; leaf name { type string; description "A name that uniquely identifies a TE interface named admin-group."; } leaf bit-position { type uint32; description "Bit-position value for a named Administrative Group (AG). The value is an integer that represents one of the bit positions in the administrative group bitmask. Values for bit-positions between 0 and 31 are inter- preted as the original 32 bit AGs. Values of bit- positions >=32 are interpreted as Extended Administrative Group (EAG) values as per RFC 7308."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } } } container named-srlgs { description "TE named SRLGs container."; list named-srlg { if-feature "te-types:named-srlg-groups"; key "name"; description "A list of named SRLG groups."; leaf name { type string; description "A name that uniquely identifies a TE interface named SRLG."; } leaf value { type te-types:srlg; description "An SRLG value."; } leaf cost { type uint32; description "The cost associated with an SRLG. This is used as a penalty during path computation when the TE path traverses a link with this SRLG."; } } } container named-path-constraints { description "TE named path constraints container."; list named-path-constraint { if-feature "te-types:named-path-constraints"; key "name"; leaf name { type string; description "A unique identifier for a set of path constraints. Operators should ensure that when this model is used to manage multiple devices, the parameters associated with the set of path constraints sharing the same name remain consistent across those devices in order to maintain uniform path behavior."; } uses path-constraints-common; description "A list of named path constraints."; } } } /* TE Tunnel Data */ container tunnels { description "Tunnels TE configuration data container."; list tunnel { key "name"; description "The list of TE tunnels."; leaf name { type string; description "TE tunnel name."; } leaf alias { type string; description "An alternate name of the TE tunnel that can be modified anytime during its lifetime."; } leaf identifier { type uint32; description "A numeric identifier for the tunnel, unique within the scope of the ingress node. While the 'name' leaf serves as a human-readable management key, this 'identifier' corresponds to the Tunnel ID used in control plane signaling (e.g., the RSVP-TE SESSION object as defined in RFC 3209), allowing for correlation between management state and network-wide signaling."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf color { type uint32; description "A TE Tunnel [RFC3209] can be associated with an intent or objective (e.g., low latency) by tagging it with a color. This color attribute is used as a guiding criterion for mapping services onto the TE Tunnel [RFC9012][RFC9256]."; reference "RFC 9012: The BGP Tunnel Encapsulation Attribute"; } leaf description { type string; default "None"; description "Textual description for this TE tunnel."; } leaf admin-state { type identityref { base te-types:tunnel-admin-state-type; } default "te-types:tunnel-admin-state-up"; description "TE tunnel administrative state."; } leaf operational-state { type identityref { base te-types:tunnel-state-type; } config false; description "TE tunnel operational state."; } leaf state-change-timestamp { type yang:date-and-time; description "Indicates the time at which the TE tunnel's operational state was last updated."; } uses te-types:encoding-and-switching-type; uses tunnel-common-attributes; container controller { description "Contains tunnel data relevant to external controllers. This target node may be augmented by external modules, for example, to add data for PCEP initiated and/or delegated tunnels."; leaf protocol-origin { type identityref { base te-types:protocol-origin-type; } description "The protocol origin for instantiating the tunnel."; } leaf controller-entity-id { type string; description "An identifier that is associated with the entity that controls the tunnel as defined in RFC 8232."; reference "RFC 8232: Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE"; } } leaf reoptimize-timer { type uint16; units "seconds"; description "Frequency of reoptimization of a traffic-engineered LSP. A value of 0 means that the LSP is never reoptimized"; } uses tunnel-associations-properties; uses protection-restoration-properties; uses te-types:tunnel-constraints; uses tunnel-hierarchy-properties; container primary-paths { description "The set of primary paths."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery."; list primary-path { key "name"; description "List of primary paths for this tunnel."; leaf active { type boolean; config false; description "When 'true', indicates an active path has been selected from the primary paths list."; } uses path-common-properties; uses path-forward-properties; uses k-requested-paths; uses path-compute-info; uses path-state; container primary-reverse-path { when "../../../te:bidirectional = 'true'"; description "The reverse primary path properties."; uses path-common-properties; uses path-compute-info; uses path-state; container candidate-secondary-reverse-paths { description "The set of referenced candidate reverse secondary paths from the full set of secondary reverse paths which may be used for this primary path."; list candidate-secondary-reverse-path { key "secondary-reverse-path"; ordered-by user; description "List of candidate secondary reverse paths"; leaf secondary-reverse-path { type leafref { path "../../../../../../" + "te:secondary-reverse-paths/" + "te:secondary-reverse-path/te:name"; } description "A reference to the secondary reverse path that may be utilized when the containing primary reverse path is in use."; } leaf active { type boolean; config false; description "When 'true', indicates an active path has been selected from the secondary reverse paths list."; } } } } container candidate-secondary-paths { description "The set of candidate secondary paths which may be used for this primary path. When secondary paths are specified in the list the path of the secondary LSP in use must be restricted to those paths referenced. The priority of the secondary paths is specified within the list. Higher priority values are less preferred - that is to say that a path with priority 0 is the most preferred path. In the case that the list is empty, any secondary path may be utilized when the current primary path is in use."; list candidate-secondary-path { key "secondary-path"; ordered-by user; description "List of candidate secondary paths for this tunnel."; leaf secondary-path { type leafref { path "../../../../../te:secondary-paths/" + "te:secondary-path/te:name"; } description "A reference to the secondary path that may be utilized when the containing primary path is in use."; } leaf active { type boolean; config false; description "When 'true', indicates an active path has been selected from the candidate secondary paths."; } } } } } container secondary-paths { description "The set of secondary paths."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery."; list secondary-path { key "name"; description "List of secondary paths for this tunnel."; uses path-common-properties; leaf preference { type uint8 { range "1..255"; } default "1"; description "Specifies a preference for this path. The lower the number, the higher the preference."; } leaf secondary-reverse-path { type leafref { path "../../../" + "te:secondary-reverse-paths/" + "te:secondary-reverse-path/te:name"; } description "A reference to the reverse secondary path when co-routed with the secondary path."; } uses path-compute-info; uses protection-restoration-properties; uses path-state; } } container secondary-reverse-paths { description "The set of secondary reverse paths."; list secondary-reverse-path { key "name"; description "List of secondary paths for this tunnel."; uses path-common-properties; leaf preference { type uint8 { range "1..255"; } default "1"; description "Specifies a preference for this path. The lower the number higher the preference. Paths that have the same preference will be activated together."; } uses path-compute-info; uses protection-restoration-properties; uses path-state; } } action tunnel-action { description "Action commands to manipulate the TE tunnel state."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 2.5"; input { leaf action-type { type identityref { base te-types:tunnel-action-type; } description "The action to be invoked on the TE tunnel."; } } output { leaf action-result { type identityref { base te-types:te-action-result; } description "The result of the tunnel action operation."; } } } action protection-external-commands { description "Actions to manipulate the protection external commands of the TE tunnel."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; input { leaf protection-external-command { type identityref { base te-types:protection-external-commands; } description "Protection external command."; } leaf ingress-node { type boolean; default "true"; description "When 'true', indicates that the action is applied on the ingress node. By default, the action applies to the ingress node"; } leaf egress-node { type boolean; default "false"; description "When 'true', indicates that the action is applied on the egress node. By default, the action applies to the ingress node."; } leaf path-name { type string; description "The name of the path that the external command applies to."; } leaf path-type { type te-types:path-type; description "The type of the path that the external command applies to."; } leaf traffic-type { type enumeration { enum normal-traffic { description "The manual-switch or forced-switch command applies to the normal traffic (this Tunnel)."; } enum null-traffic { description "The manual-switch or forced-switch command applies to the null traffic."; } enum extra-traffic { description "The manual-switch or forced-switch command applies to the extra traffic (the extra-traffic Tunnel sharing protection bandwidth with this Tunnel)."; } } description "Indicates whether the manual-switch or forced-switch commands applies to the normal traffic, the null traffic or the extra-traffic."; reference "RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)."; } leaf extra-traffic-tunnel-ref { type tunnel-ref; description "In case there are multiple extra-traffic tunnels sharing protection bandwidth with this Tunnel (m:n protection), represents which extra-traffic Tunnel the manual-switch or forced-switch to extra-traffic command applies to."; } } } } } /* TE LSPs Data */ container lsps { config false; description "TE LSPs state container."; list lsp { key "tunnel-name lsp-id node"; unique "source destination tunnel-id lsp-id " + "extended-tunnel-id"; description "List of LSPs associated with the tunnel."; leaf tunnel-name { type string; description "The TE tunnel name."; } leaf lsp-id { type uint16; description "An identifier unique in the context of the LSP head-end. For example, as used in the RSVP-TE SENDER_TEMPLATE and FILTER_SPEC objects. The value can be changed to allow a sender to share resources with itself."; reference "RFC 3209"; } leaf node { type te-types:te-node-id; description "The node where the LSP state is retrieved."; } leaf source { type te-types:te-node-id; description "The address of the ingress LSP endpoint that identifies the start of the tunnel. This typically corresponds to the Tunnel Sender Address extracted from the RSVP-TE SENDER_TEMPLATE object."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf destination { type te-types:te-node-id; description "The address of the egress LSP endpoint that identifies the end of the tunnel. This typically corresponds to the Tunnel Endpoint Address extracted from the RSVP-TE SESSION object."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf tunnel-id { type uint16; description "An identifier of the tunnel that remains constant over the life of the tunnel. For example, this may be the Tunnel ID extracted from RSVP-TE SESSION object."; reference "RFC 3209"; } leaf extended-tunnel-id { type yang:dotted-quad; description "A qualifier used to ensure the global uniqueness of the tunnel identifier. It carries a 4-byte or 16-byte value, typically corresponding to the Extended Tunnel ID extracted from the RSVP-TE SESSION object as defined in RFC 3209."; reference "RFC 3209"; } leaf operational-state { type identityref { base te-types:lsp-state-type; } description "The LSP operational state."; } leaf signaling-type { type identityref { base te-types:path-signaling-type; } description "The signaling protocol used to set up this LSP."; } leaf origin-type { type enumeration { enum ingress { description "Origin ingress."; } enum egress { description "Origin egress."; } enum transit { description "Origin transit."; } } description "The origin of the LSP relative to the location of the local switch in the path."; } leaf lsp-resource-status { type enumeration { enum primary { description "A primary LSP is a fully established LSP for which the resource allocation has been committed at the data plane."; } enum secondary { description "A secondary LSP is an LSP that has been provisioned in the control plane only; e.g. resource allocation has not been committed at the data plane."; } } description "LSP resource allocation state."; reference "RFC 4872, section 4.2.1"; } leaf lockout-of-normal { type boolean; description "When set to 'true', it represents a lockout of normal traffic external command. When set to 'false', it represents a clear lockout of normal traffic external command. The lockout of normal traffic command applies to this Tunnel."; reference "RFC 4427"; } leaf freeze { type boolean; description "When set to 'true', it represents a freeze external command. When set to 'false', it represents a clear freeze external command. The freeze command applies to all the Tunnels which are sharing the protection resources with this Tunnel."; reference "RFC 4427"; } leaf lsp-protection-role { type enumeration { enum working { description "A working LSP must be a primary LSP whilst a protecting LSP can be either a primary or a secondary LSP. Also, known as protected LSPs when working LSPs are associated with protecting LSPs."; } enum protecting { description "A secondary LSP is an LSP that has been provisioned in the control plane only; e.g. resource allocation has not been committed at the data plane."; } } description "LSP role type."; reference "RFC 4872, section 4.2.1"; } leaf lsp-protection-state { type identityref { base te-types:lsp-protection-state; } config false; description "The reported protection state controlling which tunnel is using the resources of the protecting LSP."; } leaf ingress-node-id { type te-types:te-node-id; description "Indicates the te-node-id of the ingress node of the TE tunnel or tunnel segment when the protection action is applied to the ingress node or the Wait To Restore (WTR) timer is active. This is set to '0.0.0.0' when the controller is not aware of the te-node-id of ingress-node."; } leaf egress-node-id { type te-types:te-node-id; description "Indicates the te-node-id of the egress node of the TE tunnel or tunnel segment when the protection action is applied to the ingress node or the WTR timer is active. This is set to '0.0.0.0' when the controller is not aware of the te-node-id of ingress-node."; } container lsp-actual-route-information { description "RSVP recorded route object information."; list lsp-actual-route-information { when "../../origin-type = 'ingress'" { description "Applicable on ingress LSPs only."; } key "index"; description "Record route list entry."; uses te-types:record-route-state; } } } } } /* TE Tunnel RPCs/execution Data */ rpc tunnels-path-compute { description "This RPC is a generic API whose input and output parameters are expected to be provided by augments to this module."; reference "RFC 4655: A Path Computation Element (PCE)-Based Architecture."; input { container path-compute-info { /* * An external path compute module may augment this * target. */ description "RPC input information."; } } output { container path-compute-result { /* * An external path compute module may augment this * target. */ description "RPC output information."; } } } rpc tunnels-actions { description "RPC that manipulates the state of a TE tunnel."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 2.5"; input { container tunnel-info { description "TE tunnel information."; choice filter-type { mandatory true; description "Filter choice."; case all-tunnels { leaf all { type empty; mandatory true; description "When present, applies the action on all TE tunnels."; } } case one-tunnel { leaf tunnel { type tunnel-ref; description "Apply action on the specific TE tunnel."; } } } } container action-info { description "TE tunnel action information."; leaf action { type identityref { base te-types:tunnel-action-type; } description "The action type."; } leaf disruptive { when "derived-from-or-self(../action, " + "'te-types:tunnel-action-reoptimize')"; type empty; description "Specifies whether reoptimization operations, particularly when multiple tunnels are involved, are permitted to cause traffic disruption on some TE tunnels."; } } } output { leaf action-result { type identityref { base te-types:te-action-result; } description "The result of the tunnel action operation."; } } } }

]]>


TE Device YANG Moule

The TE device YANG module 'ietf-te-device' models data that is specific to
managing a TE device.  This module augments the TE YANG module.

Module Structure

The 'ietf-te-device' module defines the configuration and operational state data
that is specific to the device, including those related to the TE subsystem, tunnels, LSPs, and interfaces.

TE Device Globals, Tunnels and LSPs

The 'ietf-te-device' module augments the TE YANG module 'ietf-te' at the
'globals', 'tunnels', and 'lsps' levels to include the device-specific
configurations and operational state.

 shows the
'ietf-te-device' subtree generated with depth=4 that describes those
augmentations.



The following is the description of the augmented data at each level.

Global Timers (Augmenting /te:te/te:globals):

These are device-specific global configuration parameters related to LSP timers, applied system-wide.


  lsp-install-interval
  
  :
  
    An optional leaf that specifies the delay time, in seconds, before a newly provisioned LSP is installed into the forwarding plane to carry traffic.
  
  lsp-cleanup-interval
  
  :
  
    An optional leaf that specifies the delay time, in seconds, before an LSP is completely removed from the system after it is no longer in use.
  
  lsp-invalidation-interval
  
  :
  
    An optional leaf that specifies the delay time, in seconds, during which a TE LSP's path is considered invalid before any corrective action is taken.
  


Tunnel Device-Dependent Attributes (Augmenting /te:te/te:tunnels/te:tunnel).

These are device-specific configuration parameters that apply to individual TE Tunnels:


  path-invalidation-action
  
  :
  
    An optional identityref that specifies the action to be taken when a TE Tunnel's path is deemed invalid (e.g., tear down, recompute).
  
  lsp-install-interval
  
  :
  
    An optional leaf that specifies the delay time, in seconds, for this specific TE Tunnel before its LSPs are installed into the forwarding plane. This value can override the global lsp-install-interval.
  
  lsp-cleanup-interval
  
  :
  
    An optional leaf that specifies the delay time, in seconds, for this specific TE Tunnel before its LSPs are cleaned up. This value can override the global lsp-cleanup-interval.
  
  lsp-invalidation-interval
  
  :
  
    An optional leaf that specifies the delay time, in seconds, for this specific TE Tunnel during which its path is considered invalid before action is taken. This value can override the global lsp-invalidation-interval.
  


LSP Device-Dependent State (Augmenting /te:te/te:lsps/te:lsp).

These are read-only operational state parameters providing device-specific details for individual LSPs:


  lsp-timers
  
  :
  
    A container that holds various timer-related operational state for an LSP, applicable primarily to ingress LSPs.
  
  uptime
  
  :
  
    An optional leaf that indicates the total time, in seconds, that the LSP has been operational.
  
  time-to-install
  
  :
  
    An optional leaf that indicates the remaining time, in seconds, for a new LSP to be fully instantiated and ready to carry traffic.
  
  time-to-destroy
  
  :
  
    An optional leaf that indicates the remaining time, in seconds, before an existing LSP is torn down.
  
  downstream-info
  
  :
  
    A container that holds information about the downstream neighbor and label for the LSP, applicable when the LSP is not at its egress.
  
  upstream-info
  
  :
  
    A container that holds information about the upstream neighbor and label for the LSP, applicable when the LSP is not at its ingress.
  



TE Device Interfaces

The TE interface is modeled as a reference to an existing interface as defined
in the 'ietf-interfaces' YANG module .

 shows the TE interface subtree from the TE device module 'ietf-te-device' with depth=4.
The full tree diagram is shown in .



The main elements under the interfaces container are:

threshold-type:


  An optional enumeration that specifies the type of thresholding mechanism used for flooding bandwidth updates for all TE interfaces on the device. Options include 'delta' (flooding on a change greater than a specified delta) or 'threshold-crossed' (flooding when bandwidth crosses a defined threshold).


delta-percentage:


  An optional percentage value, used when threshold-type is 'delta', indicating the change in reservable bandwidth that triggers an IGP update for all TE interfaces.


threshold-specification:


  An optional enumeration, used when threshold-type is 'threshold-crossed', to define whether a single set of 'mirrored-up-down' thresholds or separate 'separate-up-down' thresholds are used for increasing and decreasing bandwidth. This applies globally to all TE interfaces.


up-thresholds:


  A list of percentage values, used with 'separate-up-down' thresholding, that define the points at which bandwidth updates are triggered when the reservable bandwidth is increasing across all TE interfaces.


down-thresholds:


  A list of percentage values, used with 'separate-up-down' thresholding, that define the points at which bandwidth updates are triggered when the reservable bandwidth is decreasing across all TE interfaces.


up-down-thresholds:


  A list of percentage values, used with 'mirrored-up-down' thresholding, that define the points at which bandwidth updates are triggered for both increasing and decreasing reservable bandwidth across all TE interfaces.


interface:


  A list of individual TE interfaces configured on the device. Each entry represents a network interface enabled for Traffic Engineering and contains its specific attributes and state. A TE interface is identified by the 'name' leaf, which references an existing network interface on the device.



  name:



  
    A leaf that uniquely identifies the TE interface, referencing an existing network interface.
  



  te-metric:



  
    An optional leaf that holds the TE metric value associated with this specific interface, used during path computation.
  



  admin-group-type:



  
    A choice node that allows configuring administrative groups for the interface using either direct values or named references.
  



  value-admin-groups:



  
    A choice for defining administrative groups using direct bitmask values.
  



  named-admin-groups:



  
    A list of named administrative groups applied to this TE interface, referencing globally defined named administrative groups.
  



  srlg-type:



  
    A choice node that allows configuring SRLGs for the interface using either direct values or named references.
  



  
    value-srlgs:
  



  
    
      A list of direct SRLG values that this link is a part of.
    
  



  
    named-srlgs:
  



  
    
      A list of named SRLGs applied to this interface, referencing globally defined named SRLGs.
    
  



  threshold-type:



  
    An optional enumeration, similar to the global threshold-type, but specifically for this individual TE interface, allowing per-interface override of the global bandwidth flooding behavior.
  



  delta-percentage:



  
    An optional percentage value, specific to this interface, used when its threshold-type is 'delta'.
  



  threshold-specification:



  
    An optional enumeration, specific to this interface, used when its threshold-type is 'threshold-crossed'.
  



  up-thresholds:



  
    A list of percentage values, specific to this interface, used with 'separate-up-down' thresholding for increasing bandwidth.
  



  down-thresholds:



  
    A list of percentage values, specific to this interface, used with 'separate-up-down' thresholding for decreasing bandwidth.
  



  up-down-thresholds:



  
    A list of percentage values, specific to this interface, used with 'mirrored-up-down' thresholding for both increasing and decreasing bandwidth.
  



  switching-capabilities:



  
    A list of switching capabilities supported by this interface.
  



  
    switching-capability:
  



  
    
      An identityref indicating a specific switching capability (e.g., Packet, Lambda, Fiber).
    
  



  
    encoding:
  



  
    
      An optional identityref indicating the LSP encoding type supported by this capability on the interface.
    
  



  te-advertisements-state:



  
    A read-only container that provides operational state information related to how this TE interface's attributes are advertised.
  



  
    flood-interval:
  



  
    
      An optional leaf indicating the configured periodic flooding interval for this interface.
    
  



  
    last-flooded-time:
  



  
    
      An optional leaf showing the time elapsed since the last advertisement flood for this interface.
    
  



  
    next-flooded-time:
  



  
    
      An optional leaf showing the time remaining until the next scheduled advertisement flood for this interface.
    
  



  
    last-flooded-trigger:
  



  
    
      An optional enumeration indicating the event that triggered the last advertisement flood (e.g., link-up, bandwidth-change, periodic-timer).
    
  



  
    advertised-level-areas:
  



  
    
      A list of IGP level-areas in which this TE interface's link state information is advertised.
    
  




Tree Diagram

 shows the YANG tree diagram of the TE device YANG module defined in
'ietf-te-device'.




YANG Module

The 'ietf-te-device' module imports the following modules:


  ietf-interfaces defined in 
  ietf-routing-types defined in 
  ietf-te-types defined in 
  ietf-te defined in this document


 file "ietf-te-device@2026-02-28.yang"
module ietf-te-device {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-te-device";

  prefix te-dev;

  /* Import TE module */

  import ietf-te {
    prefix te;
    reference
      "RFCXXXX: A YANG Data Model for Traffic Engineering Tunnels,
       Label Switched Paths, and Interfaces.";
  }

  /* Import TE types */

  import ietf-te-types {
    prefix te-types;
    reference
      "draft-ietf-teas-rfc8776-update: Common YANG Data Types
       for Traffic Engineering.";
  }
  import ietf-interfaces {
    prefix if;
    reference
      "RFC8343: A YANG Data Model for Interface Management";
  }
  import ietf-routing-types {
    prefix rt-types;
    reference
      "RFC8294: Common YANG Data Types for the Routing Area";
  }

  organization
    "IETF Traffic Engineering Architecture and Signaling (TEAS)
     Working Group";
  contact
    "WG Web:   
     WG List:  

     Editor:   Tarek Saad
               

     Editor:   Rakesh Gandhi
               

     Editor:   Vishnu Pavan Beeram
               

     Editor:   Himanshu Shah
               

     Editor:   Xufeng Liu
               

     Editor:   Igor Bryskin
               ";

  description
    "This module defines a data model for TE device configurations,
     state, and RPCs.

     Copyright (c) 2025 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.: replace XXXX with actual RFC number and remove this
  // note.
  // RFC Ed.: update the date below with the date of RFC publication
  // and remove this note.

  revision 2026-02-28 {
    description
      "Initial revision for the TE device YANG module.";
    reference
      "RFCXXXX: A YANG Data Model for Traffic Engineering Tunnels
       and Interfaces";
  }

  grouping lsp-device-timers {
    description
      "Device TE LSP timers configs.";
    leaf lsp-install-interval {
      type uint32;
      units "seconds";
      description
        "TE LSP installation delay time.";
    }
    leaf lsp-cleanup-interval {
      type uint32;
      units "seconds";
      description
        "TE LSP cleanup delay time.";
    }
    leaf lsp-invalidation-interval {
      type uint32;
      units "seconds";
      description
        "TE LSP path invalidation before taking action delay time.";
    }
  }

  grouping te-igp-flooding-bandwidth-config {
    description
      "Configurable items for igp flooding bandwidth
       threshold configuration.";
    leaf threshold-type {
      type enumeration {
        enum delta {
          description
            "'delta' indicates that the local
             system should flood IGP updates when a
             change in reserved bandwidth >= the specified
             delta occurs on the interface.";
        }
        enum threshold-crossed {
          description
            "THRESHOLD-CROSSED indicates that
             the local system should trigger an update (and
             hence flood) the reserved bandwidth when the
             reserved bandwidth changes such that it crosses,
             or becomes equal to one of the threshold values.";
        }
      }
      description
        "The type of threshold that should be used to specify the
         values at which bandwidth is flooded. 'delta' indicates that
         the local system should flood IGP updates when a change in
         reserved bandwidth >= the specified delta occurs on the
         interface. Where 'threshold-crossed' is specified, the local
         system should trigger an update (and hence flood) the
         reserved bandwidth when the reserved bandwidth changes such
         that it crosses, or becomes equal to one of the threshold
         values.";
    }
    leaf delta-percentage {
      when "../threshold-type = 'delta'" {
        description
          "The percentage delta can only be specified when the
           threshold type is specified to be a percentage delta of
           the reserved bandwidth.";
      }
      type rt-types:percentage;
      description
        "The percentage of the maximum-reservable-bandwidth
         considered as the delta that results in an IGP update
         being flooded.";
    }
    leaf threshold-specification {
      when "../threshold-type = 'threshold-crossed'" {
        description
          "The selection of whether mirrored or separate threshold
           values are to be used requires user-specified thresholds
           to be set.";
      }
      type enumeration {
        enum mirrored-up-down {
          description
            "mirrored-up-down indicates that a single set of
             threshold values should be used for both increasing
             and decreasing bandwidth when determining whether
             to trigger updated bandwidth values to be flooded
             in the IGP TE extensions.";
        }
        enum separate-up-down {
          description
            "separate-up-down indicates that a separate
             threshold values should be used for the increasing
             and decreasing bandwidth when determining whether
             to trigger updated bandwidth values to be flooded
             in the IGP TE extensions.";
        }
      }
      description
        "This value specifies whether a single set of threshold
         values should be used for both increasing and decreasing
         bandwidth when determining whether to trigger updated
         bandwidth values to be flooded in the IGP TE extensions.
         'mirrored-up-down' indicates that a single value (or set of
         values) should be used for both increasing and decreasing
         values, where 'separate-up-down' specifies that the
         increasing and decreasing values will be separately
         specified.";
    }
    leaf-list up-thresholds {
      when "../threshold-type = 'threshold-crossed'"
         + "and ../threshold-specification = 'separate-up-down'" {
        description
          "A list of up-thresholds can only be specified when the
           bandwidth update is triggered based on crossing a
           threshold and separate up and down thresholds are
           required.";
      }
      type rt-types:percentage;
      description
        "The thresholds (expressed as a percentage of the maximum
         reservable bandwidth) at which bandwidth updates are to be
         triggered when the bandwidth is increasing.";
    }
    leaf-list down-thresholds {
      when "../threshold-type = 'threshold-crossed'"
         + "and ../threshold-specification = 'separate-up-down'" {
        description
          "A list of down-thresholds can only be specified when the
           bandwidth update is triggered based on crossing a
           threshold and separate up and down thresholds are
           required.";
      }
      type rt-types:percentage;
      description
        "The thresholds (expressed as a percentage of the maximum
         reservable bandwidth) at which bandwidth updates are to be
         triggered when the bandwidth is decreasing.";
    }
    leaf-list up-down-thresholds {
      when "../threshold-type = 'threshold-crossed'"
         + "and ../threshold-specification = 'mirrored-up-down'" {
        description
          "A list of thresholds corresponding to both increasing
           and decreasing bandwidths can be specified only when an
           update is triggered based on crossing a threshold, and
           the same up and down thresholds are required.";
      }
      type rt-types:percentage;
      description
        "The thresholds (expressed as a percentage of the maximum
         reservable bandwidth of the interface) at which bandwidth
         updates are flooded - used both when the bandwidth is
         increasing and decreasing.";
    }
  }

  /**
   * TE device augmentations
   */
  augment "/te:te" {
    description
      "TE global container.";
    /* TE Interface Configuration Data */
    container interfaces {
      description
        "Configuration data model for TE interfaces.";
      uses te-igp-flooding-bandwidth-config;
      list interface {
        key "name";
        description
          "The list of interfaces enabled for TE.";
        leaf name {
          type if:interface-ref;
          description
            "The reference to interface enabled for TE.";
        }
        /* TE interface parameters */
        leaf te-metric {
          type te-types:te-metric;
          description
            "TE interface metric.";
        }
        choice admin-group-type {
          description
            "TE interface administrative groups
             representation type.";
          case value-admin-groups {
            choice value-admin-group-type {
              description
                "The type of admin-groups.";
              case admin-groups {
                description
                  "Administrative group/Resource
                   class.";
                leaf admin-group {
                  type te-types:admin-group;
                  description
                    "TE interface administrative group.";
                }
              }
              case extended-admin-groups {
                if-feature "te-types:extended-admin-groups";
                description
                  "Extended administrative group/Resource
                   class.";
                leaf extended-admin-group {
                  type te-types:extended-admin-group;
                  description
                    "TE interface extended administrative group.";
                }
              }
            }
          }
          case named-admin-groups {
            list named-admin-groups {
              if-feature "te-types:extended-admin-groups";
              if-feature "te-types:named-extended-admin-groups";
              key "named-admin-group";
              description
                "A list of named admin-group entries.";
              leaf named-admin-group {
                type leafref {
                  path "../../../../te:globals/"
                     + "te:named-admin-groups/te:named-admin-group/"
                     + "te:name";
                }
                description
                  "A named admin-group entry.";
              }
            }
          }
        }
        choice srlg-type {
          description
            "Choice of SRLG configuration.";
          case value-srlgs {
            list values {
              key "value";
              description
                "List of SRLG values that
                 this link is part of.";
              leaf value {
                type uint32 {
                  range "0..4294967295";
                }
                description
                  "Value of the SRLG";
              }
            }
          }
          case named-srlgs {
            list named-srlgs {
              if-feature "te-types:named-srlg-groups";
              key "named-srlg";
              description
                "A list of named SRLG entries.";
              leaf named-srlg {
                type leafref {
                  path "../../../../te:globals/"
                     + "te:named-srlgs/te:named-srlg/te:name";
                }
                description
                  "A named SRLG entry.";
              }
            }
          }
        }
        uses te-igp-flooding-bandwidth-config;
        list switching-capabilities {
          key "switching-capability";
          description
            "List of interface capabilities for this interface.";
          leaf switching-capability {
            type identityref {
              base te-types:switching-capabilities;
            }
            description
              "Switching Capability for this interface.";
          }
          leaf encoding {
            type identityref {
              base te-types:lsp-encoding-types;
            }
            description
              "Encoding supported by this interface.";
          }
        }
        container te-advertisements-state {
          config false;
          description
            "TE interface advertisements state container.";
          leaf flood-interval {
            type uint32;
            description
              "The periodic flooding interval.";
          }
          leaf last-flooded-time {
            type uint32;
            units "seconds";
            description
              "Time elapsed since last flooding in seconds.";
          }
          leaf next-flooded-time {
            type uint32;
            units "seconds";
            description
              "Time remained for next flooding in seconds.";
          }
          leaf last-flooded-trigger {
            type enumeration {
              enum link-up {
                description
                  "Link-up flooding trigger.";
              }
              enum link-down {
                description
                  "Link-down flooding trigger.";
              }
              enum threshold-up {
                description
                  "Bandwidth reservation up threshold.";
              }
              enum threshold-down {
                description
                  "Bandwidth reservation down threshold.";
              }
              enum bandwidth-change {
                description
                  "Bandwidth capacity change.";
              }
              enum user-initiated {
                description
                  "Initiated by user.";
              }
              enum srlg-change {
                description
                  "SRLG property change.";
              }
              enum periodic-timer {
                description
                  "Periodic timer expired.";
              }
            }
            default "periodic-timer";
            description
              "Trigger for the last flood.";
          }
          list advertised-level-areas {
            key "level-area";
            description
              "List of level-areas that the TE interface is
               advertised in.";
            leaf level-area {
              type uint32;
              description
                "The IGP area or level where the TE interface link
                 state is advertised in.";
            }
          }
        }
      }
    }
  }

  /* TE globals device augmentation */

  augment "/te:te/te:globals" {
    description
      "Global TE device specific configuration parameters.";
    uses lsp-device-timers;
  }

  /* TE tunnels device configuration augmentation */

  augment "/te:te/te:tunnels/te:tunnel" {
    description
      "Tunnel device dependent augmentation.";
    leaf path-invalidation-action {
      type identityref {
        base te-types:path-invalidation-action-type;
      }
      description
        "Tunnel path invalidation action.";
    }
    uses lsp-device-timers;
  }

  /* TE LSPs device state augmentation */

  augment "/te:te/te:lsps/te:lsp" {
    description
      "TE LSP device dependent augmentation.";
    container lsp-timers {
      when "../te:origin-type = 'ingress'" {
        description
          "Applicable to ingress LSPs only.";
      }
      description
        "Ingress LSP timers.";
      leaf uptime {
        type uint32;
        units "seconds";
        description
          "The LSP uptime.";
      }
      leaf time-to-install {
        type uint32;
        units "seconds";
        description
          "The time remaining for a new LSP to be instantiated
           in forwarding to carry traffic.";
      }
      leaf time-to-destroy {
        type uint32;
        units "seconds";
        description
          "The time remaining for an existing LSP to be torn down.";
      }
    }
    container downstream-info {
      when "../te:origin-type != 'egress'" {
        description
          "Downstream information of the LSP.";
      }
      description
        "Downstream information.";
      leaf nhop {
        type te-types:te-tp-id;
        description
          "Downstream next-hop address.";
      }
      leaf outgoing-interface {
        type if:interface-ref;
        description
          "Downstream interface.";
      }
      container neighbor {
        uses te-types:te-generic-node-id;
        description
          "Downstream neighbor address.";
      }
      leaf label {
        type rt-types:generalized-label;
        description
          "Downstream label.";
      }
    }
    container upstream-info {
      when "../te:origin-type != 'ingress'" {
        description
          "Upstream information of the LSP.";
      }
      description
        "Upstream information.";
      leaf phop {
        type te-types:te-tp-id;
        description
          "Upstream next-hop or previous-hop address.";
      }
      container neighbor {
        uses te-types:te-generic-node-id;
        description
          "Upstream neighbor address.";
      }
      leaf label {
        type rt-types:generalized-label;
        description
          "Upstream label.";
      }
    }
  }

  /* TE interfaces RPCs/execution Data */

  rpc link-state-update {
    description
      "Triggers a link state update for the specific interface.";
    input {
      choice filter-type {
        mandatory true;
        description
          "Filter choice.";
        case match-all {
          leaf all {
            type empty;
            mandatory true;
            description
              "Match all TE interfaces.";
          }
        }
        case match-one-interface {
          leaf interface {
            type if:interface-ref;
            description
              "Match a specific TE interface.";
          }
        }
      }
    }
  }
}

]]>




Notifications

Notifications are a key component of any topology data model.

 and  define a subscription mechanism and a push
mechanism for YANG datastores.  These mechanisms currently allow the
user to:


  Subscribe to notifications on a per-client basis.
  Specify subtree filters or XML Path Language (XPath) filters so
that only contents of interest will be sent.
  Specify either periodic or on-demand notifications.



IANA Considerations

This document registers the following URIs in the IETF XML registry
.
Following the format in , the following registrations are
requested to be made.



This document registers two YANG modules in the YANG Module Names
registry .




Security Considerations

The YANG module specified in this document defines a schema for data that is
designed to be accessed via YANG-based management protocols, such as
NETCONF  and RESTCONF . These YANG-based management
protocols (1) have to use a secure transport layer
(e.g., SSH , TLS , and QUIC ) and (2) have
to use mutual authentication.

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

There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default). These
data nodes may be considered sensitive or vulnerable in some network
environments. Write operations (e.g., edit-config) to these data nodes without
proper protection can have a negative effect on network operations. These are
the subtrees and data nodes and their sensitivity/vulnerability:

"/te/globals":  This module specifies the global TE configurations on a device.
Unauthorized access to this container could cause the device to ignore packets
it should receive and process.

"/te/tunnels":  This list specifies the configuration and state of TE Tunnels
present on the device or controller.  Unauthorized access to this list could
cause the device to ignore packets it should receive and process. An attacker
may also use state to derive information about the network topology,
and subsequently orchestrate further attacks.

"/te/interfaces":  This list specifies the configuration and state TE interfaces
on a device. Unauthorized access to this list could cause the device to ignore packets it
should receive and process.

Some of the readable data nodes in this YANG module may be considered sensitive
or vulnerable in some network environments. It is thus important to control
read access (e.g., via get, get-config, or notification) to these data nodes.
These are the subtrees and data nodes and their sensitivity/vulnerability:

"/te/lsps": this list contains information state about established LSPs in the network.
An attacker can use this information to derive information about the network topology,
and subsequently orchestrate further attacks.

Some of the RPC operations in this YANG module may be considered sensitive or
vulnerable in some network environments. It is thus important to control access
to these operations. These are the operations and their
sensitivity/vulnerability:

"/te/tunnels-actions": using this RPC, an attacker can modify existing paths that
may be carrying live traffic, and hence result in interruption to services
carried over the network.

"/te/tunnels-path-compute": using this RPC, an attacker can retrieve sensitive
information about the network provider which can be used to orchestrate further
attacks.

The YANG module defines a set of identities, types, and groupings. These nodes
are intended to be reused by other YANG modules. The module by itself does not
expose any data nodes that are writable, data nodes that contain read-only
state, or RPCs.  As such, there are no additional security issues related to
the YANG module that need to be considered.

Modules that use the groupings that are defined in this document should
identify the corresponding security considerations. For example, reusing some
of these groupings will expose privacy-related information (e.g.,
'node-example').


Acknowledgement

The authors would like to thank the  members of the multivendor YANG design
team who are involved in the definition of this model.

The authors would like to thank Tom Petch and Adrian Farrel for reviewing and
providing useful feedback about the document. The authors would also like to
thank Loa Andersson, Lou Berger, Sergio Belotti, Italo Busi, Carlo Perocchio,
Francesco Lazzeri, Aihua Guo, Dhruv Dhody, and Raqib Jones for providing
feedback on this document.


Contributors



  




    


  
    Generic protection switching - Linear trail and subnetwork protection
    
      ITU-T Recommendation G.808.1
    
    
  
  




  
    Segment Routing Policy Architecture
    
    
    
    
    
    
    
      Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
      This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.
    
  
  
  


  
    RSVP-TE: Extensions to RSVP for LSP Tunnels
    
    
    
    
    
    
    
    
      This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]
    
  
  
  


  
    Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
    
    
    
      This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]
    
  
  
  


  
    The YANG 1.1 Data Modeling Language
    
    
    
      YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).
    
  
  
  


  
    Common YANG Data Types
    
    
    
      This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991.
    
  
  
  


  
    Common YANG Data Types for the Routing Area
    
    
    
    
    
    
    
      This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.
    
  
  
  



   
      Common YANG Data Types for Traffic Engineering
      
         Huawei
      
      
         Futurewei Technologies
      
      
         Alef Edge
      
      
         Cisco Systems Inc.
      
      
         Individual
      
      
      
	    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.

	 
      
   
   
   


  
    YANG Tree Diagrams
    
    
    
    
      This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.
    
  
  
  
  


  
    A YANG Data Model for Interface Management
    
    
    
      This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).
      The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
      This document obsoletes RFC 7223.
    
  
  
  


  
    The BGP Tunnel Encapsulation Attribute
    
    
    
    
    
    
      This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.
      This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.
    
  
  
  


  
    A YANG Data Model for Network Topologies
    
    
    
    
    
    
    
    
      This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.
    
  
  
  


  
    YANG Data Model for Traffic Engineering (TE) Topologies
    
    
    
    
    
    
    
    
      This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.
    
  
  
  


  
    Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
    
    
    
    
      To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).
      This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]
    
  
  
  


  
    RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery
    
    
    
    
    
      This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]
    
  
  
  


  
    RSVP ASSOCIATION Object Extensions
    
    
    
    
    
      The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]
    
  
  
  


  
    OSPF Traffic Engineering (TE) Metric Extensions
    
    
    
    
    
    
    
      In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.
      This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.
      Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.
    
  
  
  


  
    IS-IS Traffic Engineering (TE) Metric Extensions
    
    
    
    
    
    
    
    
      In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
      This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
      Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.
      This document obsoletes RFC 7810.
    
  
  
  


  
    Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE
    
    
    
    
    
    
    
    
      A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions.
    
  
  
  


  
    MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators
    
    
    
    
    
    
    
    
      This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.
      This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.
      This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.
      This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.
    
  
  
  


  
    Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode
    
    
    
    
    
    
    
      This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup.
    
  
  
  


  
    A Path Computation Element (PCE)-Based Architecture
    
    
    
    
    
      Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
      This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.
    
  
  
  


  
    Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
    
    
    
    
    
    
      The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
      Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.
    
  
  
  


  
    Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)
    
    
    
      MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).
      This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.
    
  
  
  


  
    Subscription to YANG Notifications
    
    
    
    
    
    
    
      This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.
    
  
  
  


  
    Subscription to YANG Notifications for Datastore Updates
    
    
    
    
      This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.
    
  
  
  


  
    The IETF XML Registry
    
    
    
      This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.
    
  
  
  
  


  
    YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
    
    
    
      YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]
    
  
  
  


  
    QUIC: A UDP-Based Multiplexed and Secure Transport
    
    
    
    
      This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.
    
  
  
  


  
    Network Configuration Access Control Model
    
    
    
    
      The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.
      This document obsoletes RFC 6536.
    
  
  
  
  




    

    




  
    Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
    
    
    
    
    
      This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.
      There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]
    
  
  
  


  
    Segment Routing Architecture
    
    
    
    
    
    
    
    
      Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.
      SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
      SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.
    
  
  
  


  
    Network Configuration Protocol (NETCONF)
    
    
    
    
    
    
      The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]
    
  
  
  



   
      Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
      
         YumaWorks
      
      
         Orange
      
      
         Huawei
      
      
      
	    This document provides guidelines for authors and reviewers of
   specifications containing YANG data models, including IANA-maintained
   modules.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF Protocol
   implementations that utilize YANG modules.  This document obsoletes
   RFC 8407.

   Also, this document updates RFC 8126 by providing additional
   guidelines for writing the IANA considerations for RFCs that specify
   IANA-maintained modules.

	 
      
   
   
   



   
      A YANG Data Model for requesting path computation
      
         Huawei Technologies
      
      
         Nokia
      
      
         Telefonica
      
      
         Google
      
      
         China Unicom
      
      
      
	    There are scenarios, typically in a hierarchical Software-Defined
   Networking (SDN) context, where the topology information provided by
   a Traffic Engineering (TE) network provider may be insufficient for
   its client to perform multi-domain path computation.  In these cases
   the client would need to request the TE network provider to compute
   some intra-domain paths to be used by the client to choose the
   optimal multi-domain paths.

   This document provides a mechanism to request path computation by
   augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY.

   [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of
   draft-ietf-teas-yang-te once it has been published.

   Moreover, this document describes some use cases where the path
   computation request, via YANG-based protocols (e.g., NETCONF or
   RESTCONF), can be needed.

	 
      
   
   
   


  
    Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
    
    
    
    
    
      This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).
      The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.
      In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. [STANDARDS-TRACK]
    
  
  
  


  
    Generalized Multi-Protocol Label Switching (GMPLS) Architecture
    
    
    
      Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.
      This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK]
    
  
  
  


  
    Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
    
    
    
      This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]
    
  
  
  


  
    Procedures for Dynamically Signaled Hierarchical Label Switched Paths
    
    
    
    
      Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.
      Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]
    
  
  
  


  
    Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)
    
    
    
    
      This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.
    
  
  
  


  
    RESTCONF Protocol
    
    
    
    
    
      This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).
    
  
  
  


  
    Using the NETCONF Protocol over Secure Shell (SSH)
    
    
    
      This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]
    
  
  
  


  
    The Transport Layer Security (TLS) Protocol Version 1.3
    
    
    
      This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
      This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
    
  
  
  




    






Data Tree Examples

This section provides examples demonstrating the use of the model with RESTCONF  and JSON encoding.
The examples are based on a 4-node network topology depicted in , where RSVP-TE tunnels can be established.
The loopback addresses for each node, which serve as the TE Node IDs, are detailed in Table 2 below:


      Node
      TE Node ID (IPv4)
      TE Node ID (IPv6)
      A
      192.0.2.1
      2001:db8::1
      B
      192.0.2.2
      2001:db8::2
      C
      192.0.2.3
      2001:db8::3
      D
      192.0.2.4
      2001:db8::4


This network topology forms the foundation for the subsequent examples, which
illustrate the setup and configuration of RSVP-TE tunnels using the model.



Basic Tunnel Setup

This example uses the TE Tunnel YANG data model defined in this document to create an
RSVP-TE signaled Tunnel of packet LSP encoding type. First, the TE Tunnel is created with no specific restrictions or constraints (e.g., protection or restoration).
The TE Tunnel ingresses on router A and egresses on router D.

In this case, the TE Tunnel is created without specifying additional information about the primary paths.




Global Named Path Constraints

This example uses the YANG data model to create a 'named path constraint' that can be referenced by TE Tunnels.
The path constraint, in this case, limits the TE Tunnel hops for the computed path.




Tunnel with Global Path Constraint

In this example, the previously created 'named path constraint' is applied to the TE Tunnel created in .




Tunnel with Per-tunnel Path Constraint

In this example, the per-tunnel path constraint is explicitly indicated under the TE Tunnel created in  to constrain the computed path for the tunnel.




Tunnel State

In this example, the 'GET' query is sent to return the state stored about the tunnel.



The request, with status code 200 would include, for example, the following json:




Example TE Tunnel with Primary and Secondary Paths

The example in this section uses the network topology depicted in .
The loopback addresses for each node, which serve as the TE Node IDs, are detailed in  below:


      Node
      TE Node ID (IPv4)
      TE Node ID (IPv6)
      A
      192.0.2.1
      2001:db8::1
      B
      192.0.2.2
      2001:db8::2
      C
      192.0.2.3
      2001:db8::3
      D
      192.0.2.4
      2001:db8::4
      E
      192.0.2.5
      2001:db8::5
      F
      192.0.2.6
      2001:db8::6
      G
      192.0.2.7
      2001:db8::7
      H
      192.0.2.8
      2001:db8::8
      I
      192.0.2.9
      2001:db8::9
      J
      192.0.2.10
      2001:db8::a




Below is the state retrieved for a TE tunnel that is setup from ingress node A
(192.0.2.1) to egress node E (192.0.2.5) with primary, secondary, reverse, and
secondary reverse paths as shown in .




Example Multi-domain TE Tunnel with Primary and Secondary Paths



The following state is retrieved for a multi-domain TE tunnel, where both the
primary and secondary paths consist of TE tunnel segments, as shown in .
In each domain, a TE tunnel segment is established to form the complete end-to-end TE path.
The nodes (192.0.2.100) and (192.0.2.200) form the multi-domain end-to-end source and destination
respectively. The nodes (192.0.2.1), (192.0.2.2), (192.0.2.3), and (192.0.2.4) act as domain
border nodes and transit nodes for the end-to-end TE tunnel LSPs.





Full Model Tree Diagram

The full tree diagram of the TE YANG data model defined in
module 'ietf-te' is shown below.

 /te/lsps/lsp/tunnel-name
          +--ro node?                     leafref
          +--ro lsp-id?                   leafref
          +--ro state-change-timestamp?   yang:date-and-time
  grouping path-computation-response:
    +--ro computed-paths-properties
    |  +--ro computed-path-properties* [k-index]
    |     +--ro k-index?                            uint8
    |     +---u te-types:generic-path-properties
    +--ro computed-path-error-infos
       +--ro computed-path-error-info* []
          +--ro error-description?   string
          +--ro error-timestamp?     yang:date-and-time
          +--ro error-reason?        identityref
  grouping protection-restoration-properties:
    +-- protection
    |  +-- protection-type?                identityref
    |  +-- protection-reversion-disable?   boolean
    |  +-- hold-off-time?                  uint32
    |  +-- wait-to-revert?                 uint16
    |  +-- aps-signal-id?                  uint8
    +-- restoration
       +-- restoration-type?                identityref
       +-- restoration-scheme?              identityref
       +-- restoration-reversion-disable?   boolean
       +-- hold-off-time?                   uint32
       +-- wait-to-restore?                 uint16
       +-- wait-to-revert?                  uint16
  grouping tunnel-associations-properties:
    +-- association-objects
       +-- association-object* [association-key]
       |  +-- association-key?   string
       |  +-- type?              identityref
       |  +-- id?                uint16
       |  +-- source
       |     +---u te-types:te-generic-node-id
       +-- association-object-extended* [association-key]
          +-- association-key?   string
          +-- type?              identityref
          +-- id?                uint16
          +-- source
          |  +---u te-types:te-generic-node-id
          +-- global-source?     uint32
          +-- extended-id?       yang:hex-string
  grouping tunnel-end-point:
    +-- node-id?        nw:node-id
    +-- te-node-id?     te-types:te-node-id
    +-- tunnel-tp-id?   binary
  grouping tunnel-common-attributes:
    +-- source
    |  +---u tunnel-end-point
    +-- destination
    |  +---u tunnel-end-point
    +-- bidirectional?   boolean
  grouping tunnel-hierarchy-properties:
    +-- hierarchy
       +-- dependency-tunnels
       |  +-- dependency-tunnel* [name]
       |     +-- name?                                   tunnel-ref
       |     +---u te-types:encoding-and-switching-type
       +-- hierarchical-link
          +-- enable?                            boolean
          +-- local-node-id?                     nw:node-id
          +-- local-te-node-id?                  te-types:te-node-id
          +-- local-link-tp-id?                  nt:tp-id
          +-- local-te-link-tp-id?               te-types:te-tp-id
          +-- remote-node-id?                    nw:node-id
          +-- remote-link-tp-id?                 nt:tp-id
          +-- remote-te-link-tp-id?              te-types:te-tp-id
          +-- remote-te-node-id?                 te-types:te-node-id
          +--ro link-id?                           nt:link-id
          +-- network-id?                        nw:network-id
          +---u te-types:te-topology-identifier
  grouping path-constraints-common:
    +---u te-types:common-path-constraints-attributes
    +---u te-types:generic-path-disjointness
    +---u te-types:path-constraints-route-objects
    +-- path-in-segment!
    |  +---u te-types:label-set-info
    +-- path-out-segment!
       +---u te-types:label-set-info
]]>