MPLS Working Group K. Raza Internet-Draft R. Rahman Intended status: Standards Track R. Asati Expires: April 21, 2016 Cisco Systems, Inc. X. Liu J. Tantsura Ericsson S. Esale Juniper Networks X. Chen L. Andersson Huawei Technologies H. Shah Ciena Corporation M. Bocci Alcatel-Lucent October 19, 2015 YANG Data Model for MPLS LDP and mLDP draft-raza-mpls-ldp-mldp-yang-02 Abstract This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP) and Multipoint LDP (mLDP). 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 http://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 April 21, 2016. Raza, et al. Expires April 21, 2016 [Page 1] Internet-Draft YANG Data Model for LDP and mLDP October 2015 Copyright Notice Copyright (c) 2015 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 3. LDP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Configuration Hierarchy . . . . . . . . . . . . . . . 11 3.2.2. All-VRFs Configuration . . . . . . . . . . . . . . . 14 3.3. Operational State . . . . . . . . . . . . . . . . . . . . 14 3.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. mLDP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. Configuration Hierarchy . . . . . . . . . . . . . . . 17 4.2.2. mldp container . . . . . . . . . . . . . . . . . . . 19 4.2.3. Leveraging LDP containers . . . . . . . . . . . . . . 19 4.2.4. YANG tree . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Operational State . . . . . . . . . . . . . . . . . . . . 23 4.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 24 4.5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. YANG Specification . . . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 65 9.2. Informative References . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 Additional Contributors . . . . . . . . . . . . . . . . . . . . . 69 Raza, et al. Expires April 21, 2016 [Page 2] Internet-Draft YANG Data Model for LDP and mLDP October 2015 1. Introduction The Network Configuration Protocol (NETCONF) [RFC6241] is a network management protocol that defines mechanisms to manage network devices. YANG [RFC6020] is a modular language that represents data structures in an XML tree format, and is used as a data modelling language for the NETCONF. This document introduces a YANG data model for MPLS Label Distribution Protocol (LDP) [RFC5036] and Multipoint LDP (mLDP) [RFC6388]. For LDP, it also covers LDP IPv6 [RFC7552] and LDP capabilities [RFC5561]. The data model is defined for following constructs that are used for managing the protocol: o Configuration o Operational State o Executables (Actions) o Notifications Given mLDP tight coupling with LDP, mLDP model is defined under LDP tree. The document is organized to first define the data model for the configuration, operational state, actions and notifications of LDP, followed by mLDP model in the same order. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In this document, the word "IP" is used to refer to both IPv4 and IPv6, unless otherwise explicitly stated. For example, "IP address family" means and be read as "IPv4 and/or IPv6 address family" 3. LDP YANG Model 3.1. Overview The LDP/mLDP Yang model is defined under "ietf-mpls-ldp" module and augments "mpls" list in ietf-mpls module [I-D.saad-mpls-static-yang] with LDP and mLDP specific parameters. There are four main containers in LDP module as follows: Raza, et al. Expires April 21, 2016 [Page 3] Internet-Draft YANG Data Model for LDP and mLDP October 2015 o Read-Write parameters (for configuration) o Read-only parameters (for operational state) o Notifications (for events) o RPCs (for executing commands to perform some action) For the configuration and state data, this model uses follows the approach described in [I-D.openconfig-netmod-opstate] to represent the configuration (intended state) and operational (applied and derived) state. This means that for each configuration leaf, there is an associated "state" leaf to represent the applied state. However, any (derived) state resulting from the configuration is kept under a separate "state" tree that augments MPLS routing-state tree. Before going into data model details, it is important to take note of the following points: o This module aims to address only the core LDP/mLDP parameters as per RFC specification, as well as some widely used and deployed non-RFC features. Any vendor specific feature should be defined in a vendor-specific augmentation of this model. o Multi-topology LDP [RFC7307] and Multi-topology mLDP [I-D.iwijnand-mpls-mldp-multi-topology] are beyond the scope of this document. o This module does not cover any applications running on top of LDP and mLDP, nor does it cover any OAM procedures for LDP and mLDP. o This model is a VPN Forwarding and Routing (VRF)-centric model and hence falls under an MPLS routing-instance. It is important to note that [RFC4364] defines VRF tables and default forwarding tables as different, however from a yang modelling perspective this introduces unnecessary complications, hence we are treating the default forwarding table as just another VRF. o A "routing-instance" refers to a VRF instance within the scope of this model. o This model supports two address-families, namely "ipv4" and "ipv6". o This model assumes platform-wide label space (i.e. label space Id of zero). Raza, et al. Expires April 21, 2016 [Page 4] Internet-Draft YANG Data Model for LDP and mLDP October 2015 o The label and neighbor policies and filters are typically defined using a prefix-list. The prefix-list is referenced from routing- policy model as defined in [I-D.shaikh-rtgwg-policy-model]. o The use of grouping (templates) for bundling and grouping the configuration items is not employed in current revision, and is a subject for consideration in future. A graphical representation of LDP YANG data model is presented in Figure 2, Figure 4, Figure 5, and Figure 6. Whereas, the actual model definition in YANG is captured in Section 5. 3.2. Configuration This specification defines the configuration parameters for base LDP as defined 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]. This specification supports VRF-centric configuration. For implementations that support protocol-centric configuration, with provision for inheritance and items that apply to all vrfs, we recommend an augmentation of this model such that any protocol- centric or all-vrf configuration is defined under their designated containers within the standard routing-instance (please see section Section 3.2.2) This model augments MPLS configuration as defined in MPLS base specification [I-D.saad-mpls-static-yang]. For LDP interfaces, this model still uses its own container and leaf, and is subject to alignment in future once MPLS interface model is solidified in MPLS base specification. Furthermore, as mentioned earlier, the configuration tree presents read-write intended configuration leave/ items as well as read-only state of the applied configuration. The former is listed under "config" container and latter under "state" container. Following is high-level configuration tree for LDP/mLDP: Raza, et al. Expires April 21, 2016 [Page 5] Internet-Draft YANG Data Model for LDP and mLDP October 2015 module: ietf-mpls-ldp +-- routing +-- routing-instance [name] +-- mpls +-- mpls-ldp . . Figure 1 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 parent. 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 on any child level. Following is a simplified graphical representation of the data model for LDP configuration, along with its applied state. module: ietf-mpls-ldp augment /rt:routing/rt:routing-instance/mpls:mpls: +--rw mpls-ldp! +--rw global | +--rw config | | +--rw capability | | | +--rw end-of-lib {capability-end-of-lib}? | | | | +--rw enable? boolean | | | +--rw typed-wildcard-fec {capability-typed-wildcard-fec}? | | | | +--rw enable? boolean | | | +--rw upstream-label-assignment {capability-upstream-label-assignment}? | | | | +--rw enable? boolean | | +--rw graceful-restart | | | +--rw enable? boolean | | | +--rw helper-enable? boolean {graceful-restart-helper-mode}? | | | +--rw reconnect-time? uint16 | | | +--rw recovery-time? uint16 | | | +--rw forwarding-holdtime? uint16 | | +--rw igp-synchronization-delay? uint16 | | +--rw lsr-id? yang:dotted-quad | | +--rw nonstop-routing? boolean | +--ro state | +--ro capability | | +--ro end-of-lib {capability-end-of-lib}? | | | +--ro enable? boolean | | +--ro typed-wildcard-fec {capability-typed-wildcard-fec}? | | | +--ro enable? boolean Raza, et al. Expires April 21, 2016 [Page 6] Internet-Draft YANG Data Model for LDP and mLDP October 2015 | | +--ro upstream-label-assignment {capability-upstream-label-assignment}? | | +--ro enable? boolean | +--ro graceful-restart | | +--ro enable? boolean | | +--ro helper-enable? boolean {graceful-restart-helper-mode}? | | +--ro reconnect-time? uint16 | | +--ro recovery-time? uint16 | | +--ro forwarding-holdtime? uint16 | +--ro igp-synchronization-delay? uint16 | +--ro lsr-id? yang:dotted-quad | +--ro nonstop-routing? boolean +--rw address-family* [af] | +--rw af address-family-type | +--rw config | | +--rw enable? boolean | | +--rw label-policy | | | +--rw independent-mode | | | | +--rw assign {policy-label-assignment-config}? | | | | | +--rw (prefix-option)? | | | | | +--:(prefix-list) | | | | | | +--rw prefix-list? prefix-list-ref | | | | | +--:(host-routes-only) | | | | | +--rw host-routes-only? boolean | | | | +--rw advertise | | | | | +--rw explicit-null! | | | | | | +--rw prefix-list? prefix-list-ref | | | | | +--rw prefix-list? prefix-list-ref | | | | +--rw accept | | | | +--rw prefix-list? prefix-list-ref | | | +--rw ordered-mode {policy-ordered-label-config}? | | | +--rw egress-lsr | | | | +--rw prefix-list? prefix-list-ref | | | +--rw advertise | | | | +--rw prefix-list? prefix-list-ref | | | +--rw accept | | | +--rw prefix-list? prefix-list-ref | | +--rw ipv4 | | | +--rw transport-address? inet:ipv4-address | | +--rw ipv6 | | +--rw transport-address? inet:ipv6-address | +--ro state | +--ro enable? boolean | +--ro label-policy | | +--ro independent-mode | | | +--ro assign {policy-label-assignment-config}? | | | | +--ro (prefix-option)? | | | | +--:(prefix-list) | | | | | +--ro prefix-list? prefix-list-ref Raza, et al. Expires April 21, 2016 [Page 7] Internet-Draft YANG Data Model for LDP and mLDP October 2015 | | | | +--:(host-routes-only) | | | | +--ro host-routes-only? boolean | | | +--ro advertise | | | | +--ro explicit-null! | | | | | +--ro prefix-list? prefix-list-ref | | | | +--ro prefix-list? prefix-list-ref | | | +--ro accept | | | +--ro prefix-list? prefix-list-ref | | +--ro ordered-mode {policy-ordered-label-config}? | | +--ro egress-lsr | | | +--ro prefix-list? prefix-list-ref | | +--ro advertise | | | +--ro prefix-list? prefix-list-ref | | +--ro accept | | +--ro prefix-list? prefix-list-ref | +--ro ipv4 | | +--ro transport-address? inet:ipv4-address | +--ro ipv6 | +--ro transport-address? inet:ipv6-address +--rw discovery | +--rw interfaces | | +--rw config | | | +--rw hello-holdtime? uint16 | | | +--rw hello-interval? uint16 | | +--ro state | | | +--ro hello-holdtime? uint16 | | | +--ro hello-interval? uint16 | | +--rw interface* [interface] | | +--rw interface if:interface-ref | | +--rw config | | | +--rw hello-holdtime? uint16 | | | +--rw hello-interval? uint16 | | | +--rw igp-synchronization-delay? uint16 {per-interface-timer-config}? | | +--ro state | | | +--ro hello-holdtime? uint16 | | | +--ro hello-interval? uint16 | | | +--ro igp-synchronization-delay? uint16 {per-interface-timer-config}? | | +--rw address-family* [af] | | +--rw af address-family-type | | +--rw config | | | +--rw enable? boolean | | | +--rw ipv4 | | | | +--rw transport-address? union | | | +--rw ipv6 | | | +--rw transport-address? union | | +--ro state | | +--ro enable? boolean | | +--ro ipv4 Raza, et al. Expires April 21, 2016 [Page 8] Internet-Draft YANG Data Model for LDP and mLDP October 2015 | | | +--ro transport-address? union | | +--ro ipv6 | | +--ro transport-address? union | +--rw targeted | +--rw config | | +--rw hello-holdtime? uint16 | | +--rw hello-interval? uint16 | | +--rw hello-accept {policy-extended-discovery-config}? | | +--rw enable? boolean | | +--rw peer-list? peer-list-ref | +--ro state | | +--ro hello-holdtime? uint16 | | +--ro hello-interval? uint16 | | +--ro hello-accept {policy-extended-discovery-config}? | | +--ro enable? boolean | | +--ro peer-list? peer-list-ref | +--rw address-family | +--rw ipv4 | | +--rw target* [address] | | +--rw address inet:ipv4-address | | +--rw config | | | +--rw enable? boolean | | +--ro state | | +--ro enable? boolean | +--rw ipv6 | +--rw target* [address] | +--rw address inet:ipv6-address | +--rw config | | +--rw enable? boolean | +--ro state | +--ro enable? boolean +--rw forwarding-nexthop {forwarding-nexthop-config}? | +--rw interfaces | +--rw interface* [interface] | +--rw interface if:interface-ref | +--rw address-family* [af] | +--rw af address-family-type | +--rw config | | +--rw ldp-disable? boolean | +--ro state | +--ro ldp-disable? boolean +--rw neighbors +--rw config | +--rw md5-password? string | +--rw session-ka-holdtime? uint16 | +--rw session-ka-interval? uint16 | +--rw session-downstream-on-demand {session-downstream-on-demand-config}? | | +--rw enable? boolean Raza, et al. Expires April 21, 2016 [Page 9] Internet-Draft YANG Data Model for LDP and mLDP October 2015 | | +--rw peer-list? peer-list-ref | +--rw session-protection {session-protection}? | +--rw enable? boolean | +--rw duration? union | +--rw peer-list? peer-list-ref +--ro state | +--ro md5-password? string | +--ro session-ka-holdtime? uint16 | +--ro session-ka-interval? uint16 | +--ro session-downstream-on-demand {session-downstream-on-demand-config}? | | +--ro enable? boolean | | +--ro peer-list? peer-list-ref | +--ro session-protection {session-protection}? | +--ro enable? boolean | +--ro duration? union | +--ro peer-list? peer-list-ref +--rw neighbor* [lsr-id] +--rw lsr-id union +--rw config | +--rw admin-down? boolean | +--rw capability | +--rw md5-password? string | +--rw graceful-restart | | +--rw enable? boolean | | +--rw reconnect-time? uint16 | | +--rw recovery-time? uint16 | +--rw session-ka-holdtime? uint16 | +--rw session-ka-interval? uint16 | +--rw session-protection {session-protection}? | | +--rw enable? boolean | | +--rw duration? union | +--rw address-family | +--rw ipv4 | | +--rw label-policy | | +--rw advertise | | | +--rw prefix-list? prefix-list-ref | | +--rw accept | | +--rw prefix-list? prefix-list-ref | +--rw ipv6 | +--rw label-policy | +--rw advertise | | +--rw prefix-list? prefix-list-ref | +--rw accept | +--rw prefix-list? prefix-list-ref +--ro state +--ro admin-down? boolean +--ro capability +--ro md5-password? string Raza, et al. Expires April 21, 2016 [Page 10] Internet-Draft YANG Data Model for LDP and mLDP October 2015 +--ro graceful-restart | +--ro enable? boolean | +--ro reconnect-time? uint16 | +--ro recovery-time? uint16 +--ro session-ka-holdtime? uint16 +--ro session-ka-interval? uint16 +--ro session-protection {session-protection}? | +--ro enable? boolean | +--ro duration? union +--ro address-family +--ro ipv4 | +--ro label-policy | +--ro advertise | | +--ro prefix-list? prefix-list-ref | +--ro accept | +--ro prefix-list? prefix-list-ref +--ro ipv6 +--ro label-policy +--ro advertise | +--ro prefix-list? prefix-list-ref +--ro accept +--ro prefix-list? prefix-list-ref Figure 2 3.2.1. Configuration Hierarchy The LDP configuration container is logically divided into following high-level config areas: Raza, et al. Expires April 21, 2016 [Page 11] Internet-Draft YANG Data Model for LDP and mLDP October 2015 Per-VRF parameters o Global parameters o Per-address-family parameters o LDP Capabilities parameters o Hello Discovery parameters - interfaces - Per-interface: Global Per-address-family - targeted - Per-target o Neighbor parameters - Global - Per-neighbor Per-address-family Capabilities parameters o Forwarding parameters Figure 3 Following subsections briefly explain these configuration areas. 3.2.1.1. Per-VRF parameters LDP module resides under an MPLS routing-instance and the scope of any LDP configuration defined under this tree is per routing-instance (per-VRF). This configuration is further divided into sub categories as follows. 3.2.1.1.1. Per-VRF global parameters There are configuration items that are available directly under a VRF instance and do not fall under any other sub tree. Example of such a parameter is LDP lsr-id that is typically configured per VRF. 3.2.1.1.2. Per-VRF Capabilities parameters This container falls under 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 neighbors in the given VRF instance. There is also a per-neighbor level capability container that is provided to override a capability that is enabled/specified at VRF level. Raza, et al. Expires April 21, 2016 [Page 12] Internet-Draft YANG Data Model for LDP and mLDP October 2015 3.2.1.1.3. Per-VRF Per-Address-Family parameters Any LDP configuration parameter related to IP address family (AF) whose scope is VRF wide is configured under this tree. The examples of per-AF parameters include enabling the AF, prefix-list based label policies, and LDP transport address. 3.2.1.1.4. Per-VRF Hello Discovery parameters This container is used to hold LDP configuration related to Hello and discovery process for both basic (link) and extended (targeted) discovery. The "interfaces" is a container 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 "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 former is interface hello timers, and example of latter is enabling hellos for a given AF under an interface. [TODO: Align with MPLS base interface model once MPLS base gets matured] The "targeted" container under a VRF instance allows to configure LDP targeted discovery related parameters. Within this container, the "target" list provides a mean to configure multiple target addresses to perform extended discovery to a specific destination target, as well as to fine tune parameters per-target. 3.2.1.1.5. Per-VRF Neighbor parameters This container is used to hold LDP configuration related to LDP neighbors (i.e. peers) under a VRF instance. This container allows to configure parameters that either apply on VRF's all neighbors or a subset (peer-list) of VRF neighbors. The example of such parameters include authentication password, session KA timers etc. Moreover, the model also allows per-neighbor parameter tuning by specifying a "neighbor" list under the "neighbors" container. A neighbor is uniquely identified using its LSR Id and hence lsr-id is the key for neighbor list Like per-interface parameters, some per-neighbor parameters are AF- agnostic (i.e. either non AF related or apply to both IP address families), and some that belong to an AF. The example of former is per-neighbor password configuration, whereas the example of latter is prefix-list based label policies (inbound and outbound) that apply to a given neighbor. Raza, et al. Expires April 21, 2016 [Page 13] Internet-Draft YANG Data Model for LDP and mLDP October 2015 3.2.1.1.6. Per-VRF Forwarding parameters 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 neighbor discovery on an interface but wishes to disable use of the same interface as forwarding nexthop. This example configuration makes sense only when there are more than one LDP enabled interfaces towards the neighbor. 3.2.2. All-VRFs Configuration TODO. 3.3. Operational State Operational state of LDP can be queried and obtained from this read- only container "mpls-ldp" which is augmented from "routing-state" of MPLS tree (/rt:routing-state/rt:routing-instance/mpls:mpls). Please note that "applied" state of a configuration item is already captured under configuration tree. This state tree only refers to the "derived" state related to the protocol. Following is a simplified graphical representation of the data model for LDP derived operational state. module: ietf-mpls-ldp augment /rt:routing-state/rt:routing-instance/mpls:mpls: +--ro mpls-ldp +-- ... +-- ... [Ed note: TODO (later revision)] Figure 4 3.4. Notifications This model defines a list of notifications to inform client of important events detected during the protocol operation. These events include events related to changes in the operational state of an LDP neighbor, 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 1 NHLFE with outgoing label. Raza, et al. Expires April 21, 2016 [Page 14] Internet-Draft YANG Data Model for LDP and mLDP October 2015 Following is a simplified graphical representation of the data model for LDP notifications. module: ietf-mpls-ldp notifications: +---n mpls-ldp-neighbor-event | +--ro event-type? oper-status-event-type | +--ro routing-instance-ref? rt:routing-instance-ref | +--ro neighbor-ref? leafref +---n mpls-ldp-adjacency-event | +--ro event-type? oper-status-event-type | +--ro routing-instance-ref? rt:routing-instance-ref | +--ro (adjacency-type)? | +--:(targeted) | | +--ro targeted | | +--ro target-address? inet:ip-address | +--:(link) | +--ro link | +--ro next-hop-interface? if:interface-ref | +--ro next-hop-address? inet:ip-address +---n mpls-ldp-fec-event +--ro event-type? oper-status-event-type +--ro routing-instance-ref? rt:routing-instance-ref +--ro prefix? inet:ip-prefix Figure 5 3.5. Actions This model defines a list of rpcs that allow performing an action or executing a command on the protocol. For example, it allows to clear (reset) LDP neighbors, hello-adjacencies, and statistics. The model makes an effort to provide different level of control so that a user is able to either clear all, or clear all of a given type, or clear a specific entity. Following is a simplified graphical representation of the data model for LDP actions. Raza, et al. Expires April 21, 2016 [Page 15] Internet-Draft YANG Data Model for LDP and mLDP October 2015 module: ietf-mpls-ldp rpcs: +---x mpls-ldp-clear-neighbor | +---w input | +---w routing-instance-ref? rt:routing-instance-ref | +---w lsr-id? union +---x mpls-ldp-clear-adjacency | +---w input | +---w routing-instance-ref? rt:routing-instance-ref | +---w adjacency | +---w (adjacency-type)? | +--:(targeted) | | +---w targeted! | | +---w target-address? inet:ip-address | +--:(link) | +---w link! | +---w next-hop-interface? if:interface-ref | +---w next-hop-address? inet:ip-address +---x mpls-ldp-clear-neighbor-statistics +---w input +---w routing-instance-ref? rt:routing-instance-ref +---w lsr-id? union Figure 6 4. mLDP YANG Model 4.1. Overview Due to tight dependency of mLDP on LDP, mLDP model builds on top of LDP model defined earlier in the document. Following are the main mLDP areas and documents that are within the scope of this model: o mLDP Base Specification [RFC6388] o mLDP Recursive FEC [RFC6512] o Targeted mLDP [RFC7060] o mLDP Fast-Reroute (FRR) * Node Protection [I-D.ietf-mpls-mldp-node-protection] * Multicast-only o Hub-and-Spoke Multipoint LSPs [RFC7140] Raza, et al. Expires April 21, 2016 [Page 16] Internet-Draft YANG Data Model for LDP and mLDP October 2015 o mLDP Inband Signaling [RFC6826] (future revision) o mLDP Inband Signaling with Wildcards [RFC7438] (future revision) o Configured Leaf LSPs (manually provisioned) [Ed Note: Some of the topics in the above list are to be addressed/ added in later revision of this document]. 4.2. Configuration 4.2.1. Configuration Hierarchy In terms of overall configuration layout, following figure highlights extensions to LDP configuration model to incorporate mLDP: Raza, et al. Expires April 21, 2016 [Page 17] Internet-Draft YANG Data Model for LDP and mLDP October 2015 +-- mpls-ldp +-- ... +-- ... +-- mldp | +-- ... | +-- ... | +-- address-family* [af] | +-- af | +-- ... | +-- ... +-- global | +-- ... | +-- capability | +-- ... | +-- ... | +-- mldp | +-- ... | +-- ... +-- discovery | +-- ... | +-- ... +-- forwarding-nexthop | +-- interfaces | +-- interface* [interface] | +-- interface | +-- address-family* [af] | +-- af | +-- ... | +-- mldp-disable +-- neighbors +-- ... +-- ... +-- neighbor* [lsr-id] +-- ... +-- ... +-- capability +-- ... +-- ... +-- mldp +-- ... +-- ... Figure 7 From above hierarchy, we can categorize mLDP configuration parameters into two types: o Parameters that leverage/extend LDP containers and parameters Raza, et al. Expires April 21, 2016 [Page 18] Internet-Draft YANG Data Model for LDP and mLDP October 2015 o Parameters that are mLDP specific Following subsections first describe mLDP specific configuration parameters, followed by those leveraging LDP. 4.2.2. mldp container mldp container resides directly under "mpls-ldp" and holds the configuration related to items that are mLDP specific. The main items under this container are: o mLDP enabling: To enable mLDP under a (VRF) routing instance, mldp container is enabled under LDP. Given that mLDP requires LDP signalling, it is not sensible to allow disabling LDP control plane under a (VRF) routing-instance while requiring mLDP to be enabled for the same. However, if a user wishes only to allow signalling for multipoint FECs on an LDP/mLDP enabled VRF instance, he/she can use LDP label-policies to disable unicast FECs under the VRF. o mLDP per-AF features: mLDP manages its own list of IP address- families and the features enabled underneath. The per-AF mLDP configuration items include: * Multicast-only FRR: This enables Multicast-only FRR functionality for a given AF under mLDP. The feature allows route-policy to be configured for finer control/applicability of the feature. * Recursive FEC: The recursive-fec feature [RFC6512] can be enabled per AF with a route-policy. * Configured Leaf LSPs: To provision multipoint leaf LSP manually, a container is provided per-AF under LDP. The configuration is flexible and allows a user to specify MP LSPs of type p2mp or mp2mp with IPv4 or IPv6 root address(es) by using either LSP-Id or (S,G). Targeted mLDP feature specification [RFC7060] do not require any mLDP specific configuration. It, however, requires LDP upstream-label- assignment capability to be enabled. 4.2.3. Leveraging LDP containers mLDP configuration model leverages following configuration areas and containers that are already defined for LDP: Raza, et al. Expires April 21, 2016 [Page 19] Internet-Draft YANG Data Model for LDP and mLDP October 2015 o Capabilities: A new container "mldp" is defined under Capabilities container. This new container specifies any mLDP specific capabilities and their parameters. Moreover, a new "mldp" container is also added under per-neighbor capability container to override/control mLDP specific capabilities on a neighbor level. In the scope of this document, the most important capabilities related to mLDP are p2mp, mp2mp, make-before-break, hub-and-spoke, and node-protection. o Discovery and Neighbor: mLDP requires LDP discovery and neighbor procedures to form mLDP peering. A neighbor is treated as mLDP neighbor only when either P2MP or MP2MP capabilities have been successfully exchanged with the peer. If a user wish to selectively enable or disable mLDP with a mLDP-enabled peer, he/ she may use per-neighbor mLDP capabilities configuration. [Ed Note: The option to control mLDP enabling/disabling on a neighbor- list is being explored for future ]. In most common deployments, it is desirable to disable mLDP (capabilities announcements) on a targeted-only LDP session, where targeted-only session is the one whose discovery sources are targeted only. In future revision, a configuration option for this support will also be provided. o Forwarding: By default, mLDP is allowed to select any of the LDP enabled interface as a downstream interface towards a nexthop (LDP/mLDP peer) for MP LSP programming. However, a configuration option is provided to allow mLDP to exclude a given interface from such a selection. Note that such a configuration option will be useful only when there are more than one interfaces available for the downstream selection. This goes without saying that mLDP configuration tree follows the same approach as LDP, where the tree comprise leafs for intended configuration as well their applied state. 4.2.4. YANG tree The following figure captures the YANG tree for mLDP configuration. The figure has been simplified to display only mLDP items and not LDP items to keep the focus. module: ietf-mpls-ldp augment /rt:routing/rt:routing-instance/mpls:mpls: +--rw mpls-ldp! +--rw global | +--rw config | | +--rw capability | | +--rw mldp {mldp}? Raza, et al. Expires April 21, 2016 [Page 20] Internet-Draft YANG Data Model for LDP and mLDP October 2015 | | +--rw p2mp | | | +--rw enable? boolean | | +--rw mp2mp | | | +--rw enable? boolean | | +--rw make-before-break | | | +--rw enable? boolean | | | +--rw switchover-delay? uint16 | | | +--rw timeout? uint16 | | +--rw hub-and-spoke {capability-mldp-hsmp}? | | | +--rw enable? boolean | | +--rw node-protection {capability-mldp-node-protection}? | | +--rw plr? boolean | | +--rw merge-point | | +--rw enable? boolean | | +--rw targeted-session-teardown-delay? uint16 | +--ro state | +--ro capability | +--ro mldp {mldp}? | +--ro p2mp | | +--ro enable? boolean | +--ro mp2mp | | +--ro enable? boolean | +--ro make-before-break | | +--ro enable? boolean | | +--ro switchover-delay? uint16 | | +--ro timeout? uint16 | +--ro hub-and-spoke {capability-mldp-hsmp}? | | +--ro enable? boolean | +--ro node-protection {capability-mldp-node-protection}? | +--ro plr? boolean | +--ro merge-point | +--ro enable? boolean | +--ro targeted-session-teardown-delay? uint16 +--rw mldp {mldp}? | +--rw config | | +--rw enable? boolean | +--ro state | | +--ro enable? boolean | +--rw address-family* [af] | +--rw af address-family-type | +--rw config | | +--rw multicast-only-frr {mldp-mofrr}? | | | +--rw prefix-list? prefix-list-ref | | +--rw recursive-fec | | +--rw prefix-list? prefix-list-ref | +--ro state | | +--ro multicast-only-frr {mldp-mofrr}? | | | +--ro prefix-list? prefix-list-ref Raza, et al. Expires April 21, 2016 [Page 21] Internet-Draft YANG Data Model for LDP and mLDP October 2015 | | +--ro recursive-fec | | +--ro prefix-list? prefix-list-ref | +--rw configured-leaf-lsps | +--rw p2mp | | +--rw roots-ipv4 | | | +--rw root* [root-addr] | | | +--rw root-addr inet:ipv4-address | | | +--rw lsp* [lsp-id source-addr group-addr] | | | +--rw lsp-id uint16 | | | +--rw source-addr inet:ipv4-address-no-zone | | | +--rw group-addr inet:ipv4-address-no-zone | | +--rw roots-ipv6 | | +--rw root* [root-addr] | | +--rw root-addr inet:ipv6-address | | +--rw lsp* [lsp-id source-addr group-addr] | | +--rw lsp-id uint16 | | +--rw source-addr inet:ipv6-address-no-zone | | +--rw group-addr inet:ipv6-address-no-zone | +--rw mp2mp | +--rw roots-ipv4 | | +--rw root* [root-addr] | | +--rw root-addr inet:ipv4-address | | +--rw lsp* [lsp-id source-addr group-addr] | | +--rw lsp-id uint16 | | +--rw source-addr inet:ipv4-address-no-zone | | +--rw group-addr inet:ipv4-address-no-zone | +--rw roots-ipv6 | +--rw root* [root-addr] | +--rw root-addr inet:ipv6-address | +--rw lsp* [lsp-id source-addr group-addr] | +--rw lsp-id uint16 | +--rw source-addr inet:ipv6-address-no-zone | +--rw group-addr inet:ipv6-address-no-zone +--rw forwarding-nexthop {forwarding-nexthop-config}? | +--rw interfaces | +--rw interface* [interface] | +--rw interface if:interface-ref | +--rw address-family* [af] | +--rw af address-family-type | +--rw config | | +--rw mldp-disable? boolean {mldp}? | +--ro state | +--ro mldp-disable? boolean {mldp}? +--rw neighbors +--rw neighbor* [lsr-id] +--rw lsr-id union +--rw config | +--rw capability Raza, et al. Expires April 21, 2016 [Page 22] Internet-Draft YANG Data Model for LDP and mLDP October 2015 | +--rw mldp {mldp}? | +--rw p2mp | | +--rw enable? boolean | +--rw mp2mp | | +--rw enable? boolean | +--rw make-before-break | | +--rw enable? boolean | | +--rw switchover-delay? uint16 | | +--rw timeout? uint16 | +--rw hub-and-spoke {capability-mldp-hsmp}? | | +--rw enable? boolean | +--rw node-protection {capability-mldp-node-protection}? | +--rw plr? boolean | +--rw merge-point | +--rw enable? boolean | +--rw targeted-session-teardown-delay? uint16 +--ro state +--ro capability +--ro mldp {mldp}? +--ro p2mp | +--ro enable? boolean +--ro mp2mp | +--ro enable? boolean +--ro make-before-break | +--ro enable? boolean | +--ro switchover-delay? uint16 | +--ro timeout? uint16 +--ro hub-and-spoke {capability-mldp-hsmp}? | +--ro enable? boolean +--ro node-protection {capability-mldp-node-protection}? +--ro plr? boolean +--ro merge-point +--ro enable? boolean +--ro targeted-session-teardown-delay? uint16 Figure 8 4.3. Operational State Operational state of mLDP can be queried and obtained from this read- only container "mldp" which resides under mpls-ldp container. Please note that "applied" state of an mLDP configuration item is already captured under mldp configuration tree. This mldp state tree only refers to the "derived" state related to mLDP protocol. Following is a simplified graphical representation of the data model for mLDP derived operational state. Raza, et al. Expires April 21, 2016 [Page 23] Internet-Draft YANG Data Model for LDP and mLDP October 2015 module: ietf-mpls-ldp augment /rt:routing-state/rt:routing-instance/mpls:mpls: +--ro mpls-ldp +-- ro mldp +-- ... [Ed note: TODO (later revision)] Figure 9 4.4. Notifications mLDP notification module consists of notification related to changes in the operational state of an mLDP FEC. Following is a simplified graphical representation of the data model for mLDP notifications: module: ietf-mpls-ldp notifications: +---n mpls-mldp-fec-event +--ro event-type? oper-status-event-type +--ro routing-instance-ref? rt:routing-instance-ref +--ro tree-type? multipoint-type +--ro root? inet:ip-address +--ro (lsp-key-type)? +--:(lsp-id-based) | +--ro lsp-id? uint16 +--:(source-group-based) +--ro source-addr? inet:ip-address +--ro group-addr? inet:ip-address Figure 10 4.5. Actions Currently, no RPCs/actions are defined for mLDP. 5. YANG Specification Following are actual YANG definition for LDP and mLDP constructs defined earlier in the document. file "ietf-mpls-ldp@2015-10-19.yang" --> Raza, et al. Expires April 21, 2016 [Page 24] Internet-Draft YANG Data Model for LDP and mLDP October 2015 module ietf-mpls-ldp { namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-ldp"; // replace with IANA namespace when assigned prefix ldp; import ietf-inet-types { prefix "inet"; } import ietf-yang-types { prefix "yang"; } import ietf-interfaces { prefix "if"; } import ietf-ip { prefix "ip"; } import ietf-routing { prefix "rt"; } import ietf-mpls { prefix "mpls"; } import routing-policy { prefix "rpl"; } organization "TBD"; contact "TBD"; description ""; revision 2015-10-19 { description "Initial revision."; reference ""; } /* * Features */ Raza, et al. Expires April 21, 2016 [Page 25] Internet-Draft YANG Data Model for LDP and mLDP October 2015 feature admin-down-config { description "This feature indicates that the system allows to configure administrative down on a VRF instance and a neighbor."; } feature capability-end-of-lib { description "This feature indicates that the system allows to configure LDP end-of-lib capability."; } feature capability-mldp-hsmp { description "This feature indicates that the system allows to configure mLDP hub-and-spoke-multipoint capability."; } feature capability-mldp-node-protection { description "This feature indicates that the system allows to configure mLDP node-protection capability."; } feature capability-typed-wildcard-fec { description "This feature indicates that the system allows to configure LDP typed-wildcard-fec capability."; } feature capability-upstream-label-assignment { description "This feature indicates that the system allows to configure LDP upstream label assignment capability."; } feature forwarding-nexthop-config { description "This feature indicates that the system allows to configure forwarding nexthop on interfaces."; } feature global-session-authentication { description "This feature indicates that the system allows to configure authentication at global level."; } Raza, et al. Expires April 21, 2016 [Page 26] Internet-Draft YANG Data Model for LDP and mLDP October 2015 feature graceful-restart-helper-mode { description "This feature indicates that the system supports graceful restart helper mode."; } feature mldp { description "This feature indicates that the system supports Multicast LDP (mLDP)."; } feature mldp-mofrr { description "This feature indicates that the system supports mLDP Multicast only FRR (MoFRR)."; } feature per-interface-timer-config { description "This feature indicates that the system allows to configure interface hello timers at the per-interface level."; } feature per-neighbor-graceful-restart-config { description "This feature indicates that the system allows to configure graceful restart at the per-neighbor level."; } feature per-neighbor-session-attributes-config { description "This feature indicates that the system allows to configure session attributes at the per-neighbor level."; } feature policy-extended-discovery-config { description "This feature indicates that the system allows to configure policies to control the acceptance of extended neighbor discovery hello messages."; } feature policy-label-assignment-config { description "This feature indicates that the system allows to configure policies to assign labels according to certain prefixes."; } Raza, et al. Expires April 21, 2016 [Page 27] Internet-Draft YANG Data Model for LDP and mLDP October 2015 feature policy-ordered-label-config { description "This feature indicates that the system allows to configure ordered label policies."; } feature session-downstream-on-demand-config { description "This feature indicates that the system allows to configure session downstream-on-demand"; } feature session-protection { description "This feature indicates that the system supports session protection"; } /* * Typedefs */ typedef address-family-type { type enumeration { enum ipv4 { description "IPv4"; } enum ipv6 { description "IPv6"; } } description "Address family type."; } typedef multipoint-type { type enumeration { enum p2mp { description "Point to multipoint."; } enum mp2mp { description "Multipoint to multipoint."; } } description "p2mp or mp2mp."; } typedef peer-list-ref { Raza, et al. Expires April 21, 2016 [Page 28] Internet-Draft YANG Data Model for LDP and mLDP October 2015 type leafref { path "/rpl:routing-policy/rpl:defined-sets/rpl:neighbor-sets/" + "rpl:neighbor-set/rpl:neighbor-set-name"; } description "A type for a reference to a peer list."; } typedef prefix-list-ref { type leafref { path "/rpl:routing-policy/rpl:defined-sets/rpl:prefix-sets/" + "rpl:prefix-set/rpl:prefix-set-name"; } description "A type for a reference to a prefix list."; } typedef oper-status-event-type { type enumeration { enum up { value 1; description "Operational status changed to up."; } enum down { value 2; description "Operational status changed to down."; } } description "Operational status event type for notifications."; } /* * Identities */ /* * Groupings */ grouping ldp-instance-ref { description "An absolute reference to an LDP instance."; leaf routing-instance-ref { type rt:routing-instance-ref; description "Reference to the routing instance."; } Raza, et al. Expires April 21, 2016 [Page 29] Internet-Draft YANG Data Model for LDP and mLDP October 2015 } // ldp-instance-ref grouping ldp-neighbor-ref { description "An absolute reference to an LDP neighbor."; uses ldp-instance-ref; leaf neighbor-ref { type leafref { path "/rt:routing/rt:routing-instance" + "[rt:name = current()/../routing-instance-ref]/" + "mpls:mpls/mpls-ldp/" + "neighbors/neighbor/lsr-id"; } description "Reference to an LDP neighbor."; } } // ldp-neighbor-ref grouping ldp-adjacency-ref { description "An absolute reference to an LDP adjacency."; uses ldp-instance-ref; choice adjacency-type { description "Interface or targeted adjacency."; case targeted { container targeted { description "Targeted adjacency."; leaf target-address { type inet:ip-address; description "The target address."; } } // targeted } case link { container link { description "Link adjacency."; leaf next-hop-interface { type if:interface-ref; description "Interface connecting to next-hop."; } leaf next-hop-address { type inet:ip-address; must "../next-hop-interface" { description "Applicable when interface is specified."; Raza, et al. Expires April 21, 2016 [Page 30] Internet-Draft YANG Data Model for LDP and mLDP October 2015 } description "IP address of next-hop."; } } // link } } } // ldp-adjacency-ref grouping ldp-fec-event { description "A LDP FEC event."; uses ldp-instance-ref; leaf prefix { type inet:ip-prefix; description "FEC."; } } // ldp-fec-event grouping mldp-fec-event { description "A mLDP FEC event."; uses ldp-instance-ref; leaf tree-type { type multipoint-type; description "p2mp or mp2mp."; } leaf root { type inet:ip-address; description "Root address."; } choice lsp-key-type { description "LSP ID based or source-group based ."; case lsp-id-based { leaf lsp-id { type uint16; description "ID to identify the LSP."; } } case source-group-based { leaf source-addr { type inet:ip-address; description Raza, et al. Expires April 21, 2016 [Page 31] Internet-Draft YANG Data Model for LDP and mLDP October 2015 "LSP source address."; } leaf group-addr { type inet:ip-address; description "Multicast group address."; } } // case source-group-based } } // mldp-fec-event grouping basic-discovery-timers { description "Basic discovery timer attributes."; leaf hello-holdtime { type uint16 { range 15..3600; } units seconds; default 15; description "The time interval for which a LDP link Hello adjacency is maintained in the absence of link Hello messages from the LDP neighbor"; } leaf hello-interval { type uint16 { range 5..1200; } units seconds; default 5; description "The interval between consecutive LDP link Hello messages used in basic LDP discovery"; } } // basic-discovery-timers grouping extended-discovery-timers { description "Extended discovery timer attributes."; leaf hello-holdtime { type uint16 { range 15..3600; } units seconds; default 45; description "The time interval for which LDP targeted Hello adjacency Raza, et al. Expires April 21, 2016 [Page 32] Internet-Draft YANG Data Model for LDP and mLDP October 2015 is maintained in the absence of targeted Hello messages from an LDP neighbor."; } leaf hello-interval { type uint16 { range 5..3600; } units seconds; default 15; description "The interval between consecutive LDP targeted Hello messages used in extended LDP discovery."; } } // extended-discovery-timers grouping graceful-restart-attributes { description "Graceful restart configuration attributes."; container graceful-restart { description "Attributes for graceful restart."; leaf enable { type boolean; description "Enable or disable graceful restart."; } leaf helper-enable { if-feature graceful-restart-helper-mode; type boolean; description "Enable or disable graceful restart helper mode."; } leaf reconnect-time { type uint16 { range 10..1800; } units seconds; description "Specifies the time interval that the remote LDP peer must wait for the local LDP peer to reconnect after the remote peer detects the LDP communication failure."; } leaf recovery-time { type uint16 { range 30..3600; } units seconds; description Raza, et al. Expires April 21, 2016 [Page 33] Internet-Draft YANG Data Model for LDP and mLDP October 2015 ""; } leaf forwarding-holdtime { type uint16 { range 30..3600; } units seconds; description ""; } } // graceful-restart } // graceful-restart-attributes grouping graceful-restart-attributes-per-neighbor { description "Per neighbor graceful restart configuration attributes."; container graceful-restart { description "Attributes for graceful restart."; leaf enable { type boolean; description "Enable or disable graceful restart."; } leaf reconnect-time { type uint16 { range 10..1800; } units seconds; description "Specifies the time interval that the remote LDP peer must wait for the local LDP peer to reconnect after the remote peer detects the LDP communication failure."; } leaf recovery-time { type uint16 { range 30..3600; } units seconds; description ""; } } // graceful-restart } // graceful-restart-attributes-per-neighbor grouping neighbor-attributes { description "Neighbor configuration attributes."; Raza, et al. Expires April 21, 2016 [Page 34] Internet-Draft YANG Data Model for LDP and mLDP October 2015 leaf session-ka-holdtime { type uint16 { range 45..3600; } units seconds; description "The time interval after which an inactive LDP session terminates and the corresponding TCP session closes. Inactivity is defined as not receiving LDP packets from the neighbor."; } leaf session-ka-interval { type uint16 { range 15..1200; } units seconds; description "The interval between successive transmissions of keepalive packets. Keepalive packets are only sent in the absence of other LDP packets transmitted over the LDP session."; } } // neighbor-attributes grouping session-protection-per-vrf { description "Session protection attributes."; container session-protection { if-feature session-protection; description "Session protection attributes."; leaf enable { type boolean; description "'true' if session protection is enabled."; } leaf duration { type union { type uint32; type enumeration { enum "infinite" { description "The duration is infinite."; } } } units seconds; description "Session protection duration."; } leaf peer-list { Raza, et al. Expires April 21, 2016 [Page 35] Internet-Draft YANG Data Model for LDP and mLDP October 2015 type peer-list-ref; description "The name of a peer ACL."; } } // session-protection } // session-protection-per-vrf grouping session-protection-per-neighbor { description "Session protection attributes."; container session-protection { if-feature session-protection; description "Session protection attributes."; leaf enable { type boolean; description "'true' if session protection is enabled."; } leaf duration { type union { type uint32; type enumeration { enum "infinite" { description "The duration is infinite."; } } } units seconds; description "Session protection duration."; } } // session-protection } // session-protection-per-neighbor grouping neighbor-authentication { description "Neighbor authentication attributes."; leaf md5-password { type string { length "1..80"; } description "Assigns an encrypted MD5 password to an LDP neighbor"; } // md5-password } // neighbor-authentication grouping neighbor-attributes-container { Raza, et al. Expires April 21, 2016 [Page 36] Internet-Draft YANG Data Model for LDP and mLDP October 2015 description "Container of neighbor configuration attributes."; container neighbors { description "Container of neighbor configuration attributes."; uses neighbor-authentication { if-feature global-session-authentication; } uses neighbor-attributes; } } // neighbor-attributes-container grouping instance-attributes { description "Configuration attributes at instance level."; container capability { description "Configure capability."; container end-of-lib { if-feature capability-end-of-lib; description "Configure upstream label assignment capability."; leaf enable { type boolean; description "Enable end-of-lib capability."; } } container typed-wildcard-fec { if-feature capability-typed-wildcard-fec; description "Configure typed-wildcard-fec capability."; leaf enable { type boolean; description "Enable typed-wildcard-fec capability."; } } container upstream-label-assignment { if-feature capability-upstream-label-assignment; description "Configure upstream label assignment capability."; leaf enable { type boolean; description "Enable upstream label assignment."; } } container mldp { if-feature mldp; Raza, et al. Expires April 21, 2016 [Page 37] Internet-Draft YANG Data Model for LDP and mLDP October 2015 description "Multipoint capabilities."; uses mldp-capabilities; } } // capability uses graceful-restart-attributes; leaf igp-synchronization-delay { type uint16 { range 3..60; } units seconds; description "Sets the interval that the LDP waits before notifying the Interior Gateway Protocol (IGP) that label exchange is completed so that IGP can start advertising the normal metric for the link."; } leaf lsr-id { type yang:dotted-quad; description "Router ID."; } } // instance-attributes grouping global-attributes { description "Configuration attributes at global level."; uses instance-attributes; leaf nonstop-routing { type boolean; default false; description "Enables Nonstop Routing (NSR)"; } } // global-attributes grouping policy-attributes { description "LDP policy attributes."; container label-policy { description "Label policy attributes."; container independent-mode { description "Independent label policy attributes."; container assign { Raza, et al. Expires April 21, 2016 [Page 38] Internet-Draft YANG Data Model for LDP and mLDP October 2015 if-feature policy-label-assignment-config; description "Label assignment policies"; choice prefix-option { description "Use either prefix-list or host-routes-only."; case prefix-list { leaf prefix-list { type prefix-list-ref; description "Assign labels according to certain prefixes."; } } case host-routes-only { leaf host-routes-only { type boolean; description "'true' to apply host routes only."; } } } // prefix-option } container advertise { description "Label advertising policies."; container explicit-null { presence "Present to enable explicit null."; description "Enables an egress router to advertise an explicit null label (value 0) in place of an implicit null label (value 3) to the penultimate hop router."; leaf prefix-list { type prefix-list-ref; description "Prefix list name. Applies the filters in the specified prefix list to label advertisements. If the prefix list is not specified, explicit null label advertisement is enabled for all directly connected prefixes."; } } leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to outgoing label advertisements."; Raza, et al. Expires April 21, 2016 [Page 39] Internet-Draft YANG Data Model for LDP and mLDP October 2015 } } container accept { description "Label advertisement acceptance policies."; leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to incoming label advertisements."; } } } // independent-mode container ordered-mode { if-feature policy-ordered-label-config; description "Ordered label policy attributes."; container egress-lsr { description "Egress LSR label assignment policies"; leaf prefix-list { type prefix-list-ref; description "Assign labels according to certain prefixes."; } } container advertise { description "Label advertising policies."; leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to outgoing label advertisements."; } } container accept { description "Label advertisement acceptance policies."; leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to incoming label advertisements."; } } } // ordered-mode } // label-policy Raza, et al. Expires April 21, 2016 [Page 40] Internet-Draft YANG Data Model for LDP and mLDP October 2015 } // policy-attributes grouping neighbor-af-policy-attributes { description "LDP policy attributes under neighbor address-family."; container label-policy { description "Label policy attributes."; container advertise { description "Label advertising policies."; leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to outgoing label advertisements."; } } container accept { description "Label advertisement acceptance policies."; leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to incoming label advertisements."; } } // accept } // label-policy } // neighbor-af-policy-attributes grouping extended-discovery-policy-attributes { description "LDP policy to control the acceptance of extended neighbor discovery hello messages."; container hello-accept { if-feature policy-extended-discovery-config; description "Extended discovery acceptance policies."; leaf enable { type boolean; description "'true' to accept; 'false' to deny."; } leaf peer-list { type peer-list-ref; description Raza, et al. Expires April 21, 2016 [Page 41] Internet-Draft YANG Data Model for LDP and mLDP October 2015 "The name of a peer ACL."; } } // hello-accept } // extended-discovery-policy-attributes grouping mldp-capabilities { description "mLDP capabilities."; container p2mp { description "Configure point-to-multipoint capability."; leaf enable { type boolean; description "Enable point-to-multipoint."; } } container mp2mp { description "Configure multipoint-to-multipoint capability."; leaf enable { type boolean; description "Enable multipoint-to-multipoint."; } } container make-before-break { description "Configure make-before-break capability."; leaf enable { type boolean; description "Enable make-before-break."; } leaf switchover-delay { type uint16; units seconds; description "Switchover delay in seconds."; } leaf timeout { type uint16; units seconds; description "Timeout in seconds."; } } container hub-and-spoke { Raza, et al. Expires April 21, 2016 [Page 42] Internet-Draft YANG Data Model for LDP and mLDP October 2015 if-feature capability-mldp-hsmp; description "Configure hub-and-spoke-multipoint capability."; reference "RFC7140: LDP Extensions for Hub and Spoke Multipoint Label Switched Path"; leaf enable { type boolean; description "Enable hub-and-spoke-multipoint."; } } container node-protection { if-feature capability-mldp-node-protection; description "Configure node-protection capability."; reference "draft-ietf-mpls-mldp-node-protection: mLDP Node Protection."; leaf plr { type boolean; description "Point of Local Repair capable for MP LSP node protection."; } container merge-point { description "Merge Point capable for MP LSP node protection."; leaf enable { type boolean; description "Enable merge point capability."; } leaf targeted-session-teardown-delay { type uint16; units seconds; description "Targeted session teardown delay."; } } // merge-point } } // mldp-capabilities grouping mldp-configured-lsp-roots { description "mLDP roots containers."; container roots-ipv4 { Raza, et al. Expires April 21, 2016 [Page 43] Internet-Draft YANG Data Model for LDP and mLDP October 2015 when "../../../af = 'ipv4'" { description "Only for IPv4."; } description "Configured IPv4 multicast LSPs."; list root { key "root-addr"; description "List of roots for configured multicast LSPs."; leaf root-addr { type inet:ipv4-address; description "Root address."; } list lsp { must "(lsp-id = 0 and source-addr != '0.0.0.0' and " + "group-addr != '0.0.0.0') or " + "(lsp-id != 0 and source-addr = '0.0.0.0' and " + "group-addr = '0.0.0.0')" { description "A LSP can be identified by either or ."; } key "lsp-id source-addr group-addr"; description "List of LSPs."; leaf lsp-id { type uint16; description "ID to identify the LSP."; } leaf source-addr { type inet:ipv4-address-no-zone; description "Source address."; } leaf group-addr { type inet:ipv4-address-no-zone; description "Group address."; } } // list lsp } // list root } // roots-ipv4 container roots-ipv6 { Raza, et al. Expires April 21, 2016 [Page 44] Internet-Draft YANG Data Model for LDP and mLDP October 2015 when "../../../af = 'ipv6'" { description "Only for IPv6."; } description "Configured IPv6 multicast LSPs."; list root { key "root-addr"; description "List of roots for configured multicast LSPs."; leaf root-addr { type inet:ipv6-address; description "Root address."; } list lsp { must "(lsp-id = 0 and source-addr != '::' and " + "group-addr != '::') or " + "(lsp-id != 0 and source-addr = '::' and " + "group-addr = '::')" { description "A LSP can be identified by either or ."; } key "lsp-id source-addr group-addr"; description "List of LSPs."; leaf lsp-id { type uint16; description "ID to identify the LSP."; } leaf source-addr { type inet:ipv6-address-no-zone; description "Source address."; } leaf group-addr { type inet:ipv6-address-no-zone; description "Group address."; } } // list lsp } // list root } // roots-ipv6 } // mldp-configured-lsp-roots Raza, et al. Expires April 21, 2016 [Page 45] Internet-Draft YANG Data Model for LDP and mLDP October 2015 /* * Configuration data nodes */ augment "/rt:routing/rt:routing-instance/mpls:mpls" { description "LDP augmentation."; container mpls-ldp { presence "Container for LDP protocol."; description "Container for LDP protocol."; container global { description "Global attributes for LDP."; container config { description "Configuration data."; uses global-attributes; } container state { config false; description "Operational state data."; uses global-attributes; } } container mldp { if-feature mldp; description "mLDP attributes at per instance level. Defining attributes here does not enable any MP capabilities. MP capabilities need to be explicitly enabled under container capability."; container config { description "Configuration data."; leaf enable { type boolean; description "Enable mLDP."; } } container state { config false; description Raza, et al. Expires April 21, 2016 [Page 46] Internet-Draft YANG Data Model for LDP and mLDP October 2015 "Operational state data."; leaf enable { type boolean; description "Enable mLDP."; } } list address-family { key "af"; description "Per-af params."; leaf af { type address-family-type; description "Address family type value."; } container config { description "Configuration data."; container multicast-only-frr { if-feature mldp-mofrr; description "Multicast only FRR (MoFRR) policy."; leaf prefix-list { type prefix-list-ref; description "Enables MoFRR for the specified access list."; } } // multicast-only-frr container recursive-fec { description "Recursive FEC policy."; leaf prefix-list { type prefix-list-ref; description "Enables recursive FEC for the specified access list."; } } // recursive-for } container state { config false; description "Operational state data."; container multicast-only-frr { if-feature mldp-mofrr; Raza, et al. Expires April 21, 2016 [Page 47] Internet-Draft YANG Data Model for LDP and mLDP October 2015 description "Multicast only FRR (MoFRR) policy."; leaf prefix-list { type prefix-list-ref; description "Enables MoFRR for the specified access list."; } } // multicast-only-frr container recursive-fec { description "Recursive FEC policy."; leaf prefix-list { type prefix-list-ref; description "Enables recursive FEC for the specified access list."; } } // recursive-for } container configured-leaf-lsps { description "Configured multicast LSPs."; container p2mp { description "Configured point-to-multipoint LSPs."; uses mldp-configured-lsp-roots; } container mp2mp { description "Configured multipoint-to-multipoint LSPs."; uses mldp-configured-lsp-roots; } } // configured-leaf-lsps } // list address-family } // mldp list address-family { key "af"; description "Per-vrf per-af params."; leaf af { type address-family-type; description "Address family type value."; } Raza, et al. Expires April 21, 2016 [Page 48] Internet-Draft YANG Data Model for LDP and mLDP October 2015 container config { description "Configuration data."; leaf enable { type boolean; description "'true' to enable the address family."; } uses policy-attributes; container ipv4 { when "../../af = 'ipv4'" { description "Only for IPv4."; } description "IPv4 address family."; leaf transport-address { type inet:ipv4-address; description "The transport address advertised in LDP Hello messages."; } } // ipv4 container ipv6 { when "../../af = 'ipv6'" { description "Only for IPv6."; } description "IPv6 address family."; leaf transport-address { type inet:ipv6-address; description "The transport address advertised in LDP Hello messages."; } } // ipv6 } container state { config false; description "Operational state data."; leaf enable { type boolean; description "'true' to enable the address family."; } Raza, et al. Expires April 21, 2016 [Page 49] Internet-Draft YANG Data Model for LDP and mLDP October 2015 uses policy-attributes; container ipv4 { when "../../af = 'ipv4'" { description "Only for IPv4."; } description "IPv4 address family."; leaf transport-address { type inet:ipv4-address; description "The transport address advertised in LDP Hello messages."; } } // ipv4 container ipv6 { when "../../af = 'ipv6'" { description "Only for IPv6."; } description "IPv6 address family."; leaf transport-address { type inet:ipv6-address; description "The transport address advertised in LDP Hello messages."; } } // ipv6 } } container discovery { description "Neibgbor discovery configuration."; container interfaces { description "A list of interfaces for basic descovery."; container config { description "Configuration data."; uses basic-discovery-timers; } container state { config false; description Raza, et al. Expires April 21, 2016 [Page 50] Internet-Draft YANG Data Model for LDP and mLDP October 2015 "Operational state data."; uses basic-discovery-timers; } list interface { key "interface"; description "List of LDP interfaces."; leaf interface { type if:interface-ref; description "Interface."; } container config { description "Configuration data."; uses basic-discovery-timers { if-feature per-interface-timer-config; } leaf igp-synchronization-delay { if-feature per-interface-timer-config; type uint16 { range 3..60; } units seconds; description "Sets the interval that the LDP waits before notifying the Interior Gateway Protocol (IGP) that label exchange is completed so that IGP can start advertising the normal metric for the link."; } } container state { config false; description "Operational state data."; uses basic-discovery-timers { if-feature per-interface-timer-config; } leaf igp-synchronization-delay { if-feature per-interface-timer-config; type uint16 { range 3..60; } units seconds; description "Sets the interval that the LDP waits before notifying the Interior Gateway Protocol (IGP) that Raza, et al. Expires April 21, 2016 [Page 51] Internet-Draft YANG Data Model for LDP and mLDP October 2015 label exchange is completed so that IGP can start advertising the normal metric for the link."; } } list address-family { key "af"; description "Per-vrf per-af params."; leaf af { type address-family-type; description "Address family type value."; } container config { description "Configuration data."; leaf enable { type boolean; description "Enable the address family on the interface."; } container ipv4 { must "/if:interfaces/if:interface" + "[name = current()/../../../interface]/" + "ip:ipv4" { description "Only if IPv4 is enabled on the interface."; } description "IPv4 address family."; leaf transport-address { type union { type enumeration { enum "use-interface-address" { description "Use interface address as the transport address."; } } type inet:ipv4-address; } description "IP address to be advertised as the LDP transport address."; } } Raza, et al. Expires April 21, 2016 [Page 52] Internet-Draft YANG Data Model for LDP and mLDP October 2015 container ipv6 { must "/if:interfaces/if:interface" + "[name = current()/../../../interface]/" + "ip:ipv6" { description "Only if IPv6 is enabled on the interface."; } description "IPv6 address family."; leaf transport-address { type union { type enumeration { enum "use-interface-address" { description "Use interface address as the transport address."; } } type inet:ipv4-address; } description "IP address to be advertised as the LDP transport address."; } } // ipv6 } container state { config false; description "Operational state data."; leaf enable { type boolean; description "Enable the address family on the interface."; } container ipv4 { must "/if:interfaces/if:interface" + "[name = current()/../../../interface]/" + "ip:ipv4" { description "Only if IPv4 is enabled on the interface."; } description "IPv4 address family."; leaf transport-address { type union { type enumeration { Raza, et al. Expires April 21, 2016 [Page 53] Internet-Draft YANG Data Model for LDP and mLDP October 2015 enum "use-interface-address" { description "Use interface address as the transport address."; } } type inet:ipv4-address; } description "IP address to be advertised as the LDP transport address."; } } container ipv6 { must "/if:interfaces/if:interface" + "[name = current()/../../../interface]/" + "ip:ipv6" { description "Only if IPv6 is enabled on the interface."; } description "IPv6 address family."; leaf transport-address { type union { type enumeration { enum "use-interface-address" { description "Use interface address as the transport address."; } } type inet:ipv4-address; } description "IP address to be advertised as the LDP transport address."; } } // ipv6 } } // address-family } // list interface } // interfaces container targeted { description "A list of targeted neighbors for extended discovery."; container config { Raza, et al. Expires April 21, 2016 [Page 54] Internet-Draft YANG Data Model for LDP and mLDP October 2015 description "Configuration data."; uses extended-discovery-timers; uses extended-discovery-policy-attributes; } container state { config false; description "Operational state data."; uses extended-discovery-timers; uses extended-discovery-policy-attributes; } container address-family { description "Per-vrf per-af params."; container ipv4 { description "IPv4 address family."; list target { key "address"; description "Targeted discovery params."; leaf address { type inet:ipv4-address; description "Configures a remote LDP neighbor and enables extended LDP discovery of the specified neighbor."; } container config { description "Configuration data."; leaf enable { type boolean; description "Enable the target."; } } container state { config false; description "Operational state data."; leaf enable { type boolean; description "Enable the target."; Raza, et al. Expires April 21, 2016 [Page 55] Internet-Draft YANG Data Model for LDP and mLDP October 2015 } } } } // ipv4 container ipv6 { description "IPv6 address family."; list target { key "address"; description "Targeted discovery params."; leaf address { type inet:ipv6-address; description "Configures a remote LDP neighbor and enables extended LDP discovery of the specified neighbor."; } container config { description "Configuration data."; leaf enable { type boolean; description "Enable the target."; } } container state { config false; description "Operational state data."; leaf enable { type boolean; description "Enable the target."; } } } } // ipv6 } // address-family } // targeted } // discovery container forwarding-nexthop { if-feature forwarding-nexthop-config; description "Configuration for forwarding nexthop."; Raza, et al. Expires April 21, 2016 [Page 56] Internet-Draft YANG Data Model for LDP and mLDP October 2015 container interfaces { description "A list of interfaces on which forwarding is disabled."; list interface { key "interface"; description "List of LDP interfaces."; leaf interface { type if:interface-ref; description "Interface."; } list address-family { key "af"; description "Per-vrf per-af params."; leaf af { type address-family-type; description "Address family type value."; } container config { description "Configuration data."; leaf ldp-disable { type boolean; description "Disable LDP forwarding on the interface."; } leaf mldp-disable { if-feature mldp; type boolean; description "Disable mLDP forwarding on the interface."; } } container state { config false; description "Operational state data."; leaf ldp-disable { type boolean; description "Disable LDP forwarding on the interface."; } leaf mldp-disable { if-feature mldp; Raza, et al. Expires April 21, 2016 [Page 57] Internet-Draft YANG Data Model for LDP and mLDP October 2015 type boolean; description "Disable mLDP forwarding on the interface."; } } } // address-family } // list interface } // interfaces } // forwarding-nexthop container neighbors { description "Neighbors configuration attributes."; container config { description "Configuration data."; uses neighbor-authentication { if-feature global-session-authentication; } uses neighbor-attributes; container session-downstream-on-demand { if-feature session-downstream-on-demand-config; description "Session downstream-on-demand attributes."; leaf enable { type boolean; description "'true' if session downstream-on-demand is enabled."; } leaf peer-list { type peer-list-ref; description "The name of a peer ACL."; } } uses session-protection-per-vrf; } container state { config false; description "Operational state data."; uses neighbor-authentication { if-feature global-session-authentication; } uses neighbor-attributes; Raza, et al. Expires April 21, 2016 [Page 58] Internet-Draft YANG Data Model for LDP and mLDP October 2015 container session-downstream-on-demand { if-feature session-downstream-on-demand-config; description "Session downstream-on-demand attributes."; leaf enable { type boolean; description "'true' if session downstream-on-demand is enabled."; } leaf peer-list { type peer-list-ref; description "The name of a peer ACL."; } } uses session-protection-per-vrf; } list neighbor { key "lsr-id"; description "List of neighbors."; leaf lsr-id { type union { type yang:dotted-quad; type uint32; } description "LSR ID."; } container config { description "Configuration data."; leaf admin-down { type boolean; default false; description "'true' to disable the neighbor."; } container capability { description "Per neighbor capability"; container mldp { if-feature mldp; description Raza, et al. Expires April 21, 2016 [Page 59] Internet-Draft YANG Data Model for LDP and mLDP October 2015 "mLDP capabilities."; uses mldp-capabilities; } } uses neighbor-authentication; uses graceful-restart-attributes-per-neighbor { if-feature per-neighbor-graceful-restart-config; } uses neighbor-attributes { if-feature per-neighbor-session-attributes-config; } uses session-protection-per-neighbor; container address-family { description "Per-vrf per-af params."; container ipv4 { description "IPv4 address family."; uses neighbor-af-policy-attributes; } container ipv6 { description "IPv6 address family."; uses neighbor-af-policy-attributes; } // ipv6 } // address-family } container state { config false; description "Operational state data."; leaf admin-down { type boolean; default false; description "'true' to disable the neighbor."; } container capability { description "Per neighbor capability"; container mldp { if-feature mldp; description Raza, et al. Expires April 21, 2016 [Page 60] Internet-Draft YANG Data Model for LDP and mLDP October 2015 "mLDP capabilities."; uses mldp-capabilities; } } uses neighbor-authentication; uses graceful-restart-attributes-per-neighbor { if-feature per-neighbor-graceful-restart-config; } uses neighbor-attributes { if-feature per-neighbor-session-attributes-config; } uses session-protection-per-neighbor; container address-family { description "Per-vrf per-af params."; container ipv4 { description "IPv4 address family."; uses neighbor-af-policy-attributes; } container ipv6 { description "IPv6 address family."; uses neighbor-af-policy-attributes; } // ipv6 } // address-family } } // list neighbor } // neighbors } // container mpls-ldp } /* * RPCs */ rpc mpls-ldp-clear-neighbor { description "Clears the session to the neighbor."; input { uses ldp-instance-ref { description "VRF instance name. If this is not provided then all instances are cleared."; } Raza, et al. Expires April 21, 2016 [Page 61] Internet-Draft YANG Data Model for LDP and mLDP October 2015 leaf lsr-id { type union { type yang:dotted-quad; type uint32; } description "LSR ID of neighbor to be cleared. If this is not provided then all neighbors are cleared"; } } } rpc mpls-ldp-clear-adjacency { description "Clears the hello adjacency"; input { uses ldp-instance-ref { description "VRF instance name. If this is not provided then all instances are cleared."; } container adjacency { description "Link adjacency or targettted adjacency. If this is not provided then all hello adjacencies are cleared"; choice adjacency-type { description "Adjacency type."; case targeted { container targeted { presence "Present to clear targeted adjacencies."; description "Clear targeted adjacencies."; leaf target-address { type inet:ip-address; description "The target address. If this is not provided then all targeted adjacencies are cleared"; } } // targeted } case link { container link { presence "Present to clear link adjacencies."; description "Clear link adjacencies."; leaf next-hop-interface { type if:interface-ref; description Raza, et al. Expires April 21, 2016 [Page 62] Internet-Draft YANG Data Model for LDP and mLDP October 2015 "Interface connecting to next-hop. If this is not provided then all link adjacencies are cleared."; } leaf next-hop-address { type inet:ip-address; must "../next-hop-interface" { description "Applicable when interface is specified."; } description "IP address of next-hop. If this is not provided then adjacencies to all next-hops on the given interface are cleared."; } // next-hop-address } // link } } } } } rpc mpls-ldp-clear-neighbor-statistics { description "Clears protocol statistics (e.g. sent and received counters)."; input { uses ldp-instance-ref { description "VRF instance name. If this is not provided then all instances are cleared."; } leaf lsr-id { type union { type yang:dotted-quad; type uint32; } description "LSR ID of neighbor whose statistic are to be cleared. If this is not provided then all neighbors statistics are cleared"; } } } /* * Notifications */ notification mpls-ldp-neighbor-event { Raza, et al. Expires April 21, 2016 [Page 63] Internet-Draft YANG Data Model for LDP and mLDP October 2015 description "Notification event for a change of LDP neighbor operational status."; leaf event-type { type oper-status-event-type; description "Event type."; } uses ldp-neighbor-ref; } notification mpls-ldp-adjacency-event { description "Notification event for a change of LDP adjacency operational status."; leaf event-type { type oper-status-event-type; description "Event type."; } uses ldp-adjacency-ref; } notification mpls-ldp-fec-event { description "Notification event for a change of FEC status."; leaf event-type { type oper-status-event-type; description "Event type."; } uses ldp-fec-event; } notification mpls-mldp-fec-event { description "Notification event for a change of FEC status."; leaf event-type { type oper-status-event-type; description "Event type."; } uses mldp-fec-event; } } Figure 11 Raza, et al. Expires April 21, 2016 [Page 64] Internet-Draft YANG Data Model for LDP and mLDP October 2015 6. Security Considerations The configuration, state, action and notification data defined in this document are designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. The NETCONF access control model [RFC6536] provides means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. LDP is a MPLS protocol that is used to establish MPLS transport LSPs. So it is critical to ensure security of the protocol to avoid disruption of the services that depend on these transport LSPs. There are a number of data nodes defined in the LDP and mLDP 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. The security concerns listed above are, however, no different than faced by other routing protocols. Hence, this draft does not change any underlying security issues inherent in [I-D.ietf-netmod-routing- cfg] 7. IANA Considerations None. 8. Acknowledgments The authors would like to acknowledge Danial Johari, Eddie Chami, Nagendra Kumar, Mannan Venkatesan, Pavan Beeram for their contribution to this document. We also acknowledge Ladislav Lhotka for his useful comments as the YANG Doctor. 9. References 9.1. Normative References [I-D.ietf-mpls-mldp-node-protection] Wijnands, I., Raza, K., Atlas, A., Tantsura, J., and Q. Zhao, "mLDP Node Protection", draft-ietf-mpls-mldp-node- protection-08 (work in progress), September 2015. Raza, et al. Expires April 21, 2016 [Page 65] Internet-Draft YANG Data Model for LDP and mLDP October 2015 [I-D.ietf-netmod-routing-cfg] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", draft-ietf-netmod-routing-cfg-20 (work in progress), October 2015. [I-D.openconfig-netmod-opstate] Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling of Operational State Data in YANG", draft-openconfig- netmod-opstate-01 (work in progress), July 2015. [I-D.saad-mpls-static-yang] Raza, K., Gandhi, R., Liu, X., Beeram, V., Saad, T., Chen, X., Jones, R., and B. Wen, "A YANG Data Model for MPLS Base and Static LSPs", draft-saad-mpls-static-yang-00 (work in progress), October 2015. [I-D.shaikh-rtgwg-policy-model] Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, "Routing Policy Configuration Model for Service Provider Networks", draft-shaikh-rtgwg-policy-model-01 (work in progress), July 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, . [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, . [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, DOI 10.17487/RFC5919, August 2010, . Raza, et al. Expires April 21, 2016 [Page 66] Internet-Draft YANG Data Model for LDP and mLDP October 2015 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, . [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, November 2011, . [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, "Using Multipoint LDP When the Backbone Has No Route to the Root", RFC 6512, DOI 10.17487/RFC6512, February 2012, . [RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. Napierala, "Multipoint LDP In-Band Signaling for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6826, DOI 10.17487/RFC6826, January 2013, . [RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP Multipoint Extensions on Targeted LDP Sessions", RFC 7060, DOI 10.17487/RFC7060, November 2013, . [RFC7140] Jin, L., Jounay, F., Wijnands, IJ., and N. Leymann, "LDP Extensions for Hub and Spoke Multipoint Label Switched Path", RFC 7140, DOI 10.17487/RFC7140, March 2014, . [RFC7438] Wijnands, IJ., Ed., Rosen, E., Gulko, A., Joorde, U., and J. Tantsura, "Multipoint LDP (mLDP) In-Band Signaling with Wildcards", RFC 7438, DOI 10.17487/RFC7438, January 2015, . [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. Papneja, "Updates to LDP for IPv6", RFC 7552, DOI 10.17487/RFC7552, June 2015, . 9.2. Informative References [I-D.iwijnand-mpls-mldp-multi-topology] Wijnands, I. and K. Raza, "mLDP Extensions for Multi Topology Routing", draft-iwijnand-mpls-mldp-multi- topology-03 (work in progress), June 2013. Raza, et al. Expires April 21, 2016 [Page 67] Internet-Draft YANG Data Model for LDP and mLDP October 2015 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, DOI 10.17487/RFC7307, July 2014, . Authors' Addresses Kamran Raza Cisco Systems, Inc. Email: skraza@cisco.com Reshad Rahman Cisco Systems, Inc. Email: rrahman@cisco.com Rajiv Asati Cisco Systems, Inc. Email: rajiva@cisco.com Raza, et al. Expires April 21, 2016 [Page 68] Internet-Draft YANG Data Model for LDP and mLDP October 2015 Xufeng Liu Ericsson Email: xufeng.liu@ericsson.com Jeff Tantsura Ericsson Email: jeff.tantsura@ericsson.com Santosh Esale Juniper Networks Email: sesale@juniper.net Xia Chen Huawei Technologies Email: jescia.chenxia@huawei.com Loa Andersson Huawei Technologies Email: loa@pi.nu Himanshu Shah Ciena Corporation Email: hshah@ciena.com Matthew Bocci Alcatel-Lucent Email: matthew.bocci@alcatel-lucent.com Additional Contributors Stephane Litkowski Orange. Email: stephane.litkowski@orange.com Sowmya Krishnaswamy Cisco Systems Inc. Email: sowkrish@cisco.com Raza, et al. Expires April 20, 2016 [Page 69]