|RFC 9070||YANG Data Model for MPLS LDP||March 2022|
|Raza, et al.||Standards Track||[Page]|
- Internet Engineering Task Force (IETF)
- Standards Track
YANG Data Model for MPLS LDP
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP). The model also serves as the base model to define the Multipoint LDP (mLDP) model.¶
The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
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.¶
The Network Configuration Protocol (NETCONF) [RFC6241] is one of the network management protocols that defines mechanisms to manage network devices. YANG [RFC6020] [RFC7950] is a modular language that represents data structures in an XML tree format and is used as a data modeling language for NETCONF.¶
The data model is defined for the following constructs that are used for managing the protocol:¶
This document is organized to define the data model for each of the above constructs in the sequence as listed above.¶
The configuration and state items are divided into the following two broad categories:¶
The "base" category contains the basic and fundamental features that are covered in LDP base specification [RFC5036] and constitute the minimum requirements for a typical base LDP deployment, whereas the "extended" category contains other non-base features. All the items in a base category are mandatory and, hence, no "if-feature" is allowed under the "base" category. The base and extended categories are defined in their own modules as described later.¶
The examples of a base feature include the configuration of LDP lsr-id, enabling LDP interfaces, setting passwords for LDP sessions, etc., whereas the examples of an extended feature include inbound/outbound label policies, IGP Sync [RFC5443], downstream on demand, etc. It is worth highlighting that LDP IPv6 [RFC7552] is also categorized as an extended feature.¶
While "base" model support will suffice for small deployments, it is expected that large deployments will require both "base" and "extended" model support from the vendors.¶
In this document, the word "IP" is used to refer to both IPv4 and IPv6 unless otherwise explicitly stated. For example, "IP address family" should be read as "IPv4 and/or IPv6 address family".¶
This document defines two new modules for LDP YANG support:¶
- A module that specifies the base LDP features and augments /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol defined in [RFC8349]. We define the new identity 'mpls-ldp' for LDP; the model allows only a single instance of 'mpls-ldp'.¶
- A module that specifies the extended LDP features and augments the base LDP module.¶
There are four types of containers in our module(s):¶
- Read-write parameters for configuration (Section 5)¶
- Read-only parameters for operational state (Section 6)¶
- Notifications for events (Section 7)¶
- RPCs for executing commands to perform some action (Section 8)¶
The modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [RFC8407]. When protocol states are retrieved from the NMDA operational state datastore, the returned states cover all "config true" (rw) and "config false" (ro) nodes defined in the schema.¶
The following diagram depicts high-level LDP YANG tree organization and hierarchy:¶
Before going into data model details, it is important to take note of the following points:¶
- This model aims to address only the core LDP parameters as per RFC specification, as well as well-known and widely deployed manageability controls (such as label filtering policies to apply filtering rules on the assignment, advertisement, and acceptance for label bindings). Any vendor-specific feature should be defined in a vendor-specific augmentation of this model.¶
- Multi-topology LDP [RFC7307] is beyond the scope of this document.¶
- This model does not cover any applications running on top of LDP, nor does it cover any Operations, Administration, and Maintenance (OAM) procedures for LDP.¶
- This model is a VRF-centric model. It is important to note that [RFC4364] defines VPN Routing and Forwarding (VRF) tables and default forwarding tables as different; however, from a YANG modeling perspective, this introduces unnecessary complications; hence, we are treating the default forwarding table as just another VRF.¶
- A "network-instance", as defined in [RFC8529], refers to a VRF instance (both default and non-default) within the scope of this model.¶
- This model supports two address families, namely, "ipv4" and "ipv6".¶
- This model assumes platform-wide label space (i.e., label space Id of zero). However, when upstream label assignment [RFC6389] is in use, an upstream assigned label is looked up in a Context-Specific Label Space as defined in [RFC5331].¶
- The label and peer policies (including filters) are defined using prefix-set and neighbor-set, respectively, as defined in the routing-policy model [RFC9067].¶
This model uses the terms LDP "neighbor/adjacency", "session", and "peer" with the following semantics:¶
- An LDP-enabled Label Switching Router (LSR) that is discovered through LDP discovery mechanisms.¶
- An LDP neighbor with whom a TCP connection has been established.¶
- An LDP session that has successfully progressed beyond its initialization phase and is either already exchanging the bindings or is ready to do so.¶
It is to be noted that LDP Graceful Restart (GR) mechanisms defined in [RFC3478] allow keeping the exchanged bindings for some time after a session goes down with a peer. We refer to such a state as belonging to a "stale" peer, i.e., keeping peer bindings from a peer with whom currently there is either no connection established or connection is established but the GR session is in recovery state. When used in this document, the above terms will refer strictly to the semantics and definitions defined for them.¶
While presenting the YANG tree view and actual specification, this document assumes readers are familiar with the concepts of YANG modeling, its presentation, and its compilation.¶
The following is a complete tree representation of configuration, state, notification, and RPC items under LDP base and extended modules.¶
This specification defines the configuration parameters for base LDP as specified in [RFC5036] and LDP IPv6 [RFC7552]. Moreover, it incorporates provisions to enable LDP Capabilities [RFC5561] and defines some of the most significant and commonly used capabilities such as Typed Wildcard FEC [RFC5918], End-of-LIB [RFC5919], and LDP Upstream Label Assignment [RFC6389].¶
The following is the high-level configuration organization for the base LDP module:¶
The following is the high-level configuration organization for the extended LDP module:¶
Given the configuration hierarchy, the model allows inheritance such that an item in a child tree is able to derive value from a similar or related item in one of the parents. For instance, Hello holdtime can be configured per VRF or per VRF interface, thus allowing inheritance as well flexibility to override with a different value at any child level.¶
The LDP module resides under a network-instance and the scope of any LDP configuration defined under this tree is per network-instance (per-VRF). This configuration is further divided into sub categories as follows:¶
- Global parameters¶
- Per-address-family parameters¶
- LDP Capabilities parameters¶
Hello Discovery parameters¶
- Forwarding parameters¶
The following subsections briefly explain these configuration areas.¶
There are configuration items that are available directly under a VRF instance and do not fall under any other subtree. An example of such a parameter is an LDP LSR Id that is typically configured per VRF. To keep legacy LDP features and applications working in an LDP IPv4 network with this model, this document recommends an operator to pick a routable IPv4 unicast address (within a routing domain) as an LSR Id.¶
This container falls under the global tree and holds the LDP capabilities that are to be enabled for certain features. By default, an LDP capability is disabled unless explicitly enabled. These capabilities are typically used to negotiate with LDP peer(s) the support/non-support related to a feature and its parameters. The scope of a capability enabled under this container applies to all LDP peers in the given VRF instance. There is also a peer-level capability container that is provided to override a capability that is enabled/specified at VRF level.¶
Any LDP configuration parameter related to an IP address family (AF) whose scope is VRF wide is configured under this tree. The examples of per-AF parameters include enabling LDP for an address family, prefix-list-based label policies, and LDP transport address.¶
This container is used to hold LDP configuration related to the Hello and discovery process for both basic (link) and extended (targeted) discovery.¶
The "interfaces" container is used to configure parameters related to VRF interfaces. There are parameters that apply to all interfaces (such as Hello timers) as well as parameters that can be configured per interface. Hence, an interface list is defined under the "interfaces" container. The model defines parameters to configure per-interface non-AF-related items as well as per-interface per-AF items. The example of the former is interface Hello timers, and an example of the latter is enabling hellos for a given AF under an interface.¶
The "targeted" container under a VRF instance allows for the configuration of parameters related to LDP targeted discovery. Within this container, the "target" list provides a means to configure multiple target addresses to perform extended discovery to a specific destination target, as well as to fine tune the per-target parameters.¶
This container is used to hold LDP configuration related to LDP sessions and peers under a VRF instance. This container allows for the configuration of parameters that either apply to all or a subset (peer-list) of peers in a given VRF. The example of such parameters includes authentication passwords, session KeepAlive (KA) timers, etc. Moreover, the model also allows per-peer parameter tuning by specifying a "peer" list under the "peers" container. A peer is uniquely identified by its LSR Id.¶
Like per-interface parameters, some per-peer parameters are AF agnostic (i.e., either non-AF related or apply to both IP address families), and some belong to an AF. The example of the former is per-peer session password configuration, whereas the example of the latter is prefix-lis-based label policies (inbound and outbound) that apply to a given peer.¶
This container is used to hold configuration used to control LDP forwarding behavior under a VRF instance. One example of a configuration under this container is when a user wishes to enable LDP neighbor discovery on an interface but wishes to disable use of the same interface for forwarding MPLS packets. This example configuration makes sense only when there are more than one LDP-enabled interfaces towards a neighbor.¶
The operational state of LDP can be queried and obtained from read-only state containers that fall under the same tree (/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol) as the configuration.¶
The following are main areas for which LDP operational state is defined:¶
Neighbor adjacencies are per-address-family Hello adjacencies that are formed with neighbors as a result of LDP basic or extended discovery. In terms of organization, there is a source of discovery (e.g., interface or target address) along with its associated parameters and one or more discovered neighbors along with neighbor-discovery-related parameters. For the basic discovery, there could be more than one discovered neighbor for a given source (interface), whereas there is at most one discovered neighbor for an extended discovery source (local-address and target-address). It is also to be noted that the reason for a targeted neighbor adjacency could be either an active source (locally configured targeted) or passive source (to allow any incoming extended/targeted hellos). A neighbor/adjacency record also contains session state that helps highlight whether a given adjacency has progressed to the subsequent session level or eventual peer level.¶
The following captures high-level tree hierarchy for neighbor adjacency state. The tree is shown for ipv4 address-family only; a similar tree exists for ipv6 address-family as well.¶
Peer-related state is presented under a peers tree. This is one of the core states that provides info on the session-related parameters (mode, authentication, KA timeout, etc.), TCP connection info, Hello adjacencies for the peer, statistics related to messages and bindings, and capabilities exchange info.¶
The following captures high-level tree hierarchy for peer state. The peer's Hello adjacencies tree is shown for ipv4 address-family only; a similar tree exists for ipv6 address-family as well.¶
Bindings state provides information on LDP FEC-Label bindings as well as address bindings for both inbound (received) as well as outbound (advertised) direction. FEC-Label bindings are presented in a FEC-centric view, and address bindings are presented in an address-centric view:¶
Note that all local addresses are advertised to all peers; hence, there is no need to provide per-peer information for local address advertisement. Furthermore, note that it is easy to derive a peer-centric view for the bindings from the information already provided in this model.¶
The following captures high-level tree hierarchy for bindings state. The tree shown below is for ipv4 address-family only; a similar tree exists for ipv6 address-family as well.¶
LDP capabilities state comprises two types of information: global information (such as timer, etc.) and per-peer information.¶
The following captures high-level tree hierarchy for LDP capabilities state.¶
This model defines a list of notifications to inform the client of important events detected during the protocol operation. These events include events related to changes in the operational state of an LDP peer, Hello adjacency, and FEC, etc. It is to be noted that an LDP FEC is treated as operational (up) as long as it has at least one Next Hop Label Forwarding Entry (NHLFE) with an outgoing label.¶
This model defines a list of rpcs that allow performing an action or executing a command on the protocol. For example, it allows for the clearing (resetting) of LDP peers, hello-adjacencies, and statistics. The model makes an effort to provide a different level of control so that a user is able to either clear all, clear all for a given type, or clear a specific entity.¶
The following sections specify the actual YANG (module) specification for LDP constructs defined earlier in the document.¶
This specification inherits the security considerations captured in [RFC5920] and the LDP protocol specification documents, namely base LDP [RFC5036], LDP IPv6 [RFC7552], LDP Capabilities [RFC5561], Typed Wildcard FEC [RFC5918], LDP End-of-LIB [RFC5919], and LDP Upstream Label Assignment [RFC6389].¶
The YANG modules specified in this document define 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 these YANG modules 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.¶
For LDP, the ability to modify MPLS LDP configuration may allow the entire MPLS LDP domain to be compromised including forming LDP adjacencies and/or peer sessions with unauthorized routers to mount a massive Denial-of-Service (DoS) attack. In particular, the following are the subtrees and data nodes that are sensitive and vulnerable:¶
- Adding LDP on any unprotected interface could allow an LDP Hello adjacency to be formed with an unauthorized and malicious neighbor. Once a Hello adjacency is formed, a peer session could progress with this neighbor.¶
- Allowing acceptance of targeted-hellos could open LDP to DoS attacks related to incoming targeted hellos from malicious sources.¶
- Allowing a peer session establishment is typically controlled via LDP authentication where a proper and secure authentication password/key management is warranted.¶
- Same as above.¶
Some of the readable data nodes in these YANG modules 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:¶
The exposure of LDP databases (such as Hello adjacencies, peers, address bindings, and FEC-Label bindings) beyond the scope of the LDP admin domain may be undesirable. The relevant subtrees and data nodes are as follows:¶
The configuration for LDP peer authentication is supported via the key-chain specification [RFC8177] or via direct specification of a key associated with a crypto algorithm (such as MD5). The relevant subtrees and data nodes are as follows:¶
The actual authentication key data (whether locally specified or part of a key-chain) is sensitive and needs to be kept secret from unauthorized parties. For key-chain-based authentication, this model inherits the security considerations of [RFC8040] (that includes the considerations with respect to the local storage and handling of authentication keys). A similar procedure for storage and access to direct keys is warranted.¶
Some of the RPC operations in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations; otherwise, control plane flaps, network outages, and DoS attacks are possible. The RPC operations are:¶
The model describes several notifications. The implementations must rate-limit the generation of these notifications to avoid creating significant notification load and possible side effects on the system stability.¶
- RFC 9070¶
- Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, DOI 10.17487/RFC3478, , <https://www.rfc-editor.org/info/rfc3478>.
- Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
- Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, , <https://www.rfc-editor.org/info/rfc5036>.
- Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, , <https://www.rfc-editor.org/info/rfc5331>.
- Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, , <https://www.rfc-editor.org/info/rfc5443>.
- Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, , <https://www.rfc-editor.org/info/rfc5561>.
- Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, , <https://www.rfc-editor.org/info/rfc5918>.
- Asati, R., Mohapatra, P., Chen, E., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, DOI 10.17487/RFC5919, , <https://www.rfc-editor.org/info/rfc5919>.
- Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, , <https://www.rfc-editor.org/info/rfc5920>.
- 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>.
- 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>.
- Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, , <https://www.rfc-editor.org/info/rfc6242>.
- Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, , <https://www.rfc-editor.org/info/rfc6389>.
- Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, , <https://www.rfc-editor.org/info/rfc6991>.
- Asati, R., Pignataro, C., Raza, K., Manral, V., and R. Papneja, "Updates to LDP for IPv6", RFC 7552, DOI 10.17487/RFC7552, , <https://www.rfc-editor.org/info/rfc7552>.
- Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
- Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
- Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, , <https://www.rfc-editor.org/info/rfc8177>.
- 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>.
- 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>.
- 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>.
- Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, , <https://www.rfc-editor.org/info/rfc8343>.
- Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, , <https://www.rfc-editor.org/info/rfc8344>.
- Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, , <https://www.rfc-editor.org/info/rfc8349>.
- Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, , <https://www.rfc-editor.org/info/rfc8407>.
- Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
- Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Data Model for Network Instances", RFC 8529, DOI 10.17487/RFC8529, , <https://www.rfc-editor.org/info/rfc8529>.
- Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data Model for Routing Policy", RFC 9067, DOI 10.17487/RFC9067, , <https://www.rfc-editor.org/info/rfc9067>.
- Raza, K., Ed., Liu, X., Esale, S., Andersson, L., Tantsura, J., and S. Krishnaswamy, "YANG Data Model for MPLS mLDP", Work in Progress, Internet-Draft, draft-ietf-mpls-mldp-yang-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mldp-yang-10>.
- Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, , <https://www.rfc-editor.org/info/rfc4364>.
- Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, DOI 10.17487/RFC7307, , <https://www.rfc-editor.org/info/rfc7307>.
- Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, , <https://www.rfc-editor.org/info/rfc7951>.
- Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
The corresponding operational state data for Router 203.0.113.1 could be as follows:¶
The authors would like to acknowledge Eddie Chami, Nagendra Kumar, Mannan Venkatesan, and Pavan Beeram for their contribution to this document.¶
We also acknowledge Ladislav Lhotka, Jan Lindblad, Tom Petch, Yingzhen Qu, and Benjamin Kaduk for their detailed review of the model during WG and IESG processes.¶