MPLS Working Group K. Raza Internet-Draft S. Krishnaswamy Intended status: Standards Track Cisco Systems, Inc. Expires:May 16,September 14, 2017 X. LiuKuatro TechnologiesJabil S. Esale Juniper Networks X. Chen Huawei Technologies Jeff TantsuraNovember 12, 2016March 13, 2017 YANG Data Model for MPLS mLDPdraft-ietf-mpls-mldp-yang-00draft-ietf-mpls-mldp-yang-01 Abstract This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP data model augments the LDP data model. 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 onMay 16,September 14, 2017. Copyright Notice Copyright (c)20162017 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 . . . . . . . . . . . . . . . . . . . . . . . .23 1.1. Base and Extended . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . .34 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . .34 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. FEC Types . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . .47 4.1. Configuration Hierarchy . . . . . . . . . . . . . . . . .47 4.2. mldp global container . . . . . . . . . . . . . . . . . .. . . 69 4.3. Leveraging LDP containers . . . . . . . . . . . . . . . .69 4.4.YANG treeConfiguration Tree . . . . . . . . . . . . . . . . . . . 10 4.4.1. Base . . . . .7. . . . . . . . . . . . . . . . . . . 10 4.4.2. Extended . . . . . . . . . . . . . . . . . . . . . . 11 5. Operational State . . . . . . . . . . . . . . . . . . . . . .913 5.1.Derived statesBase . . . . . . . . . . . . . . . . . . . . . . . . . . 135.1.1. Root state5.2. Extended . . . . . . . . . . . . . . . . . . . . .13 5.1.2. Bindings state. . . 14 5.3. Derived states . . . . . . . . . . . . . . . . . . .14 5.1.3. Capabilities. . 17 5.3.1. Root state . . . . . . . . . . . . . . . . . . . . . 186. Notifications5.3.2. Bindings state . . . . . . . . . . . . . . . . . . . 19 5.3.3. Capabilities state . . . . .18 7. Actions. . . . . . . . . . . . 22 6. Notifications . . . . . . . . . . . . . . .18 8. Open Items. . . . . . . . . 22 6.1. Base . . . . . . . . . . . . . . . .18 9. YANG Specification. . . . . . . . . . 22 6.2. Extended . . . . . . . . . . .19 10. Security Considerations. . . . . . . . . . . . . 22 7. Actions . . . . . .43 11. IANA Considerations. . . . . . . . . . . . . . . . . . . . .43 12. Acknowledgments23 8. Open Items . . . . . . . . . . . . . . . . . . . . . . .44 13. References. . 23 9. YANG Specification . . . . . . . . . . . . . . . . . . . . . 23 9.1. Base . .44 13.1. Normative References. . . . . . . . . . . . . . . . . .44 13.2. Informative References. . . . . . 23 9.2. Extended . . . . . . . . . . .45 Appendix A. Additional Contributors. . . . . . . . . . . . . 33 10. Security Considerations .46 Authors' Addresses. . . . . . . . . . . . . . . . . . 54 11. IANA Considerations . . . . .46 1. Introduction This document introduces a YANG data model for MPLS Multipoint Label Distribution Protocol (mLDP). The. . . . . . . . . . . . . . . . 54 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.1. Normative References . . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . 56 Appendix A. Additional Contributors . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 1. Introduction This document introduces a YANG data model for MPLS Multipoint Label Distribution Protocol (mLDP). The mLDP model being defined here ishighlydependent on LDP YANG data model[I-D.ietf-mpls-ldp-mldp-yang].[I-D.ietf-mpls-ldp-yang]. This implies that an opertor will need to use base LDP module to configure and manage control plane for mLDP. For example, an operator would enable LDP discovery on MPLS interface to establish LDP/mLDP peering on which mLDP bindings could be exchanged. Similarly, an operator could query state information for an LDP peer in order to verify peering attributes etc. Moreover, it is important to note here that any assumptions made in the LDP model also hold true in this document, unless otherwise explicitly stated.This document specifies mLDP model under ietf-mpls-mldp that augments LDP model as defined under ietf-mpls-ldp [I-D.ietf-mpls-ldp-mldp-yang].Like itsbaseparent LDP data model, this mLDP model also defines the following constructs for managing the mLDP protocol: o Configuration o Operational State o Executables (Actions) o Notifications This document is organized to define the data model for each of the above constructs in the sequence as listed above.2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",1.1. Base and"OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Overview FollowingExtended Like LDP model, the configuration and state items are divided into following two broad categories: o Base o Extended The "base" category contains themain mLDP areasbasic and fundamental features that arewithin the scope of this model: ocovered in mLDPBase Specificationbase specification [RFC6388]oalongwith few significant extension like targeted mLDPRecursive FEC [RFC6512] o Targeted mLDP [RFC7060] o mLDP Fast-Reroute (FRR): * Node Protection [RFC7715] * Multicast-only o In-band Signaling: * mLDP In-band Signaling [RFC6826] *[RFC7060], constituting the minumum requirements for an mLDPIn-band signalingdeployment. Whereas, the "extended" category contains all other non-base features (such as recursive FEC support, protection etc.). All the items in aVRF [RFC7246] *base category are mandatory and hence no "if-feature" is allowed under the "base" category. While "base" model support will suffice for small deployments, large deployments will require not only the "base" module support but also "extended" support for some selected and required features. The base and extended catogories are defined in their own modules ietf-mpls-mldp and ietf-mpls-mldp-extended respectively, each of which augmenting LDP base model ietf-mpls-ldp as defined under ietf- mpls-ldp [I-D.ietf-mpls-ldp-yang]. Like LDP, mLDPIn-band Signaling"base" model configuration and state covers ipv4 address-family only, withWildcards [RFC7438] o Hub-and-Spoke Multipoint LSPs [RFC7140] o Configured Leaf LSPs (manually provisioned) [Ed Note: Someipv6 address-family related configuration and state be covered in "extended" model. 2. Specification ofthe topicsRequirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" inthe above listthis document are to beaddressed/ extendedinterpreted as described in [RFC2119]. 3. Overview This document defines alater revision of this document]. 4. Configuration 4.1. Configuration Hierarchy In terms of overall configuration layout, following figure highlights extensions to LDP configurationnew module named "ietf-mpls-mldp" for mLDP YANG base data model that augments /rt:routing/rt:control-plane- protocols/ldp:mpls-ldp defined in [I-D.ietf-mpls-ldp-yang]. The document also defines "ietf-mpls-mldp-extended" module that models the extended mLDP features under YANG. Following diagram depicts high level mLDP yang tree organization and hierarchy with respect toincorporate mLDP: module: ietf-mpls-ldp augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:LDP: +-- rw routing +-- rw control-plane-protocols +-- rw mpls-ldp +--globalrw some_container | +--...rw config |+-- ...| +--mldp (augmentation)rw .... // ldp base | | +--...rw ldp-ext:.... // ldp extended | |+--... | | +--address-family* [afi]rw mldp | | +-- rw ... // mldp base | | +--...rw mldp-ext:.... // mldp extended | | ... | +--configured-leaf-lspsro state | | +--p2mp | | | +-- ... | | | +-- ...ro .... // ldp base | | +--mp2mpro ldp-ext:.... // ldp extended | |+--... | | +--...ro mldp |+-- capability| +-- ro ... // mldp base |+-- ...| +-- ro mldp-ext:.... // mldp(augmentation)extended |+-- ...|+-- ... +-- peers +--... +-- rw ...+-- peer* +-- ... +-- ... +-- capability +-- ... +-- ... +-- mldp +-- ... +--| notifications: +--- n mpls-mldp-some_event +--- n ... Figure 1From above hierarchy, we can categorize mLDP configuration parameters into two types: o Parameters that are mLDP specific o Parameters that leverage/extend LDP containers and parameters3.1. Scope Followingsubsections first describeare the main mLDPspecific configuration parameters, followed by those leveraging LDP. 4.2. mldp container mldp container is an augmentation of LDP global containerareas andholds the configuration related to itemsfeatures that aremLDP specific. The main items underwithin the scope of thiscontainer are:model: o Base: * mLDPenabling: To enableBase Specification [RFC6388] * Targeted mLDPunder a (VRF) routing instance, mldp container is enabled under LDP. Given that[RFC7060] * Configured Leaf LSPs (manually provisioned) o Extended: * mLDPrequires LDP signalling, it is not sensible to allow disabling LDP control plane underRecursive FEC [RFC6512] * mLDP Fast-Reroute (FRR): + Node Protection [RFC7715] + Multicast-only * In-band Signaling: + mLDP In-band Signaling [RFC6826] + mLDP In-band signaling in a(VRF) network-instance while requiringVRF [RFC7246] + mLDP In-band Signaling with Wildcards [RFC7438] * Hub-and-Spoke Multipoint LSPs [RFC7140] [Ed Note: Some of the topics in the above list are to beenabledaddressed/ extended in a later revision of this document]. 3.2. FEC Types The FEC for Multipoint LSP is presented as (root-address, opaque- type). The following is thesame. However, if a user wants only to allow signallingtable formultipoint 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 listvarious type ofIP address- families andMP opaque values with their keys, as covered in thefeatures enabled underneath. The per-AF mLDPconfigurationitems 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. *and state model: +-------------------------+--------------------+------------+ | Opaque Type | Key | RFC | +-------------------------+--------------------+------------+ | Generic LSP Identifier | LSP Id | [RFC6388] | | Transit IPv4 Source | Source, Group | [RFC6826] | | Transit IPv6 Source | Source, Group | [RFC6826] | | Transit IPv4 Bidir | RP, Group | [RFC6826] | | Transit IPv6 Bidir | RP, Group | [RFC6826] | | Transit VPNv4 Source | Source, Group, RD | [RFC7246] | | Transit VPNv6 Source | Source, Group, RD | [RFC7246] | | Transit VPNv4 Bidir | RP, Group, RD | [RFC7246] | | Transit VPNv6 Bidir | RP, Group, RD | [RFC7246] | | RecursiveFEC: The recursive-fec featureOpaque | Root | [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| | VPN-Recursive Opaque | Root, RD | [RFC6512] | +-------------------------+--------------------+------------+ Table 1: MP Opaque Types andallows 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] does not require any mLDP specific configuration. It, however, requires LDP upstream- label-assignment capability [RFC6389]keys It is to beenabled. 4.3. Leveraging LDP containers mLDP configuration model leverages following configuration areas and containersnoted that there arealready defined for LDP: o Capabilities: A new container "mldp" is defined that augments LDP's capabilities container. This new container specifies any mLDP specific capabilitiesthree basic types (LSP Id, Source, andtheir parameters. Moreover, a new "mldp" container is also added by augmenting LDP per-peer capability container to override/control mLDP specific capabilitiesBidir) and then there are variants (VPN, recursive, VPN- recursive) ona peer level. Intop of these basic types. The "base" model includes only thescope"Generic LSP Identifier" opaque type (for ipv4), while rest ofthis document,themost important capabilities related to mLDPabove types arep2mp, mp2mp, make- before-break, hub-and-spoke, and node-protection. o Discovery and Peer: mLDP requires LDP discovery and peer procedures to form mLDP peering. A peer is treated as mLDP peer only when either P2MP or MP2MP capabilities have been successfully exchanged withcovered by thepeer. If a user wish to selectively enable or disable mLDP with a LDP-enabled peer, he/she may use per-peer mLDP capabilities configuration. [Ed Note: The option to control mLDP enabling/disabling on a peer-list is being explored for future ]. In most common deployments, it is desirable to disable mLDP (capabilities announcements) on a targeted-only LDP peering, where targeted-only peer"extended" model. 4. Configuration 4.1. Configuration Hierarchy Following is theone whose discovery sources are targeted type only. In future revision, ahigh-level configurationoption 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. 4.4. YANG tree The following figure captures the YANG treeorganization formLDP configuration. module: ietf-mpls-mldpbase and extended mLDP: augment/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global: +--rw/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol: +-- mpls-ldp +-- global +-- ... +-- ... +-- mldp{mldp}? +--rw config | +--rw enable? boolean +--rw address-family* [afi] +--rw afi ldp:ldp-address-family +--rw config | +--rw multicast-only-frr {mldp-mofrr}?| +-- ... |+--rw prefix-list? ldp:prefix-list-ref+-- ... |+--rw recursive-fec+-- address-families |+--rw prefix-list? ldp:prefix-list-ref +--rw configured-leaf-lsps +--rw p2mp+-- ipv4 |+--rw roots-ipv4| +-- ... |+--rw root* [root-address]| +-- mldp-ext: ... |+--rw root-address inet:ipv4-address| +-- ... |+--rw lsp* [lsp-id source-address group-address]| +-- configured-leaf-lsps |+--rw lsp-id uint16| +-- ... |+--rw source-address inet:ipv4-address| +-- ... |+--rw group-address inet:ipv4-address-no-zone|+--rw roots-ipv6+-- mldp-ext: ... |+--rw root* [root-address]|+--rw root-address inet:ipv6-address+-- ... |+--rw lsp* [lsp-id source-address group-address]+-- mldp-ext: ipv6 |+--rw lsp-id uint16+-- ... |+--rw source-address inet:ipv6-address+-- ... |+--rw group-address inet:ipv6-address-no-zone +--rw mp2mp +--rw roots-ipv4+-- configured-leaf-lsps |+--rw root* [root-address]+-- ... |+--rw root-address inet:ipv4-address+-- ... +-- capability |+--rw lsp* [lsp-id source-address group-address]+-- mldp |+--rw lsp-id uint16+-- ... |+--rw source-address inet:ipv4-address+-- mldp-ext: ... |+--rw group-address inet:ipv4-address-no-zone +--rw roots-ipv6 +--rw root* [root-address] +--rw root-address inet:ipv6-address +--rw lsp* [lsp-id source-address group-address] +--rw lsp-id uint16 +--rw source-address inet:ipv6-address +--rw group-address inet:ipv6-address-no-zone augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:config/ldp:capability: +--rw 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 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:forwarding-nexthop/ldp:interfaces/ldp:interface/ldp:address-family/ldp:config: +--rw mldp-disable? boolean {mldp}? augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:config/ldp:capability: +--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+-- ... +-- forwarding-nexthop +--- interfaces +--- interface* [name] +--- mldp-ext: ... Figure 25. Operational State Operational state of mLDPFrom above hierarchy, we canbe queried and obtained from various read-only mdlp "state" containerscategorize mLDP configuration parameters into two types: o Parameters thataugment ldp state containers. Please note this state tree refers both theare mLDP specific o Parameters that leverage/extend LDP containers and parameters Following subsections first describe mLDP specific configuration"applied" state as wellparameters, followed by those leveraging LDP. It is to be noted that these parameters are defined under their respective base or extended module as per their categorization. 4.2. mldp global container mldp container is an augmentation of LDP global container and holds the"derived" stateconfiguration related totheitems that are mLDPprotocol. [Ed note: Future revision will realign] Following is a simplified graphical representation of the data modelspecific. 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) network-instance while requiring mLDP to be enabled for the same. However, if a user wants 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] does not require any mLDP specific configuration. It, however, requires LDP upstream- label-assignment capability [RFC6389] to be enabled. 4.3. Leveraging LDP containers mLDP configuration model leverages following configuration areas and containers that are already defined for LDP: o Capabilities: A new container "mldp" is defined that augments LDP's capabilities container. This new container specifies any mLDP specific capabilities and their parameters. Moreover, a new "mldp" container is also added by augmenting LDP per-peer capability container to override/control mLDP specific capabilities on a peer 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 Peer: mLDP requires LDP discovery and peer procedures to form mLDP peering. A peer is treated as mLDP peer 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 LDP-enabled peer, he/she may use per-peer mLDP capabilities configuration. [Ed Note: The option to control mLDP enabling/disabling on a peer-list is being explored for future ]. In most common deployments, it is desirable to disable mLDP (capabilities announcements) on a targeted-only LDP peering, where targeted-only peer is the one whose discovery sources are targeted type 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. 4.4. Configuration Tree 4.4.1. Base Following is a simplified graphical representation of the data model for mLDP base configuration module: ietf-mpls-mldp augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:config/ldp:capability: +--rw 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 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global: +--rw mldp +--rw config | +--rw enable? boolean +--rw address-families +--rw ipv4 +--rw configured-leaf-lsps +--rw p2mp | +--rw roots | +--rw root* [root-address] | +--rw root-address inet:ipv4-address | +--rw (lsp-key-type)? | +--:(lsp-id) | +--rw opaque-type-lspid | +--rw lsp* [lsp-id] | +--rw lsp-id uint16 +--rw mp2mp +--rw roots +--rw root* [root-address] +--rw root-address inet:ipv4-address +--rw (lsp-key-type)? +--:(lsp-id) +--rw opaque-type-lspid +--rw lsp* [lsp-id] +--rw lsp-id uint16 Figure 3 4.4.2. Extended Following is a simplified graphical representation of the data model for mLDP extended configuration module: ietf-mpls-mldp-extended augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:config/ldp:capability/mldp:mldp: +--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 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:config/ldp:capability: +--rw mldp {per-peer-capability}? +--rw p2mp | +--rw enable? boolean +--rw mp2mp | +--rw enable? boolean +--rw make-before-break +--rw enable? boolean +--rw switchover-delay? uint16 +--rw timeout? uint16 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/mldp:ipv4: +--rw config +--rw multicast-only-frr {mldp-mofrr}? | +--rw prefix-list? ldp-ext:prefix-list-ref +--rw recursive-fec +--rw prefix-list? ldp-ext:prefix-list-ref augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/mldp:ipv4/mldp:configured-leaf-lsps/mldp:p2mp/mldp:roots/mldp:root/mldp:lsp-key-type: +--:(source-group) +--rw opaque-type-transit +--rw lsp* [source-address group-address] +--rw source-address inet:ipv4-address +--rw group-address inet:ipv4-address-no-zone augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/mldp:ipv4/mldp:configured-leaf-lsps/mldp:mp2mp/mldp:roots/mldp:root/mldp:lsp-key-type: +--:(source-group) +--rw opaque-type-transit +--rw lsp* [source-address group-address] +--rw source-address inet:ipv4-address +--rw group-address inet:ipv4-address-no-zone augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp-ext:forwarding-nexthop/ldp-ext:interfaces/ldp-ext:interface/ldp-ext:address-family/ldp-ext:config: +--rw mldp-disable? boolean augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families: +--rw ipv6 +--rw config +--rw multicast-only-frr {mldp-mofrr}? | +--rw prefix-list? ldp-ext:prefix-list-ref +--rw recursive-fec +--rw prefix-list? ldp-ext:prefix-list-ref Figure 4 5. Operational State Operational state of mLDP can be queried and obtained from various read-only mdlp "state" containers that augment ldp state containers. Please note this state tree refers both the configuration "applied" state as well as the "derived" state related to the mLDP protocol. [Ed note: Future revision will realign] 5.1. Base Following is a simplified graphical representation of the data model for mLDP base operational state: module: ietf-mpls-mldp augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:state/ldp:capability: +--ro 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 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/ldp:received-peer-state/ldp:capability: +--ro mldp +--ro p2mp | +--ro enable? boolean +--ro mp2mp | +--ro enable? boolean +--ro make-before-break +--ro enable? boolean augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global: +--rw mldp +--ro state | +--ro enable? boolean +--rw address-families +--rw ipv4 +--ro state +--ro roots +--ro root* [root-address] +--ro root-address inet:ipv4-address +--ro is-self? boolean +--ro reachability* [address interface] | +--ro address inet:ipv4-address | +--ro interface ldp:mpls-interface-ref | +--ro peer? leafref +--ro bindings +--ro opaque-type-lspid +--ro fec-label* [lsp-id] +--ro lsp-id uint32 +--ro multipoint-type? multipoint-type +--ro peer* [direction peer advertisement-type] +--ro direction ldp:downstream-upstream +--ro peer leafref +--ro advertisement-type ldp:advertised-received +--ro label? rt-types:mpls-label +--ro mbb-role? enumeration Figure 5 5.2. Extended Following is a simplified graphical representation of the data model for mLDP extended operational state: module:ietf-mpls-mldpietf-mpls-mldp-extended augment/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global: +--rw/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:state/ldp:capability/mldp:mldp: +--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 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/ldp:capability: +--ro mldp{mldp}?+--rostatep2mp | +--ro enable? boolean+--rw address-family* [afi]+--rostatemp2mp | +--ro enable? boolean +--ro make-before-break +--ro enable? boolean +--ro switchover-delay? uint16 +--ro timeout? uint16 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/mldp:ipv4/mldp:state: +--ro multicast-only-frr {mldp-mofrr}? | +--ro prefix-list?ldp:prefix-list-refldp-ext:prefix-list-ref +--ro recursive-fec|+--ro prefix-list?ldp:prefix-list-ref +--ro ipv4 | +--ro roots | | +--ro root* [root-address] | |ldp-ext:prefix-list-ref augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/mldp:ipv4/mldp:state/mldp:roots/mldp:root/mldp:bindings/mldp:opaque-type-lspid/mldp:fec-label/mldp:peer: +--roroot-address inet:ipv4-address | |mofrr-role? mofrr-role augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp-ext:forwarding-nexthop/ldp-ext:interfaces/ldp-ext:interface/ldp-ext:address-family/ldp-ext:state: +--rois-self?mldp-disable? boolean| |augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/ldp:received-peer-state/ldp:capability/mldp:mldp: +--roreachability* [address interface] |hub-and-spoke | +--roaddress inet:ipv4-address | |enable? boolean +--rointerface ldp:mpls-interface-ref | |node-protection +--ropeer? leafref |plr? boolean +--robindings |merge-point? boolean augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/mldp:ipv4/mldp:state/mldp:roots/mldp:root/mldp:bindings: +--roopaque-type-lspid |opaque-type-transit | +--ro fec-label*[root-address lsp-id[source-address group-address rd recur-root-address recur-rd] ||+--roroot-address inet:ipv4-address |source-address inet:ip-address | +--rolsp-id uint32group-address inet:ip-address-no-zone | +--ro rd route-distinguisher | +--ro recur-root-address inet:ip-address ||+--ro recur-rd route-distinguisher ||+--ro multipoint-type?multipoint-type |mldp:multipoint-type | +--ro peer* [direction peer advertisement-type] ||+--ro direction ldp:downstream-upstream ||+--ro peer leafref ||+--ro advertisement-type ldp:advertised-received ||+--ro label?mpls:mpls-label |rt-types:mpls-label | +--ro mbb-role? enumeration ||+--ro mofrr-role?enumeration |mofrr-role +--roopaque-type-transit | |opaque-type-bidir +--ro fec-label*[root-address source-address[rp group-address... ] | | +--ro root-address inet:ipv4-address | |rd recur-root-address recur-rd] +--rosource-addressrp inet:ip-address| |+--ro group-address inet:ip-address-no-zone| |+--ro rd route-distinguisher| |+--ro recur-root-address inet:ip-address| |+--ro recur-rd route-distinguisher| |+--ro multipoint-type?multipoint-type | |mldp:multipoint-type +--ro peer* [direction peer advertisement-type]| |+--ro direction ldp:downstream-upstream| |+--ro peer leafref| |+--ro advertisement-type ldp:advertised-received| |+--ro label?mpls:mpls-label | |rt-types:mpls-label +--ro mbb-role? enumeration| |+--ro mofrr-role?enumeration | +--ro opaque-type-bidir | +--ro fec-label* [root-address rp group-address ... ] | +--ro root-address inet:ipv4-address | +--ro rp inet:ip-address | +--ro group-address inet:ip-address-no-zone |mofrr-role augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/mldp:ipv4/mldp:state/mldp:roots/mldp:root/mldp:bindings/mldp:opaque-type-lspid/mldp:fec-label: +--rord route-distinguisher |recursive-fec* [recur-root-address recur-rd] +--ro recur-root-address inet:ip-address|+--ro recur-rd route-distinguisher|+--ro multipoint-type?multipoint-type |mldp:multipoint-type +--ro peer* [direction peer advertisement-type]|+--ro direction ldp:downstream-upstream|+--ro peer leafref|+--ro advertisement-type ldp:advertised-received|+--ro label?mpls:mpls-label |rt-types:mpls-label +--ro mbb-role? enumeration|+--ro mofrr-role?enumeration +--romofrr-role augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families: +--rw ipv6 +--ro state +--ro roots|+--ro root* [root-address]|+--ro root-address inet:ipv6-address|+--ro is-self? boolean|+--ro reachability* [address interface] | +--ro address inet:ipv6-address | +--rointerface ldp:mpls-interface-refinterface ldp:mpls-interface-ref | +--ro peer? leafref +--ro bindings +--ro opaque-type-lspid | +--ro fec-label* [lsp-id] | +--ro lsp-id uint32 | +--ro multipoint-type? mldp:multipoint-type | +--ro peer* [direction peer advertisement-type] | | +--ro direction ldp:downstream-upstream | | +--ropeer?peer leafref | | +--robindingsadvertisement-type ldp:advertised-received | | +--roopaque-type-lspidlabel? rt-types:mpls-label | | +--rofec-label* [root-address lsp-id recur-root-address recur-rd]mbb-role? enumeration | | +--roroot-address inet:ipv6-addressmofrr-role? mofrr-role | +--rolsp-id uint32recursive-fec* [recur-root-address recur-rd] | +--ro recur-root-address inet:ip-address | +--ro recur-rd route-distinguisher | +--ro multipoint-type?multipoint-typemldp:multipoint-type | +--ro peer* [direction peer advertisement-type] | +--ro direction ldp:downstream-upstream | +--ro peer leafref | +--ro advertisement-type ldp:advertised-received | +--ro label?mpls:mpls-labelrt-types:mpls-label | +--ro mbb-role? enumeration | +--ro mofrr-role?enumerationmofrr-role +--ro opaque-type-transit | +--ro fec-label*[root-address source-address[source-address group-address... ] | +--ro root-address inet:ipv6-addressrd recur-root-address recur-rd] | +--ro source-address inet:ip-address | +--ro group-address inet:ip-address-no-zone | +--ro rd route-distinguisher | +--ro recur-root-address inet:ip-address | +--ro recur-rd route-distinguisher | +--ro multipoint-type?multipoint-typemldp:multipoint-type | +--ro peer* [direction peer advertisement-type] | +--ro direction ldp:downstream-upstream | +--ro peer leafref | +--ro advertisement-type ldp:advertised-received | +--ro label?mpls:mpls-labelrt-types:mpls-label | +--ro mbb-role? enumeration | +--ro mofrr-role?enumerationmofrr-role +--ro opaque-type-bidir +--ro fec-label*[root-address rp[rp group-address... ] +--ro root-address inet:ipv6-addressrd recur-root-address recur-rd] +--ro rp inet:ip-address +--ro group-address inet:ip-address-no-zone +--ro rd route-distinguisher +--ro recur-root-address inet:ip-address +--ro recur-rd route-distinguisher +--ro multipoint-type?multipoint-typemldp:multipoint-type +--ro peer* [direction peeradvertisement-type] +--roadvertisement-type] +--ro direction ldp:downstream-upstream +--ro peer leafref +--ro advertisement-type ldp:advertised-received +--ro label? rt-types:mpls-label +--ro mbb-role? enumeration +--ro mofrr-role? mofrr-role Figure 6 5.3. Derived states Following are main areas for which mLDP operational derived state is defined: o Root o Bindings (FEC-label) o Capabilities 5.3.1. Root state Root address is a fundamental construct for MP FEC bindings and LSPs. The root state provides information on all the known roots in a given address-familty, and their information on the root reachability (as learnt from RIB). In case of multi-path reachability to a root, the selection of upstream path is done on per-LSP basis at the time of LSP setup. Similarly, when protection mechanisms like MBB or MoFRR are in place, the path designation as active/standby or primary/ backup is also done on per LSP basis. It is to be noted that a given root can be shared amongst multiple P2MP and/or MP2MP LSPs. Moreover, an LSP can be signaled to more than one root for RNR purposes. The following diagram illustrates a root database on a branch/transit LSR: root 1.1.1.1: path1: RIB: GigEthernet 1/0, 12.1.0.2; LDP: peer 192.168.0.1:0 path2: RIB: GigEthernet 2/0, 12.2.0.2; LDP: peer 192.168.0.3:0 root 2.2.2.2: path1: RIB: 3.3.3.3; (NOTE: This is a recursive path) LDP: peer 192.168.0.3:0 (NOTE: T-mLDP peer) root 9.9.9.9: . . . . Figure 7 A root entry on a root LSR itself will be presented as follows: root 9.9.9.9: is-self Figure 8 5.3.2. Bindings state Binding state provides information on mLDP FEC-label bindings for both P2MP and MP2MP FEC types. Like LDP, the FEC-label binding derived state is presented in a FEC-centric view per address-family, and provides information on both inbound (received) and outbound (advertised) bindings. The FEC is presented as (root-address, opaque-type-data) as described earlier in section Section 3.2, and the directionldp:downstream-upstream +--ro(upstream or downstream) is picked with respect to root reachability. In case of MBB or/and MoFRR, the role of a given peerleafref +--ro advertisement-type ldp:advertised-received +--ro label? mpls:mpls-label +--ro mbb-role? enumeration +--ro mofrr-role? enumeration augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:forwarding-nexthop/ldp:interfaces/ldp:interface/ldp:address-family/ldp:state: +--ro mldp-disable? boolean {mldp}? augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:state/ldp:capability: +--ro 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 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/ldp:capability: +--robinding is also provided with respect to MBB (active or standby) or/ and MoFRR (primary or backup). Following captures a high level tree hierarchy for mLDP bindings state: +--rw mpls-ldp! +--rw global +--rw mldp{mldp}? +--ro p2mp | +--ro enable? boolean +--ro mp2mp | +--ro enable? boolean +--ro make-before-break | +--ro enable? boolean | +--ro switchover-delay? uint16 |+--rw address-families +--rw ipv4 (or ipv6) +--rotimeout? uint16state +--rohub-and-spoke {capability-mldp-hsmp}? |roots +--roenable? booleanroot* [root-address] +--ronode-protection {capability-mldp-node-protection}?.... +--roplr? booleanbindings +--romerge-pointopaque-type-xxx | +--roenable? booleanfec-label* [type-specific-key] | +--rotargeted-session-teardown-delay? uint16 augment /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/ldp:received-peer-state/ldp:capability:some_key_1 ... | +--romldp {mldp}?some_key_2 ... | +--rop2mpmultipoint-type? multipoint-type | +--roenable? booleanpeer* [direction peer advertisement-type] | | +--romp2mpdirection ldp:downstream-upstream | | +--roenable? booleanpeer leafref | | +--romake-before-breakadvertisement-type ldp:advertised-received | | +--roenable? booleanlabel? rt-types:mpls-label | | +--rohub-and-spokembb-role? enumeration | | +--roenable? booleanmldp-ext:mofrr-role? mofrr-role +--ronode-protectionopaque-type-yyy | +--roplr? booleanfec-label* [type-specific-key] | +--romerge-point? booleansome_key_1 ... ... Figure3 5.1. Derived states Following are main areas for which9 mLDPoperational derivedbinding state isdefined: o Root o Bindings (FEC-label) o Capabilities 5.1.1. Rootorganized and presented per root address, and hence the bindings container hang off a root node in the model. The bindings stateRoot addressisa fundamental constructmade available forMP FEC bindings and LSPs. The rootFECs pertaining to different types of opaque types, with some stateprovides information on allavaiable under "base" tree and theknown rootsrest under "extended". In the above tree, the various opaque types alongwith their type specific key(s) refer to the table Table 1 captured earlier in the document. For example, if the opaque type is Generic LSP Identifier, then the type-specific-key will be agiven address-familty, and their information onuint32 LSP-Id key. Please see theroot reachability (as learnt from RIB).complete model for all other types. It is important to take note of the following: o The address-family ipv4/ipv4 applies to "root" address in the mLDP binding tree. The other addresses (source, group, RP etc) do not have to be of the same address family type as the root. o The "recur-root-address" field applies to Recursive opaque type, and (recur-root-address, recur-rd) fields applies to VPN-Recursive opaque types as defined in [RFC6512] o In case ofmulti-path reachability toaroot, the selection of upstream path is done on per-LSP basis atrecursive FEC, thetimeaddress-family ofLSP setup. Similarly, when protection mechanisms like MBB or MoFRR are in place,thepath designation as active/standby or primary/ backup is also done on per LSP basis. It is to be noted that a given root can be shared amongst multiple P2MP and/or MP2MP LSPs. Moreover, an LSP canrecur-root- address could besignaled to moredifferent thanonethe address-family of the rootfor RNR purposes.address of original encapsulated MP FEC The following diagram illustrates the FEC-label binding information structure for aroot databaseP2MP (Transit IPv4 Source type) LSP on abranch/transitbranch/ transit LSR:root 1.1.1.1: path1: RIB: GigEthernet 1/0, 12.1.0.2; LDP:FEC (root 2.2.2.2, S=192.168.1.1, G=224.1.1.1): type: p2mp upstream: advertised: peer192.168.0.1:0 path2: RIB: GigEthernet 2/0, 12.2.0.2; LDP:192.168.0.1:0, label 16000 (local) downstream: received: peer192.168.0.3:0 root 2.2.2.2: path1: RIB: 3.3.3.3; (NOTE: This is a recursive path) LDP:192.168.0.2:0, label 17000 (remote) peer192.168.0.3:0 (NOTE: T-mLDP peer) root 9.9.9.9: . . . .192.168.0.3:0, label 18000 (remote) Figure4 A root entry10 The following diagram illustrates the FEC-label binding information structure for a similar MP2MP LSP on aroot LSR itself will be presented as follows: root 9.9.9.9: is-self Figure 5 5.1.2. Bindings state Bindingbranch/transit LSR: FEC (root 2.2.2.2, RP=192.168.9.9, G=224.1.1.1): type: mp2mp upstream: advertised: peer 192.168.0.1:0, label 16000 (local) received: peer 192.168.0.1:0, label 17000 (remote) downstream: advertised: peer 192.168.0.2:0, label 16001 (local), MBB role=active peer 192.168.0.3:0, label 16002 (local), MBB role=standby received: peer 192.168.0.2:0, label 17001 (remote) peer 192.168.0.3:0, label 18001 (remote) Figure 11 5.3.3. Capabilities stateprovides information on mLDP FEC-label bindings for both P2MP and MP2MP FEC types.Like LDP,the FEC-label binding derivedmLDP capabilities stateis presented in a FEC-centric view per address-family, and provides information on both inbound (received) and outbound (advertised) bindings. The FEC is presented as (root-address, opaque-type-data) and the direction (upstream or downstream) is picked with respect to root reachability. In casecomprise two types ofMBB or/and MoFRR, the roleinformation: o global: augments ldp:global/ldp:state/ldp:capability. o per-peer: augments ldp:peers/ldp:peer/ldp:state/ldp:capability 6. Notifications mLDP notification module consists ofa given peer binding is also provided with respectnotification related toMBB (active or standby) or/and MoFRR (primary or backup). This document covers following type of opaque values with their keyschanges in the operationalmodelstate of an mLDPbindings: +-------------------------+--------------------+------------+ | Opaque Type | Key | RFC | +-------------------------+--------------------+------------+ | Generic LSP Identifier | LSP Id | [RFC6388] | | Transit IPv4 Source | Source, Group | [RFC6826] | | Transit IPv6 Source | Source, Group | [RFC6826] | | Transit IPv4 Bidir | RP, Group | [RFC6826] | | Transit IPv6 Bidir | RP, Group | [RFC6826] | | Transit VPNv4 Source | Source, Group, RD | [RFC7246] | | Transit VPNv6 Source | Source, Group, RD | [RFC7246] | | Transit VPNv4 Bidir | RP, Group, RD | [RFC7246] | | Transit VPNv6 Bidir | RP, Group, RD | [RFC7246] | | Recursive Opaque | Root | [RFC6512] | | VPN-Recursive Opaque | Root, RD | [RFC6512] | +-------------------------+--------------------+------------+ Table 1: MP Opaque Types and keys ItFEC. 6.1. Base Following is a simplified graphical representation of the base data model for mLDP notifications: module: ietf-mpls-mldp notifications: +---n mpls-mldp-fec-event +--ro event-type? ldp:oper-status-event-type +--ro tree-type? multipoint-type +--ro root? inet:ip-address +--ro (lsp-key-type)? +--:(lsp-id) +--ro lsp-id? uint16 Figure 12 6.2. Extended Following isto be noteda simplified graphical representation of the extended data model for mLDP notifications: module: ietf-mpls-mldp augment /mldp:mpls-mldp-fec-event/mldp:lsp-key-type: +--:(source-group-based) +---- source-address? inet:ip-address +---- group-address? inet:ip-address Figure 13 7. Actions Currently, no RPCs/actions are defined for mLDP. 8. Open Items Following is a list of open items thattherearethree basic types (LSP Id, Source,to be discussed andBidir)addressed in future revisions of this document: o Align operational state modeling with other routing protocols andthen there are variants (VPN, recursive, VPN- recursive) on top[I-D.openconfig-netmod-opstate] o Specify default values for configuration parameters o Extend the "Configured Leaf LSPs" for various type ofthese basic types.opaque-types o Extend mLDP notifications for other types of opaque values as well o Make MP LSP configuration and state model consistent 9. YANG Specification Followingcaptures a high level tree hierarchyis the actual YANG definition (module) for mLDP constructs defined earlier in the document. 9.1. Base <CODE BEGINS> file "ietf-mpls-mldp@2017-03-12.yang" module ietf-mpls-mldp { namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-mldp"; prefix "mldp"; import ietf-inet-types { prefix "inet"; } import ietf-routing { prefix "rt"; } import ietf-routing-types { prefix "rt-types"; } import ietf-mpls-ldp { prefix "ldp"; } organization "IETF MPLS Working Group"; contact "WG Web: <http://tools.ietf.org/wg/teas/> WG List: <mailto:teas@ietf.org> WG Chair: Loa Andersson <mailto:loa@pi.nu> WG Chair: Ross Callon <mailto:rcallon@juniper.net> WG Chair: George Swallow <mailto:swallow.ietf@gmail.com> Editor: Kamran Raza <mailto:skraza@cisco.com> Editor: Rajiv Asati <mailto:rajiva@cisco.com> Editor: Xufeng Liu <mailto:Xufeng_Liu@jabil.com> Editor: Santosh Esale <mailto:sesale@juniper.net> Editor: Xia Chen <mailto:jescia.chenxia@huawei.com> Editor: Himanshu Shah <mailto:hshah@ciena.com>"; description "This YANG module defines the essential components formLDP bindings state: +--rw mldp (augmentationthe management ofldp:global) +--rw address-family* [afi] +--rw afi address-family +--ro state +--ro ipv4 (or ipv6) +--ro bindings +--ro opaque-type-xxx [root-address, type-specific-key] +--ro root-address +--ro ... +--ro recur-root-address inet:ipv4-address +--ro recur-rd route-distinguisher +--ro multipoint-type?Multi-Protocol Label Switching (MPLS) Multipoint LDP (mLDP)."; revision 2017-03-12 { description "Initial revision."; reference "RFC XXXX: YANG Data Model for MPLS mLDP."; } /* * Typedefs */ typedef multipoint-type+--ro peer* [direction{ type enumeration { enum p2mp { description "Point to multipoint."; } enum mp2mp { description "Multipoint to multipoint."; } } description "p2mp or mp2mp."; } /* * Groupings */ 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."; } } } // mldp-capabilities grouping mldp-fec-event { description "A mLDP FEC event."; 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 { leaf lsp-id { type uint16; description "ID to identify the LSP."; } } } } // mldp-fec-event grouping mldp-binding-label-peer-state-attributes { description "mLDP label binding per peeradvertisement-type] +--roattributes."; leaf directiondownstream-upstream +--ro{ type ldp:downstream-upstream; description "Downstream or upstream."; } leaf peer { type leafref+--ro{ path "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:lsr-id"; } description "LDP peer from which this binding is received, or to which this binding is advertised."; } leaf advertisement-typeadvertised-received +--ro label? mpls:mpls-label +--ro mbb-role? enumeration +--ro mofrr-role? enumeration Figure 6 In the above tree, the type-specific-key varies with the base{ typeas listed in earlier Table 1. For example, if the opaqueldp:advertised-received; description "Advertised or received."; } leaf label { type rt-types:mpls-label; description "Advertised (outbound) or received (inbound) label."; } leaf mbb-role { when "../direction = 'upstream'" { description "For upstream."; } type enumeration { enum none { description "MBB isGenericnot enabled."; } enum active { description "This LSPIdentifier, then the type-specific-key will be a uint32 value corresponding to the LSP. Please see the complete model for all other types. Moreover, theis active."; } enum inactive { description "This LSP is inactive."; } } description "The MBB status of this LSP."; } } // mldp-binding-label-peer-state-attributes grouping mldp-binding-label-state-attributes { description "mLDP label bindingtree defines only three typesattributes."; leaf multipoint-type { type multipoint-type; description "The type of mutipoint, p2mp or mp2mp."; } list peer { key "direction peer advertisement-type"; description "List of advertised and received peers."; uses mldp-binding-label-peer-state-attributes; } // peer } // mldp-binding-label-state-attributes grouping mldp-ipv4-configured-lsp-roots { description "mLDP IPv4 roots containers."; container roots { description "Configured IPv4 multicast LSPs."; list root { key "root-address"; description "List of roots for configured multicast LSPs."; leaf root-address { type inet:ipv4-address; description "Root address."; } choice lsp-key-type { description "LSP ID based or source-group based ."; case lsp-id { container opaque-type-lspid { description "The type ofsub-trees (i.e. lspid, src, and bidir) whichopaque value element isable to map the respective variants (vpn, recursive, and vpn-recusrive) accordingly. For example,the generic LSP identifier"; list lsp { keyfor opaque-type-src is [R, S, G, rd, recur-R, recur- RD], where basic"lsp-id"; description "List of LSPs."; leaf lsp-id { typewill specify (R, S,G,-, -, -), VPNuint16; description "ID to identify the LSP."; } } // list lsp } // opaque-type-lspid } // case lsp-id } // choice lsp-key-type } // list root } // roots } // mldp-ipv4-configured-lsp-roots /* * Configuration data nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/ldp:config/ldp:capability" { description "Augmentation for MLDP global capability."; container mldp { description "Multipoint capabilities."; uses mldp-capabilities; } } /* * Operational state data nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/ldp:state/ldp:capability" { description "Augmentation for MLDP global capability."; container mldp { description "Multipoint capabilities."; uses mldp-capabilities; } } augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/" + "ldp:received-peer-state/ldp:capability" { description "Augmentation for MLDP received peer state capability."; container mldp { description "Multipoint capabilities."; container p2mp { description "Configure point-to-multipoint capability."; leaf enable { typewill specify (R, S,G, rd, -, -), recursiveboolean; description "Enable point-to-multipoint."; } } container mp2mp { description "Configure multipoint-to-multipoint capability."; leaf enable { typewill specify [R, S,G, -, recur-R, -] and VPN-recursiveboolean; description "Enable multipoint-to-multipoint."; } } container make-before-break { description "Configure make-before-break capability."; leaf enable { typewill specify [R, S,G, -, recur-R, recur-rd]. It is important to take note of the following: o The address-family ipv4/ipv4 applies to "root" address in the mLDP binding tree. The other addresses (source, group, RP etc) doboolean; description "Enable make-before-break."; } } } // mldp } /* * Global augmentation */ augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global" { description "MLDP global augmentation."; container mldp { description "mLDP attributes at per instance level. Defining attributes here does nothaveenable any MP capabilities. MP capabilities need to beof the same address familyexplicitly enabled under container capability."; container config { description "Configuration data."; leaf enable { typeas the root. o The "recur-root-address" field applies to Recursive opaque type, and (recur-root-address, recur-rd) fields applies to VPN-Recursive opaque types as defined in [RFC6512] o In case of a recursive FEC, the address-family of the recur-root- address could be different than the address-family of the root address of original encapsulated MP FEC The following diagram illustrates the FEC-label binding information structure for a P2MP (Transit IPv4 Source type) LSP on a branch/ transit LSR: FEC (root 2.2.2.2, S=192.168.1.1, G=224.1.1.1): type: p2mp upstream: advertised: peer 192.168.0.1:0, label 16000 (local) downstream: received: peer 192.168.0.2:0, label 17000 (remote) peer 192.168.0.3:0, label 18000 (remote) Figure 7 The following diagram illustrates the FEC-label binding information structure for a similar MP2MP LSP on a branch/transit LSR: FEC (root 2.2.2.2, RP=192.168.9.9, G=224.1.1.1): type: mp2mp upstream: advertised: peer 192.168.0.1:0, label 16000 (local) received: peer 192.168.0.1:0, label 17000 (remote) downstream: advertised: peer 192.168.0.2:0, label 16001 (local), MBB role=active peer 192.168.0.3:0, label 16002 (local), MBB role=standby received: peer 192.168.0.2:0, label 17001 (remote) peer 192.168.0.3:0, label 18001 (remote) Figure 8 5.1.3. Capabilitiesboolean; description "Enable mLDP."; } } container stateLike LDP, mLDP capabilities{ config false; description "Operational statecomprise two types of information: o global: augments ldp:global/ldp:state/ldp:capability. o per-peer: augments ldp:peers/ldp:peer/ldp:state/ldp:capability 6. Notifications mLDP notification module consists of notification related to changes in the operationaldata."; leaf enable { type boolean; description "Enable mLDP."; } } container address-families { description "Per-af params."; container ipv4 { description "IPv4 information."; container state { config false; description "Operational state data."; container roots { description "IPv4 multicast LSP roots."; list root { key "root-address"; description "List ofan mLDP FEC. Followingroots for configured multicast LSPs."; leaf root-address { type inet:ipv4-address; description "Root address."; } leaf is-self { type boolean; description "This isa simplified graphical representation ofthedata model for mLDP notifications: module: ietf-mpls-mldp notifications: +---n mpls-mldp-fec-event +--ro event-type? ldp:oper-status-event-type +--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-address? inet:ip-address +--ro group-address? inet:ip-address Figure 9 7. Actions Currently, no RPCs/actions are definedroot."; } list reachability { key "address interface"; description "A next hop formLDP. 8. Open Items Following isreachability to root, as alist of open items that areRIB view."; leaf address { type inet:ipv4-address; description "The next hop address tobe discussed and addressed in future revisions of this document: o Revisit and cut down on the scope of the document and number of features it is tryingreach root."; } leaf interface { type ldp:mpls-interface-ref; description "Interface connecting tocover o Split the model into a base and extended items o Align operational state modeling with other routing protocols and [I-D.openconfig-netmod-opstate] o Specify default values for configuration parameters o Add statistics for mLDP root LSPs andnext-hop."; } leaf peer { type leafref { path "../../../../../../../../../ldp:peers/" + "ldp:peer/ldp:lsr-id"; } description "LDP peer from which this next hop can be reached."; } } container bindingso Extend the "Configured Leaf LSPs" for various{ description "mLDP FEC to label bindings."; container opaque-type-lspid { description "The type ofopaque-types o Extend mLDP notifications for other types ofopaquevalues as well 9. YANG Specification Followingvalue element is theactual YANG definitiongeneric LSP identifier"; reference "RFC6388: Label Distribution Protocol Extensions formLDP constructs defined earlier inPoint-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths."; list fec-label { key "lsp-id"; description "List of FEC to label bindings."; leaf lsp-id { type uint32; description "ID to identify thedocument.LSP."; } uses mldp-binding-label-state-attributes; } // fec-label } // opaque-type-lspid } // bindings } // list root } // roots } // state container configured-leaf-lsps { description "Configured multicast LSPs."; container p2mp { description "Configured point-to-multipoint LSPs."; uses mldp-ipv4-configured-lsp-roots; } container mp2mp { description "Configured multipoint-to-multipoint LSPs."; uses mldp-ipv4-configured-lsp-roots; } } // configured-leaf-lsps } // ipv4 } // list address-family } // mldp } /* * Notifications */ notification mpls-mldp-fec-event { description "Notification event for a change of FEC status."; leaf event-type { type ldp:oper-status-event-type; description "Event type."; } uses mldp-fec-event; } } <CODE ENDS> Figure 14 9.2. Extended <CODE BEGINS> file"ietf-mpls-mldp@2016-11-01.yang" -->"ietf-mpls-mldp-extended@2017-03-12.yang" moduleietf-mpls-mldpietf-mpls-mldp-extended { namespace"urn:ietf:params:xml:ns:yang:ietf-mpls-mldp";"urn:ietf:params:xml:ns:yang:ietf-mpls-mldp-extended"; prefixmldp;"mldp-ext"; import ietf-inet-types { prefix "inet"; } import ietf-routing { prefix "rt"; } importietf-mplsietf-mpls-ldp { prefix"mpls";"ldp"; } importietf-mpls-ldpietf-mpls-ldp-extended { prefix"ldp";"ldp-ext"; } import ietf-mpls-mldp { prefix "mldp"; } organization "IETF MPLS Working Group"; contact "WG Web:<http://tools.ietf.org/wg/mpls/><http://tools.ietf.org/wg/teas/> WG List:<mailto:mpls@ietf.org><mailto:teas@ietf.org> WG Chair: Loa Andersson <mailto:loa@pi.nu> WG Chair: Ross Callon <mailto:rcallon@juniper.net> WG Chair: George Swallow <mailto:swallow.ietf@gmail.com> Editor: Kamran Raza <mailto:skraza@cisco.com> Editor: Rajiv Asati <mailto:rajiva@cisco.com> Editor: Xufeng Liu<mailto:xliu@kuatrotech.com><mailto:Xufeng_Liu@jabil.com> Editor: Santosh Esale <mailto:sesale@juniper.net> Editor: Xia Chen <mailto:jescia.chenxia@huawei.com> Editor: Himanshu Shah<mailto:hshah@ciena.com> Editor: Sowmya Krishnaswamy <mailto:sowkrish@cisco.com>";<mailto:hshah@ciena.com>"; description "This YANG module defines the essential components for the management of Multi-Protocol Label Switching (MPLS) Multipoint LDP (mLDP)."; revision2016-11-012017-03-12 { description "Initial revision."; reference "RFC XXXX: YANG Data Model for MPLS mLDP."; } /* * Features */ 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."; } featuremldpmldp-mofrr { description "This feature indicates that the system supports mLDP MulticastLDP (mLDP).";only FRR (MoFRR)."; } featuremldp-mofrrper-peer-capability { description "This feature indicates that the systemsupportsallows to configure mLDPMulticast only FRR (MoFRR).";capabilities at the per peer level."; } /* * Typedefs */ typedefmultipoint-typeroute-distinguisher { type string { } description "Type definition for route distinguisher."; reference "RFC4364: BGP/MPLS IP Virtual Private Networks (VPNs)."; } typedef mofrr-role { type enumeration { enump2mpnone { description"Point to multipoint.";"MOFRR is not enabled."; } enummp2mpprimary { description"Multipoint to multipoint."; } } description "p2mp or mp2mp.";"This LSP is primary."; }typedef route-distinguisher { type stringenum backup { description "This LSP is backup."; } } description"Type definition for route distinguisher."; reference "RFC4364: BGP/MPLS IP Virtual Private Networks (VPNs).";"This type represents the MOFRR (Multicast only FRR) role status of a LSP."; } /* * Groupings */ groupingmldp-capabilitiesmldp-ext-binding-label-state-attributes { description "mLDPcapabilities."; container p2mp { description "Configure point-to-multipoint capability.";label binding attributes."; leafenablemultipoint-type { typeboolean; description "Enable point-to-multipoint."; } } container mp2mp {mldp:multipoint-type; description"Configure multipoint-to-multipoint capability."; leaf enable {"The typeboolean; description "Enable multipoint-to-multipoint."; }of mutipoint, p2mp or mp2mp."; }container make-before-breaklist peer { key "direction peer advertisement-type"; description"Configure make-before-break capability.";"List of advertised and received peers."; uses mldp:mldp-binding-label-peer-state-attributes; leafenablemofrr-role {type boolean; description "Enable make-before-break."; } leaf switchover-delaywhen "../direction = 'upstream'" {type uint16; units seconds;description"Switchover delay in seconds.";"For upstream."; }leaf timeout {typeuint16; units seconds;mofrr-role; description"Timeout in seconds.";"The MOFRR status of this LSP."; } } // peer } // mldp-ext-binding-label-state-attributes grouping mldp-ext-capabilities { description "mLDP extended capabilities."; container hub-and-spoke { 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 "RFC7715: 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 { when "../../../afi = 'ipv4'" { description "Only for IPv4."; } description "Configured IPv4 multicast LSPs."; list root { key "root-address"; description "List of roots for configured multicast LSPs."; leaf root-address { type inet:ipv4-address; description "Root address."; } list lsp { must "(lsp-id = 0 and source-address != '0.0.0.0' and " + "group-address != '0.0.0.0') or " + "(lsp-id != 0 and source-address = '0.0.0.0' and " + "group-address = '0.0.0.0')" { description "A LSP can be identified by either <lsp-id> or <source-address, group-address>."; } key "lsp-id source-address group-address"; description "List of LSPs."; leaf lsp-idcontainer merge-point {type uint16;description"ID to identify the LSP."; }"Merge Point capable for MP LSP node protection."; leafsource-addressenable { typeinet:ipv4-address;boolean; description"Source address.";"Enable merge point capability."; } leafgroup-addresstargeted-session-teardown-delay { typeinet:ipv4-address-no-zone;uint16; units seconds; description"Group address.";"Targeted session teardown delay."; } } //list lspmerge-point }// list root} //roots-ipv4 container roots-ipv6 { when "../../../afi = 'ipv6'"mldp-ext-capabilities grouping mldp-ipv6-configured-lsp-roots { description"Only for IPv6."; }"mLDP IPv6 roots containers."; container roots { description "Configured IPv6 multicast LSPs."; list root { key "root-address"; description "List of roots for configured multicast LSPs."; leaf root-address { type inet:ipv6-address; description "Root address."; }list lspchoice lsp-key-type {must "(lsp-id = 0 and source-address != '::' and " + "group-address != '::')description "LSP ID based or" + "(lsp-id != 0 and source-address = '::' and " + "group-address = '::')"source-group based ."; case lsp-id { container opaque-type-lspid { description"A"The type of opaque value element is the generic LSPcan be identified by either <lsp-id> or <source-address, group-address>."; }identifier"; list lsp { key"lsp-id source-address group-address";"lsp-id"; description "List of LSPs."; leaf lsp-id { type uint16; description "ID to identify the LSP."; }leaf source-address { type inet:ipv6-address; description "Source address."; } leaf group-address { type inet:ipv6-address-no-zone; description "Group address."; }} // list lsp } //list root } // roots-ipv6opaque-type-lspid } //mldp-configured-lsp-roots grouping mldp-fec-event { description "A mLDP FEC event."; 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 .";caselsp-id-based { leaflsp-id case source-group { container opaque-type-transit {type uint16;description"ID to identify"The type of opaque value element is theLSP."; } } case source-group-basedtransit IPv6 source."; list lsp { key "source-address group-address"; description "List of LSPs."; leaf source-address { typeinet:ip-address;inet:ipv6-address; description"LSP source"Source address."; } leaf group-address { typeinet:ip-address;inet:ipv6-address-no-zone; description"Multicast group"Group address."; } } } } // casesource-group-based }source-group } //mldp-fec-event grouping mldp-binding-label-state-attributes { description "mLDP label binding attributes."; leaf multipoint-type { type multipoint-type; description "The type of mutipoint, p2mp or mp2mp.";choice lsp-key-type } // listpeerroot } // roots } // mldp-ipv6-configured-lsp-roots grouping mldp-ext-per-af-config-attibutes {key "direction peer advertisement-type";description"List of advertised and received peers."; leaf direction"mLDP per address family configuration attibutes."; container multicast-only-frr {type ldp:downstream-upstream;if-feature mldp-mofrr; description"Downstream or upstream."; }"Multicast only FRR (MoFRR) policy."; leafpeerprefix-list { typeleafref { path "../../../../../../../../../../ldp:peers/ldp:peer/ldp:lsr-id"; }ldp-ext:prefix-list-ref; description"LDP peer from which this binding is received, or to which this binding is advertised.";"Enables MoFRR for the specified access list."; }leaf advertisement-type} // multicast-only-frr container recursive-fec {type ldp:advertised-received;description"Advertised or received."; }"Recursive FEC policy."; leaflabelprefix-list { typempls:mpls-label;ldp-ext:prefix-list-ref; description"Advertised (outbound) or received (inbound) label.";"Enables recursive FEC for the specified access list."; }leaf mbb-role { when "../direction = 'upstream'"} // recursive-for } // mldp-ext-per-af-config-attibutes /* * Configuration data nodes */ // Global capability config augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/ldp:config/ldp:capability/" + "mldp:mldp" { description"For upstream.";"Augmentation for MLDP global capability."; uses mldp-ext-capabilities; }type enumeration// Peer capability config augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:config/ldp:capability" {enum nonedescription "Augmentation for MLDP peer capability."; container mldp { if-feature per-peer-capability; description"MBB is not enabled.";"mLDP capabilities."; uses mldp:mldp-capabilities; }enum active} // IPv4 config augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "mldp:ipv4" { description"This LSP is active."; } enum inactive"Augmentation for MLDP IPv4 configuration."; container config { description"This LSP is inactive.";"Configuration data."; uses mldp-ext-per-af-config-attibutes; } } // IPv4 configured-leaf-lsps config augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "mldp:ipv4/mldp:configured-leaf-lsps/mldp:p2mp/mldp:roots/" + "mldp:root/mldp:lsp-key-type" { description"The MBB status of this LSP."; } leaf mofrr-role"Augmentation for MLDP IPv4 configured-leaf-lsps configuration."; case source-group {when "../direction = 'upstream'"container opaque-type-transit { description"For upstream."; }"The typeenumeration { enum noneof opaque value element is the transit IPv4 source."; list lsp { key "source-address group-address"; description"MOFRR is not enabled."; } enum primary"List of LSPs."; leaf source-address { type inet:ipv4-address; description"This LSP is primary.";"Source address."; }enum backupleaf group-address { type inet:ipv4-address-no-zone; description"This LSP is backup.";"Group address."; } }description "The MOFRR status of this LSP.";} } //peercase source-group }// mldp-binding-label-state-attributes /* * Configuration data nodes */augment "/rt:routing/rt:control-plane-protocols/" +"ldp:mpls-ldp/ldp:global/ldp:config/ldp:capability""ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "mldp:ipv4/mldp:configured-leaf-lsps/mldp:mp2mp/mldp:roots/" + "mldp:root/mldp:lsp-key-type" { description "Augmentation for MLDPglobal capability.";IPv4 configured-leaf-lsps configuration."; case source-group { containermldpopaque-type-transit { description"Multipoint capabilities."; uses mldp-capabilities;"The type of opaque value element is the transit IPv4 source."; list lsp { key "source-address group-address"; description "List of LSPs."; leaf source-address { type inet:ipv4-address; description "Source address."; } leaf group-address { type inet:ipv4-address-no-zone; description "Group address."; } } } } // case source-group } // IPv6 config augment "/rt:routing/rt:control-plane-protocols/" +"ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:config/ldp:capability""ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "ipv6" { description "Augmentation for MLDPpeer capability.";IPv4 configuration."; containermldpconfig {if-feature mldp;description"mLDP capabilities.";"Configuration data."; usesmldp-capabilities;mldp-ext-per-af-config-attibutes; } } // Global forwarding-nexthop config augment "/rt:routing/rt:control-plane-protocols/" +"ldp:mpls-ldp/ldp:global/ldp:forwarding-nexthop/""ldp:mpls-ldp/ldp:global/ldp-ext:forwarding-nexthop/" +"ldp:interfaces/ldp:interface/ldp:address-family/""ldp-ext:interfaces/ldp-ext:interface/ldp-ext:address-family/" +"ldp:config""ldp-ext:config" { description "Augmentation for MLDP nexthop forwarding interface."; leaf mldp-disable {if-feature mldp;type boolean; description "Disable mLDP forwarding on the interface."; } } /* * Operational state data nodes */ // Global capability state augment "/rt:routing/rt:control-plane-protocols/" +"ldp:mpls-ldp/ldp:global/ldp:state/ldp:capability""ldp:mpls-ldp/ldp:global/ldp:state/ldp:capability/" + "mldp:mldp" { description "Augmentation for MLDP global capability.";container mldp { description "Multipoint capabilities.";usesmldp-capabilities; }mldp-ext-capabilities; } // Peer capability state augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/ldp:capability" { description "Augmentation for MLDP peer capability."; container mldp {if-feature mldp;description "mLDP capabilities."; usesmldp-capabilities;mldp:mldp-capabilities; } } // IPv4 state augment "/rt:routing/rt:control-plane-protocols/" +"ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/""ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" +"ldp:received-peer-state/ldp:capability""mldp:ipv4/mldp:state" { description "Augmentation for MLDPreceived peer state capability."; container mldp { if-feature mldp; description "Multipoint 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."; }IPv4 state."; uses mldp-ext-per-af-config-attibutes; }container hub-and-spoke { description "Configure hub-and-spoke-multipoint capability."; reference "RFC7140: LDP Extensions// IPv4 state forHub and Spoke Multipoint Label Switched Path"; leaf enable { type boolean; description "Enable hub-and-spoke-multipoint."; } } container node-protection { description "Configure node-protection capability."; reference "RFC7715: mLDP Node Protection."; leaf plrper peer bindings augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "mldp:ipv4/mldp:state/mldp:roots/mldp:root/mldp:bindings/" + "mldp:opaque-type-lspid/mldp:fec-label/mldp:peer" {type boolean;description"Point of Local Repair capable"Augmentation forMP LSP node protection."; }MLDP IPv4 state."; leafmerge-pointmofrr-role { when "../mldp:direction = 'upstream'" { description "For upstream."; } typeboolean;mofrr-role; description"Merge Point capable for MP LSP node protection.";"The MOFRR status of this LSP."; }// merge-point} //node-protectionIPv6 state augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "ipv6/state" { description "Augmentation for MLDP IPv6 state."; uses mldp-ext-per-af-config-attibutes; } //mldp }Global forwarding-nexthop config augment "/rt:routing/rt:control-plane-protocols/" +"ldp:mpls-ldp/ldp:global/ldp:forwarding-nexthop/""ldp:mpls-ldp/ldp:global/ldp-ext:forwarding-nexthop/" +"ldp:interfaces/ldp:interface/ldp:address-family/""ldp-ext:interfaces/ldp-ext:interface/ldp-ext:address-family/" +"ldp:state""ldp-ext:state" { description "Augmentation for MLDP nexthop forwarding interface."; leaf mldp-disable {if-feature mldp;type boolean; description "Disable mLDP forwarding on the interface."; } }/* * Global augmentation */// Peer capability state augment "/rt:routing/rt:control-plane-protocols/" +"ldp:mpls-ldp/ldp:global" { description "MLDP global augmentation."; container mldp"ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:state/" + "ldp:received-peer-state/ldp:capability/mldp: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"Augmentation for MLDP received peer state capability."; containerconfighub-and-spoke { description"Configuration data.";"Configure hub-and-spoke-multipoint capability."; reference "RFC7140: LDP Extensions for Hub and Spoke Multipoint Label Switched Path"; leaf enable { type boolean; description "EnablemLDP.";hub-and-spoke-multipoint."; } } containerstatenode-protection {config false;description"Operational state data.";"Configure node-protection capability."; reference "RFC7715: mLDP Node Protection."; leafenableplr { type boolean; description"Enable mLDP."; } } list address-family { key "afi"; description "Per-af params."; leaf afi { type ldp:ldp-address-family; 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 ldp: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 ldp: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; description "Multicast only FRR (MoFRR) policy."; leaf prefix-list { type ldp:prefix-list-ref; description "Enables MoFRR"Point of Local Repair capable forthe specified access list."; }MP LSP node protection."; }// multicast-only-frr container recursive-fec { description "Recursive FEC policy.";leafprefix-listmerge-point { typeldp:prefix-list-ref;boolean; description"Enables recursive FEC"Merge Point capable forthe specified access list.";MP LSP node protection."; } // merge-point } //recursive-fec container ipv4 { when "../../afi = 'ipv4'"node-protection } // IPv4 bindings state augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "mldp:ipv4/mldp:state/mldp:roots/mldp:root/mldp:bindings" { description"Only"Augmentation forIPv4."; } description "IPv4 state information.";MLDP IPv4 bindings."; containerrootsopaque-type-transit { description"IPv4 multicast LSP roots.";"The type of opaque value element is the transit IPv4 source."; reference "RFC6826: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths."; listrootfec-label { key"root-address";"source-address group-address " + "rd recur-root-address recur-rd"; description "List ofroots for configured multicast LSPs.";FEC to label bindings."; leafroot-addresssource-address { typeinet:ipv4-address;inet:ip-address; description"Root"Source address."; } leafis-selfgroup-address { typeboolean;inet:ip-address-no-zone; description"This is the root.";"Group address."; }list reachability { key "address interface"; description "A next hop for reachability to root, as a RIB view.";leafaddressrd { typeinet:ipv4-address;route-distinguisher; description"The next hop address to reach root.";"Route Distinguisher."; reference "RFC7246: Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context."; } leafinterfacerecur-root-address { typeldp:mpls-interface-ref;inet:ip-address; description"Interface connecting"Recursive root address."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route tonext-hop.";the Root"; } leafpeerrecur-rd { typeleafref { path "../../../../../../../../../ldp:peers/" + "ldp:peer/ldp:lsr-id"; }route-distinguisher; description"LDP peer from which this next hop can be reached."; }"Route Distinguisher in the VPN-Recursive Opaque Value."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } uses mldp-ext-binding-label-state-attributes; } //list rootfec-label } //roots container bindings { description "mLDP FEC to label bindings.";opaque-type-transit containeropaque-type-lspidopaque-type-bidir { description "The type of opaque value element is the generic LSP identifier"; reference"RFC6388: Label Distribution Protocol Extensions"RFC6826: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths."; list fec-label { key"root-address lsp-id " + "recur-root-address"rp group-address rd recur-root-address recur-rd"; description "List of FEC to label bindings."; leafroot-addressrp { typeinet:ipv4-address;inet:ip-address; description"Root"RP address."; } leaflsp-idgroup-address { typeuint32;inet:ip-address-no-zone; description"ID to identify the LSP.";"Group address."; } leaf rd { type route-distinguisher; description "Route Distinguisher."; reference "RFC7246: Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context."; } leaf recur-root-address { type inet:ip-address; description "Recursive root address."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } leaf recur-rd { type route-distinguisher; description "Route Distinguisher in the VPN-Recursive Opaque Value."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } usesmldp-binding-label-state-attributes;mldp-ext-binding-label-state-attributes; } // fec-label } //opaque-type-lspidopaque-type-bidir } // IPv6 bindings state augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "ipv6/state/roots/root/bindings" { description "Augmentation for MLDP IPv6 bindings."; container opaque-type-transit { config false; description "The type of opaque value element is thegeneric LSP identifier";transit IPv6 source."; reference "RFC6826: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths."; list fec-label { key"root-address source-address"source-address group-address " + "rd recur-root-address recur-rd"; description "List of FEC to label bindings."; leafroot-address { type inet:ipv4-address; description "Root address."; } leafsource-address { type inet:ip-address; description "Source address."; } leaf group-address { type inet:ip-address-no-zone; description "Group address."; } leaf rd { type route-distinguisher; description "Route Distinguisher."; reference "RFC7246: Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context."; } leaf recur-root-address { type inet:ip-address; description "Recursive root address."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } leaf recur-rd { type route-distinguisher; description "Route Distinguisher in the VPN-Recursive Opaque Value."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } usesmldp-binding-label-state-attributes;mldp-ext-binding-label-state-attributes; } // fec-label } // opaque-type-transit container opaque-type-bidir { config false; description "The type of opaque value element is the generic LSP identifier"; reference "RFC6826: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths."; list fec-label { key"root-address rp"rp group-address" + "rdrd recur-root-address recur-rd"; description "List of FEC to label bindings."; leafroot-address { type inet:ipv4-address; description "Root address."; } leafrp { type inet:ip-address; description "RP address."; } leaf group-address { type inet:ip-address-no-zone; description "Group address."; } leaf rd { type route-distinguisher; description "Route Distinguisher."; reference "RFC7246: Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context."; } leaf recur-root-address { type inet:ip-address; description "Recursive root address."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } leaf recur-rd { type route-distinguisher; description "Route Distinguisher in the VPN-Recursive Opaque Value."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } usesmldp-binding-label-state-attributes;mldp-ext-binding-label-state-attributes; } // fec-label } // opaque-type-bidir } // IPv4 bindings} // ipv4 container ipv6 { when "../../afi = 'ipv6'" { description "Only for IPv6."; } description "IPv6opaque-type-lspid stateinformation."; container rootsaugment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "mldp:ipv4/mldp:state/mldp:roots/mldp:root/mldp:bindings/" + "mldp:opaque-type-lspid/mldp:fec-label" { description"IPv6 multicast"Augmentation for MLDP IPv4 bindings with opaque type LSProots.";ID."; listrootrecursive-fec { key"root-address";"recur-root-address recur-rd"; description "List ofroots for configured multicast LSPs.";recursive opaque values."; leafroot-addressrecur-root-address { typeinet:ipv6-address;inet:ip-address; description"Root"Recursive root address.";} leaf is-self { type boolean; description "This isreference "RFC6512: Using Multipoint LDP When theroot."; } list reachability { key "address interface"; description "A next hop for reachability to root, as a RIB view."; leaf address { type inet:ipv6-address; description "The next hop address to reach root."; } leaf interface { type ldp:mpls-interface-ref; description "Interface connectingBackbone Has No Route tonext-hop.";the Root"; } leafpeerrecur-rd { typeleafref { path "../../../../../../../../../ldp:peers/" + "ldp:peer/ldp:lsr-id"; }route-distinguisher; description"LDP peer from which this next hop can be reached."; }"Route Distinguisher in the VPN-Recursive Opaque Value."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } uses mldp-ext-binding-label-state-attributes; } //list rootfec-label } //roots containerIPv6 bindings{ description "mLDP FEC to label bindings."; containeropaque-type-lspid state augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families/" + "ipv6/state/roots/root/bindings/opaque-type-lspid/" + "fec-label" { description"The type of"Augmentation for MLDP IPv6 bindings with opaquevalue element is the generictype LSPidentifier"; reference "RFC6388: Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.";ID."; listfec-labelrecursive-fec { key"root-address lsp-id " +"recur-root-address recur-rd"; config false; description "List ofFEC to label bindings."; leaf root-address { type inet:ipv6-address; description "Root address."; } leaf lsp-id { type uint32; description "ID to identify the LSP."; }recursive opaque values."; leaf recur-root-address { type inet:ip-address; description "Recursive root address."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } leaf recur-rd { type route-distinguisher; description "Route Distinguisher in the VPN-Recursive Opaque Value."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } usesmldp-binding-label-state-attributes;mldp-ext-binding-label-state-attributes; } // fec-label } /* * Per AF augmentation */ //opaque-type-lspidIPv6 augmentation augment "/rt:routing/rt:control-plane-protocols/" + "ldp:mpls-ldp/ldp:global/mldp:mldp/mldp:address-families" { description "Augmentation for MLDP IPv6 address family."; containeropaque-type-transitipv6 { description"The type of opaque value element is the generic"IPv6 information."; container state { config false; description "Operational state data."; container roots { description "IPv6 multicast LSPidentifier"; reference "RFC6826: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.";roots."; listfec-labelroot { key"root-address source-address group-address " + "rd recur-root-address recur-rd";"root-address"; description "List ofFEC to label bindings.";roots for configured multicast LSPs."; leaf root-address { type inet:ipv6-address; description "Root address."; } leafsource-address { type inet:ip-address; description "Source address."; } leaf group-addressis-self { typeinet:ip-address-no-zone;boolean; description"Group address.";"This is the root."; }leaf rdlist reachability {type route-distinguisher;key "address interface"; description"Route Distinguisher."; reference "RFC7246: Multipoint Label Distribution Protocol In-Band Signaling in"A next hop for reachability to root, as aVirtual Routing and Forwarding (VRF) Table Context."; }RIB view."; leafrecur-root-addressaddress { typeinet:ip-address;inet:ipv6-address; description"Recursive root address."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route"The next hop address tothe Root";reach root."; } leafrecur-rdinterface { typeroute-distinguisher;ldp:mpls-interface-ref; description"Route Distinguisher in the VPN-Recursive Opaque Value."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route"Interface connecting tothe Root";next-hop."; }uses mldp-binding-label-state-attributes;leaf peer { type leafref { path "../../../../../../../../../ldp:peers/" + "ldp:peer/ldp:lsr-id"; } description "LDP peer from which this next hop can be reached."; }// fec-label}// opaque-type-transitcontaineropaque-type-bidirbindings { description "mLDP FEC to label bindings."; container opaque-type-lspid { description "The type of opaque value element is the generic LSP identifier"; reference"RFC6826: Multipoint LDP In-Band Signaling"RFC6388: Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths."; list fec-label { key"root-address rp group-address " + "rd recur-root-address recur-rd";"lsp-id"; description "List of FEC to label bindings."; leafroot-address { type inet:ipv6-address; description "Root address."; } leaf rp { type inet:ip-address; description "RP address."; } leaf group-address { type inet:ip-address-no-zone; description "Group address."; } leaf rd { type route-distinguisher; description "Route Distinguisher."; reference "RFC7246: Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context."; } leaf recur-root-address { type inet:ip-address; description "Recursive root address."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root"; } leaf recur-rdlsp-id { typeroute-distinguisher;uint32; description"Route Distinguisher in the VPN-Recursive Opaque Value."; reference "RFC6512: Using Multipoint LDP When the Backbone Has No Route"ID to identify theRoot";LSP."; } usesmldp-binding-label-state-attributes;mldp-ext-binding-label-state-attributes; } // fec-label } //opaque-type-bidiropaque-type-lspid } // bindings } //ipv6list root } // roots } // state container configured-leaf-lsps { description "Configured multicast LSPs."; container p2mp { description "Configured point-to-multipoint LSPs."; usesmldp-configured-lsp-roots;mldp-ipv6-configured-lsp-roots; } container mp2mp { description "Configured multipoint-to-multipoint LSPs."; usesmldp-configured-lsp-roots;mldp-ipv6-configured-lsp-roots; } } // configured-leaf-lsps } //list address-family } // mldpipv6 } /* * Global augmentation */ /* * Notifications */notification mpls-mldp-fec-eventaugment "/mldp:mpls-mldp-fec-event/mldp:lsp-key-type" { description"Notification event for a change of FEC status.";""; case source-group-based { leafevent-typesource-address { typeldp:oper-status-event-type;inet:ip-address; description"Event type.";"LSP source address."; }uses mldp-fec-event;leaf group-address { type inet:ip-address; description "Multicast group address."; } } // case source-group } } <CODE ENDS> Figure1015 10. Security Considerations This mLDP model shares the same security considerations as captured in LDP Yang model[I-D.ietf-mpls-ldp-mldp-yang].[I-D.ietf-mpls-ldp-yang]. 11. IANA Considerations This document does not extend mLDP protocol specifiction and hence there are no IANA considerations. Note to the RFC Editor: Please remove IANA section before the publication. 12. Acknowledgments The authors would like to acknowledge Ladislav Lhotka for his useful comments as the YANG Doctor. 13. References 13.1. Normative References[I-D.ietf-mpls-ldp-mldp-yang][I-D.ietf-mpls-ldp-yang] Raza, K., Asati, R., Liu, X., Esale, S., Chen, X., and H. Shah, "YANG Data Model for MPLSLDP and mLDP", draft-ietf- mpls-ldp-mldp-yang-00LDP", draft-ietf-mpls-ldp- yang-00 (work in progress),AugustNovember 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <http://www.rfc-editor.org/info/rfc5561>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>. [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, <http://www.rfc-editor.org/info/rfc6241>. [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, <http://www.rfc-editor.org/info/rfc6388>. [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, November 2011, <http://www.rfc-editor.org/info/rfc6389>. [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, <http://www.rfc-editor.org/info/rfc6512>. [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <http://www.rfc-editor.org/info/rfc6536>. [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, <http://www.rfc-editor.org/info/rfc6826>. [RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP Multipoint Extensions on Targeted LDP Sessions", RFC 7060, DOI 10.17487/RFC7060, November 2013, <http://www.rfc-editor.org/info/rfc7060>. [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, <http://www.rfc-editor.org/info/rfc7140>. [RFC7246] Wijnands, IJ., Ed., Hitchen, P., Leymann, N., Henderickx, W., Gulko, A., and J. Tantsura, "Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context", RFC 7246, DOI 10.17487/RFC7246, June 2014, <http://www.rfc-editor.org/info/rfc7246>. [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, <http://www.rfc-editor.org/info/rfc7438>. [RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and Q. Zhao, "Multipoint LDP (mLDP) Node Protection", RFC 7715, DOI 10.17487/RFC7715, January 2016, <http://www.rfc-editor.org/info/rfc7715>. 13.2. Informative References [I-D.ietf-rtgwg-policy-model] Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, "Routing Policy Configuration Model for Service Provider Networks", draft-ietf-rtgwg-policy-model-01 (work in progress), April 2016. [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. [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. Appendix A. Additional ContributorsDanial Johari Cisco Systems Inc. Email: dajohari@cisco.comMatthew BocciAlcatel-Lucent matthew.bocci@alcatel-lucent.comNokia matthew.bocci@nokia.com Authors' Addresses Kamran Raza Cisco Systems, Inc. Email: skraza@cisco.com Rajiv Asati Cisco Systems, Inc. Email: rajiva@cisco.com Sowmya Krishnaswamy Cisco Systems, Inc. Email: sowkrish@cisco.com Xufeng LiuKuatro TechnologiesJabil Email:xliu@kuatrotech.comxufeng_liu@jabil.com Jeff Tantsura Email:jefftant@gmail.comjefftant.ietf@gmail.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