Internet-Draft | TE YANG Data Model | February 2024 |
Saad, et al. | Expires 5 August 2024 | [Page] |
- Workgroup:
- TEAS Working Group
- Internet-Draft:
- draft-ietf-teas-yang-te-36
- Published:
- Intended Status:
- Standards Track
- Expires:
A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces
Abstract
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.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 August 2024.¶
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. Introduction
YANG [RFC6020] and [RFC7950] is a data modeling language that was introduced to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF [RFC6241]. YANG has proved relevant beyond its initial confines, as bindings to other interfaces (e.g. RESTCONF [RFC8040]) and encoding other than XML (e.g. JSON) are being defined. Furthermore, YANG data models can be used as the basis of implementation for other interfaces, such as CLI and programmatic APIs.¶
This document describes a YANG data model for Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The data model is divided into two YANG modules. The module 'ietf-te.yang' includes data that is generic and device-independent, while the module 'ietf-te-device.yang' includes data that is device-specific.¶
The document describes a high-level relationship between the modules defined in this document, as well as other external protocol YANG modules. The TE generic YANG data model does not include any data specific to a signaling protocol. It is expected other data plane technology model(s) will augment the TE generic YANG data model.¶
Also, it is expected other YANG modules that model TE signaling protocols, such as RSVP-TE ([RFC3209], [RFC3473]), or Segment-Routing TE (SR-TE) [RFC9256] will augment the generic TE YANG module.¶
2. Terms and Conventions
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
2.2. Terminology
The following terms are defined in [RFC6241] and are used in this specification:¶
This document also makes use of the following terminology introduced in the YANG Data Modeling Language [RFC7950]:¶
2.3. Prefixes in Data Node Names
In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in Table 1.¶
Prefix | YANG module | Reference |
---|---|---|
yang | ietf-yang-types | [RFC6991] |
inet | ietf-inet-types | [RFC6991] |
rt-types | ietf-routing-types | [RFC8294] |
te-types | ietf-te-types | [I-D.draft-ietf-teas-rfc8776-update] |
te-packet-types | ietf-te-packet-types | [I-D.draft-ietf-teas-rfc8776-update] |
te | ietf-te | this document |
te-dev | ietf-te-device | this document |
2.4. Model Tree Diagrams
The tree diagrams extracted from the module(s) defined in this document are given in subsequent sections as per the syntax defined in [RFC8340].¶
3. Design Considerations
This document describes a generic TE YANG 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 generic data model and possibly augment it with technology specific data.¶
The elements of the generic TE YANG data model, including TE Tunnels, LSPs, and interfaces have leaf(s) 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 generic TE YANG data model does not cover signaling protocol data. The signaling protocol used to instantiate TE LSPs are outside the scope of this document and expected to be covered by augmentations defined in other document(s).¶
The following other design considerations are taken into account with respect to data organization:¶
-
The generic TE YANG data model 'ietf-te' contains device independent data and can be used to model data off a device (e.g. on 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 device(s) that the TE controller manages.¶
-
The device-specific TE data is defined in module 'ietf-te-device' as shown in Figure 1.¶
-
In general, 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.¶
-
The model declares a number of TE functions as features that can be optionally supported.¶
3.1. State Data Organization
The Network Management Datastore Architecture (NMDA) [RFC8342] addresses modeling state data for ephemeral objects. This document adopts the NMDA model for configuration and state data representation as per IETF guidelines for new IETF YANG models.¶
4. Model Overview
The data models 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 feature(s) is expected to either be in augmentations, or deviations to this model that are defined in separate documents.¶
4.1. Module Relationship
The generic TE YANG data model that is defined in "ietf-te.yang" covers the building blocks that are device independent and agnostic of any specific technology or control plane instances. The TE device model defined in "ietf-te-device.yang" augments the generic TE YANG data model and covers data that is specific to a device -- for example, attributes of TE interfaces, or TE timers that are local to a TE node.¶
The TE data models for specific instances of data plane technology exist in separate YANG modules that augment the generic TE YANG data model. The TE data models for specific instances of signaling protocols are outside the scope of this document and are defined in other documents. For example, the RSVP-TE YANG model augmentation of the TE model is covered in a separate document.¶
5. TE YANG Model
The generic TE YANG module ('ietf-te') is meant for 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, SRLGs, etc.).¶
A full tree diagram of the TE model is shown in the Appendix in Figure 13.¶
5.1. 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. Below provides further descriptions of containers that exist under the 'te' top level container.¶
There are three further containers grouped under the 'te' container as shown in Figure 2 and described below.¶
globals:¶
-
The 'globals' container maintains the set of global TE attributes that can be applicable to TE Tunnels and interfaces.¶
tunnels:¶
-
The 'tunnels' container includes the list of TE Tunnels that are instantiated. Refer to Section 5.1.2 for further details on the properties of a TE Tunnel.¶
lsps:¶
-
The 'lsps' container includes the list of TE LSP(s) that are instantiated for TE Tunnels. Refer to Section 5.1.3 for further details on the properties of a TE LSP.¶
The model also contains two Remote Procedure Calls (RPCs) as shown in Figure 13 and described below.¶
tunnels-path-compute:¶
-
A 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 Section 5.1.2 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.¶
Figure 13 shows the relationships of these containers and RPCs within the 'ietf-te' module.¶
5.1.1. TE Globals
The 'globals' container covers properties that control a TE feature's behavior system-wide, and its respective state as shown in Figure 3 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 Shared Risk Link Groups (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 Figure 4:¶
-
-
-
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 [RFC3209].¶
-
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 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.¶
-
'route-object-include-exclude': a list of route entries to include or exclude route entry constraints for the path computation. 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 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.¶
-
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 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 considerations when crossing domains. This 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 considerations when crossing domains. The TE tunnel segment in this case is being stitched to the downstream TE tunnel segment.¶
-
-
5.1.2. TE Tunnels
The 'tunnels' container holds the list of TE Tunnels that are provisioned on ingress LER devices in the network as shown in Figure 5.¶
When the 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 device(s) 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 part of a multi-domain TE Tunnel that is within a specific network domain.¶
The TE Tunnel has a number of attributes that are set directly under the tunnel (as shown in Figure 5). The main attributes of a TE Tunnel are described below:¶
operational-state:¶
-
A YANG leaf that holds the operational state of the tunnel.¶
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 amongst 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 initiated TE Tunnels from the controller, the controller is responsible to ensures that TE Tunnel names are unique.¶
alias:¶
-
A YANG leaf that holds an alternate name to the TE tunnel. 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 amongst 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 on to the TE tunnel as described in [RFC9012].¶
admin-state:¶
-
A YANG leaf that holds the tunnel administrative state. The administrative status in state datastore transitions to 'tunnel-admin-up' when the tunnel used by the client layer, and to 'tunnel-admin-down' when it is not used by the client layer.¶
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 [RFC3945].¶
source/destination:¶
-
YANG containers that hold the tunnel source and destination node endpoints identities, including:¶
-
-
te-node-id: A YANG leaf that holds the identifier of the source or destination of the TE Tunnel TE node identifiers as defined in [I-D.draft-ietf-teas-rfc8776-update].¶
-
node-id: A YANG leaf that holds the identifier of the source or destination of the TE Tunnel node identifiers as defined in [RFC8345].¶
-
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 [RFC8795]. 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 [rfc3473].¶
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 module(s), for example, to add data for 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 [RFC8795].¶
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 [RFC8345].¶
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 [RFC6107]. 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 set of hierarchical TE Tunnels provisioned or to be provisioned in the immediate lower layer that this TE tunnel depends on for multi-layer path computation. A dependency TE Tunnel is provisioned if and only if it is used (selected by path computation) at least by one client layer TE Tunnel. The TE link in the client layer network topology supported by a dependent TE Tunnel is dynamically created only when the dependency TE Tunnel is actually provisioned.¶
-
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 path(s) reference path(s) 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 contains attributes similar to a 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 as soon as a valid path is computed. 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 a usual with the associated per path constraint(s) and properties on a device or TE controller. The device or TE controller computes the feasible path(s) 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 path(s) 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 reoptimized after a failure on any of its traversed links.¶
path-scope:¶
-
A YANG leaf that specifies the path scope if segment or an end-to-end path.¶
preference:¶
-
A YANG leaf that specifies the preference for the path. The lower the number higher the preference.¶
k-requested-paths:¶
-
A YANG leaf that specifies the number of k-shortest-paths requested from the path computation server and returned sorted by its optimization objective.¶
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 [I-D.draft-ietf-teas-rfc8776-update]).¶
link-protection:¶
-
A YANG leaf that specifies the link protection type required for the links to be included the computed path (see [I-D.draft-ietf-teas-rfc8776-update]).¶
setup/hold-priority:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
signaling-type:¶
-
see description provided in Section 5.1.1. This value overrides the provided one in the referenced named-path-constraint.¶
path-metric-bounds:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
path-affinities-values:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
path-affinity-names:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
path-srlgs-lists:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
path-srlgs-names:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
disjointness:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
explicit-route-objects:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
path-in-segment:¶
-
see description provided in Section 5.1.1. These values override those provided in the referenced named-path-constraint.¶
path-out-segment:¶
-
see description provided in Section 5.1.1. 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 a list of errors related to the 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.¶
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 compuation 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:¶
Note, unless overriden 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:¶
5.1.3. TE LSPs
The 'lsps' container includes the set of TE LSP(s) 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 LSP(s) 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 LSP(s) 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.¶
5.2. Tree Diagram
Figure 6 shows the tree diagram of depth=4 for the generic TE YANG model defined in modules 'ietf-te.yang'. The full tree diagram is shown in Section 13.¶
5.3. YANG Module
The generic TE YANG module 'ietf-te' imports the following modules:¶
-
ietf-te-types defined in [I-D.draft-ietf-teas-rfc8776-update]¶
-
ietf-network and ietf-network-topology defined in [RFC8345]¶
This module references the following documents: [RFC4206], [RFC4427], [RFC4872], [RFC3209], [RFC6780], [RFC7471], [RFC9012], [RFC8570], [RFC8232], [RFC7271], [RFC8234], [RFC7308], and [ITU_G.808.1].¶
6. TE Device YANG Model
The device TE YANG module ('ietf-te-device') models data that is specific to managing a TE device. This module augments the generic TE YANG module.¶
6.1. Module Structure
6.1.1. TE Interfaces
This branch of the model manages TE interfaces that are present on a device. Examples of TE interface properties are:¶
-
Maximum reservable bandwidth, bandwidth constraints (BC)¶
-
Flooding parameters¶
-
Flooding intervals and threshold values¶
-
-
Interface attributes¶
-
Fast reroute backup tunnel properties (such as static, auto-tunnel)¶
The derived state associated with interfaces is grouped under the interface "state" sub-container as shown in Figure 8. This covers state data such as:¶
-
Bandwidth information: maximum bandwidth, available bandwidth at different priorities and for each class-type (CT)¶
-
List of admitted LSPs¶
-
Name, bandwidth value and pool, time, priority¶
-
-
Statistics: state counters, flooding counters, admission counters (accepted/rejected), preemption counters¶
-
Adjacency information¶
6.2. Tree Diagram
Figure 9 shows the tree diagram of the device TE YANG model defined in modules 'ietf-te-device.yang'.¶
6.3. YANG Module
The device TE YANG module 'ietf-te-device' imports the following module(s):¶
-
ietf-te-types defined in [I-D.draft-ietf-teas-rfc8776-update]¶
-
ietf-te defined in this document¶
7. Notifications
Notifications are a key component of any topology data model.¶
[RFC8639] and [RFC8641] define a subscription mechanism and a push mechanism for YANG datastores. These mechanisms currently allow the user to:¶
8. IANA Considerations
This document registers the following URIs in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registrations are requested to be made.¶
URI: urn:ietf:params:xml:ns:yang:ietf-te Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-te-device Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
This document registers two YANG modules in the YANG Module Names registry [RFC6020].¶
Name: ietf-te Namespace: urn:ietf:params:xml:ns:yang:ietf-te Prefix: te Reference: RFCXXXX Name: ietf-te-device Namespace: urn:ietf:params:xml:ns:yang:ietf-te-device Prefix: te-device Reference: RFCXXXX¶
9. Security Considerations
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
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 to interruption to services carried over the network.¶
"/te/tunnels-path-compute": using this RPC, an attacker can retrieve secured information about the network provider which can be used to orchestrate further attacks.¶
The security considerations spelled out in the YANG 1.1 specification [RFC7950] apply for this document as well.¶
10. Acknowledgement
The authors would like to thank the members of the multi-vendor 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.¶
11. Contributors
Oscar Gonzalez de Dios Telefonica Email: oscar.gonzalezdedios@telefonica.com Himanshu Shah Ciena Email: hshah@ciena.com Xia Chen Huawei Technologies Email: jescia.chenxia@huawei.com Bin Wen Comcast Email: Bin_Wen@cable.comcast.com¶
12. Appendix A: Data Tree Examples
This section contains examples of use of the model with RESTCONF [RFC8040] and JSON encoding.¶
For the example we will use a 4 node MPLS network were RSVP-TE MPLS Tunnels can be setup. The loopbacks of each router are shown. The network in Figure 11 will be used in the examples described in the following sections.¶
12.1. 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.¶
POST /restconf/data/ietf-te:te/tunnels HTTP/1.1 Host: example.com Accept: application/yang-data+json Content-Type: application/yang-data+json { "ietf-te:tunnel": [ { "name": "Example_LSP_Tunnel_A_2", "encoding": "te-types:lsp-encoding-packet", "admin-state": "te-types:tunnel-state-up", "source": "192.0.2.1", "destination": "192.0.2.4", "bidirectional": "false", "signaling-type": "te-types:path-setup-rsvp" } ] }¶
12.2. Global Named Path Constraints
This example uses the YANG data model to create a 'named path constraint' that can be reference by TE Tunnels. The path constraint, in this case, limits the TE Tunnel hops for the computed path.¶
POST /restconf/data/ietf-te:te/globals/named-path-constraints HTTP/1.1 Host: example.com Accept: application/yang-data+json Content-Type: application/yang-data+json "ietf-te:named-path-constraint": { "name": "max-hop-3", "path-metric-bounds": { "path-metric-bound": { "metric-type": "te-types:path-metric-hop", "upper-bound": "3" } } } }¶
12.3. Tunnel with Global Path Constraint
In this example, the previously created 'named path constraint' is applied to the TE Tunnel created in Section 12.1.¶
POST /restconf/data/ietf-te:te/tunnels HTTP/1.1 Host: example.com Accept: application/yang-data+json Content-Type: application/yang-data+json { "ietf-te:ietf-tunnel": [ { "name": "Example_LSP_Tunnel_A_4_1", "encoding": "te-types:lsp-encoding-packet", "description": "Simple_LSP_with_named_path", "admin-state": "te-types:tunnel-state-up", "source": "192.0.2.1", "destination": "192.0.2.4", "signaling-type": "path-setup-rsvp", "primary-paths": [ { "primary-path": { "name": "Simple_LSP_1", "use-path-computation": "true", "named-path-constraint": "max-hop-3" } } ] } ] }¶
12.4. Tunnel with Per-tunnel Path Constraint
In this example, the a per tunnel path constraint is explicitly indicated under the TE Tunnel created in Section 12.1 to constrain the computed path for the tunnel.¶
POST /restconf/data/ietf-te:te/tunnels HTTP/1.1 Host: example.com Accept: application/yang-data+json Content-Type: application/yang-data+json { "ietf-te:tunnel": [ { "name": "Example_LSP_Tunnel_A_4_2", "encoding": "te-types:lsp-encoding-packet", "admin-state": "te-types:tunnel-state-up", "source": "192.0.2.1", "destination": "192.0.2.4", "signaling-type": "te-types:path-setup-rsvp", "primary-paths": { "primary-path": [ { "name": "path1", "path-metric-bounds": { "path-metric-bound": [ { "metric-type": "te-types:path-metric-hop", "upper-bound": "3" } ] } } ] } } ] }¶
12.5. Tunnel State
In this example, the 'GET' query is sent to return the state stored about the tunnel.¶
GET /restconf/data/ietf-te:te/tunnels + /tunnel="Example_LSP_Tunnel_A_4_1" /primary-paths/ HTTP/1.1 Host: example.com Accept: application/yang-data+json¶
The request, with status code 200 would include, for example, the following json:¶
{ "ietf-te:primary-paths": { "primary-path": [ { "name": "path1", "path-computation-method": "te-types:path-locally-computed", "computed-paths-properties": { "computed-path-properties": [ { "k-index": "1", "path-properties": { "path-route-objects": { "path-route-object": [ { "index": "1", "numbered-node-hop": { "node-id": "192.0.2.2" } }, { "index": "2", "numbered-node-hop": { "node-id": "192.0.2.4" } } ] } } } ] }, "lsps": { "lsp": [ { "tunnel-name": "Example_LSP_Tunnel_A_4_1", "node": "192.0.2.1 ", "lsp-id": "25356" } ] } } ] } }¶
12.6. Example TE Tunnel with Primary and Secondary Paths
Below is the state retrieved for a TE tunnel from source 192.0.2.1 to 192.0.2.5 with primary, secondary, reverse, and secondary reverse paths as shown in Figure 12.¶
{ "ietf-te:te": { "tunnels": { "tunnel": [ { "name": "example-1", "description": "Example in slide 1", "source": "192.0.2.1", "destination": "192.0.2.5", "bidirectional": false, "primary-paths": { "primary-path": [ { "name": "primary-1 (fwd)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.2", "hop-type": "loose" } } ] }, "primary-reverse-path": { "name": "primary-2 (rev)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.3", "hop-type": "loose" } } ] }, "candidate-secondary-reverse-paths": { "candidate-secondary-reverse-path": [ "secondary-3 (rev)", "secondary-4 (rev)", "secondary-5 (rev)" ] } }, "candidate-secondary-paths": { "candidate-secondary-path": [ "secondary-1 (fwd)", "secondary-2 (fwd)" ] } } ] }, "secondary-paths": { "secondary-path": [ { "name": "secondary-1 (fwd)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.1" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.2", "hop-type": "loose" } } ] } }, { "name": "secondary-2 (fwd)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.2" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.5", "hop-type": "loose" } } ] } } ] }, "secondary-reverse-paths": { "secondary-reverse-path": [ { "name": "secondary-3 (rev)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.5" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.4", "hop-type": "loose" } } ] } }, { "name": "secondary-4 (rev)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.4" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.3", "hop-type": "loose" } } ] } }, { "name": "secondary-5 (rev)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.3" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.1", "hop-type":"loose" } } ] } } ] } }, { "name": "example-3", "description": "Example in slide 3", "source": "192.0.2.1", "destination": "192.0.2.5", "bidirectional": true, "primary-paths": { "primary-path": [ { "name": "primary-1 (bidir)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.2", "hop-type": "loose" } } ] }, "candidate-secondary-paths": { "candidate-secondary-path": [ "secondary-1 (bidir)", "secondary-2 (bidir)" ] } } ] }, "secondary-paths": { "secondary-path": [ { "name": "secondary-1 (bidir)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.1" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.2", "hop-type": "loose" } } ] } }, { "name": "secondary-2 (bidir)", "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.2" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.5", "hop-type": "loose" } } ] } } ] } }, { "name": "example-4", "description": "Example in slide 4", "source": "192.0.2.1", "destination": "192.0.2.5", "bidirectional": false, "primary-paths": { "primary-path": [ { "name": "primary-1 (fwd)", "co-routed": [null], "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.2", "hop-type": "loose" } } ] }, "primary-reverse-path": { "name": "primary-2 (rev)", "candidate-secondary-reverse-paths": { "candidate-secondary-reverse-path": [ "secondary-3 (rev)", "secondary-4 (rev)" ] } }, "candidate-secondary-paths": { "candidate-secondary-path": [ "secondary-1 (fwd)", "secondary-2 (fwd)" ] } } ] }, "secondary-paths": { "secondary-path": [ { "name": "secondary-1 (fwd)", "co-routed": [null], "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.1" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.2", "hop-type": "loose" } } ] } }, { "name": "secondary-2 (fwd)", "co-routed": [null], "explicit-route-objects": { "route-object-include-exclude": [ { "index": 1, "explicit-route-usage" : "route-include-object", "numbered-node-hop": { "node-id": "192.0.2.2" } }, { "index": 2, "numbered-node-hop": { "node-id": "192.0.2.5", "hop-type": "loose" } } ] } } ] }, "secondary-reverse-paths": { "secondary-reverse-path": [ { "name": "secondary-3 (rev)" }, { "name": "secondary-4 (rev)" } ] } } ] } } }¶
13. Appendix B: Full Model Tree Diagram
Figure 13 shows the full tree diagram of the TE YANG model defined in module 'ietf-te.yang'.¶
14. References
14.1. Normative References
- [I-D.draft-ietf-teas-rfc8776-update]
- Busi, I., Guo, A., Liu, X., Saad, T., and I. Bryskin, "Common YANG Data Types for Traffic Engineering", Work in Progress, Internet-Draft, draft-ietf-teas-rfc8776-update-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-rfc8776-update-09>.
- [ITU_G.808.1]
- ITU-T Recommendation G.808.1, "Generic protection switching - Linear trail and subnetwork protection", ITU-T G.808.1 , .
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC3209]
- Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, , <https://www.rfc-editor.org/info/rfc3209>.
- [RFC3473]
- Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, , <https://www.rfc-editor.org/info/rfc3473>.
- [RFC3688]
- Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
- [RFC4206]
- Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, , <https://www.rfc-editor.org/info/rfc4206>.
- [RFC4427]
- Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, , <https://www.rfc-editor.org/info/rfc4427>.
- [RFC4872]
- Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, , <https://www.rfc-editor.org/info/rfc4872>.
- [RFC6020]
- Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, , <https://www.rfc-editor.org/info/rfc6020>.
- [RFC6107]
- Shiomoto, K., Ed. and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, DOI 10.17487/RFC6107, , <https://www.rfc-editor.org/info/rfc6107>.
- [RFC6241]
- Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
- [RFC6242]
- Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, , <https://www.rfc-editor.org/info/rfc6242>.
- [RFC6780]
- Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/RFC6780, , <https://www.rfc-editor.org/info/rfc6780>.
- [RFC6991]
- Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, , <https://www.rfc-editor.org/info/rfc6991>.
- [RFC7271]
- Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, DOI 10.17487/RFC7271, , <https://www.rfc-editor.org/info/rfc7271>.
- [RFC7308]
- Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10.17487/RFC7308, , <https://www.rfc-editor.org/info/rfc7308>.
- [RFC7471]
- Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, , <https://www.rfc-editor.org/info/rfc7471>.
- [RFC7950]
- Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
- [RFC8040]
- Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8232]
- Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, , <https://www.rfc-editor.org/info/rfc8232>.
- [RFC8234]
- Ryoo, J., Cheung, T., van Helvoort, H., Busi, I., and G. Wen, "Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode", RFC 8234, DOI 10.17487/RFC8234, , <https://www.rfc-editor.org/info/rfc8234>.
- [RFC8294]
- Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, , <https://www.rfc-editor.org/info/rfc8294>.
- [RFC8340]
- Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
- [RFC8341]
- Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, , <https://www.rfc-editor.org/info/rfc8341>.
- [RFC8342]
- Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, , <https://www.rfc-editor.org/info/rfc8342>.
- [RFC8343]
- Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, , <https://www.rfc-editor.org/info/rfc8343>.
- [RFC8345]
- Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, , <https://www.rfc-editor.org/info/rfc8345>.
- [RFC8446]
- Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
- [RFC8570]
- Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, , <https://www.rfc-editor.org/info/rfc8570>.
- [RFC8639]
- Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, , <https://www.rfc-editor.org/info/rfc8639>.
- [RFC8641]
- Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, , <https://www.rfc-editor.org/info/rfc8641>.
- [RFC8795]
- Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, , <https://www.rfc-editor.org/info/rfc8795>.
- [RFC9012]
- Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, , <https://www.rfc-editor.org/info/rfc9012>.
14.2. Informative References
- [rfc3473]
- Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, , <https://www.rfc-editor.org/info/rfc3473>.
- [RFC3945]
- Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, , <https://www.rfc-editor.org/info/rfc3945>.
- [RFC9256]
- Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, , <https://www.rfc-editor.org/info/rfc9256>.