Internet-Draft | TE YANG Data Model | July 2022 |
Saad, et al. | Expires 12 January 2023 | [Page] |
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.¶
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 12 January 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
YANG [RFC6020] 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) [I-D.ietf-spring-segment-routing-policy] will augment the generic TE YANG module.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The 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]:¶
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 | [RFC8776] |
te-packet-types | ietf-te-packet-types | [RFC8776] |
te | ietf-te | this document |
te-dev | ietf-te-device | this document |
The tree diagrams extracted from the module(s) defined in this document are given in subsequent sections as per the syntax defined in [RFC8340].¶
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 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.¶
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.¶
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.¶
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 12.¶
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:¶
tunnels:¶
lsps:¶
The model also contains two Remote Procedure Calls (RPCs) as shown in Figure 12 and described below.¶
tunnels-path-compute:¶
tunnels-action:¶
Figure 12 shows the relationships of these containers and RPCs within the 'ietf-te' module.¶
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:¶
named-srlgs:¶
named-path-constraints:¶
explicit-route-objects-always: A YANG container that contains two route objects lists:¶
The 'tunnels' container holds the list of TE Tunnels that are provisioned on devices in the network as shown in Figure 5.¶
When the model is used to manage a specific device, the 'tunnels' list contains the TE Tunnels originating from the specific device. When the model is used to manage a TE controller, the 'tunnels' 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:¶
TE Path:¶
TE LSP:¶
TE Tunnel Segment:¶
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:¶
name:¶
alias:¶
identifier:¶
color:¶
admin-state:¶
operational-state:¶
encoding/switching:¶
source/destination:¶
src-tunnel-tp-id/dst-tunnel-tp-id:¶
bidirectional:¶
controller:¶
reoptimize-timer:¶
association-objects:¶
protection:¶
restoration:¶
te-topology-identifier:¶
hierarchy:¶
primary-paths:¶
secondary-paths:¶
secondary-reverse-paths:¶
The following set of common path attributes are shared for primary forward and reverse primary and secondary paths:¶
path-computation-method:¶
path-computation-server:¶
compute-only:¶
use-path-computation:¶
lockdown:¶
path-scope:¶
preference:¶
k-requested-paths:¶
association-objects:¶
optimizations:¶
named-path-constraint:¶
te-bandwidth:¶
link-protection:¶
setup/hold-priority:¶
signaling-type:¶
path-metric-bounds:¶
path-affinities-values:¶
path-affinity-names:¶
path-srlgs-lists:¶
path-srlgs-names:¶
disjointness:¶
explicit-route-objects-always:¶
path-in-segment:¶
path-out-segment:¶
computed-paths-properties: > A YANG container that holds properties for the list of computed paths.¶
computed-path-error-infos:¶
lsp-provisioning-error-infos:¶
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 all TE LSP(s) that traverse all network devices (including ingressing, transiting and egressing the device) that the TE controller manages.¶
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.¶
The generic TE YANG module 'ietf-te' imports the following modules:¶
This module references the following documents: [RFC6991], [RFC4875], [RFC7551], [RFC4206], [RFC4427], [RFC4872], [RFC3945], [RFC3209], [RFC6780], [RFC8800], [RFC5441], [RFC8685], [RFC5440], [RFC8306], [RFC5557], [RFC5520], [RFC7471], [RFC9012], [RFC8570], [RFC8232], and [RFC7308].¶
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.¶
This branch of the model manages TE interfaces that are present on a device. Examples of TE interface properties are:¶
Flooding parameters¶
Interface attributes¶
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:¶
List of admitted LSPs¶
Adjacency information¶
Figure 9 shows the tree diagram of the device TE YANG model defined in modules 'ietf-te-device.yang'.¶
The device TE YANG module 'ietf-te-device' imports the following module(s):¶
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:¶
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¶
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.¶
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.¶
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¶
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.¶
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": "10.0.0.1", "destination": "10.0.0.4", "signaling-type": "te-types:path-setup-rsvp" } ] }¶
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" } } } }¶
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": "10.0.0.1", "destination": "10.0.0.4", "signaling-type": "path-setup-rsvp", "primary-paths": [ { "primary-path": { "name": "Simple_LSP_1", "use-path-computation": "true", "named-path-constraint": "max-hop-3" } } ] } ] }¶
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": "10.0.0.1", "destination": "10.0.0.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" } ] } } ] } } ] }¶
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" /p2p-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": "10.0.0.2" } }, { "index": "2", "numbered-node-hop": { "node-id": "10.0.0.4" } } ] } } } ] }, "lsps": { "lsp": [ { "tunnel-name": "Example_LSP_Tunnel_A_4_1", "node": "10.0.0.1 ", "lsp-id": "25356" } ] } } ] } }¶
Figure 12 shows the full tree diagram of the TE YANG model defined in module 'ietf-te.yang'.¶