YANG Data Model for MPLS LDP and mLDP
draft-raza-mpls-ldp-mldp-yang-04

MPLS Working Group                                               K. Raza
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                  X. Liu
Expires: January 7, 2016                                        Ericsson
                                                                S. Esale
                                                        Juniper Networks
                                                                 X. Chen
                                                     Huawei Technologies
                                                                 H. Shah
                                                       Ciena Corporation
                                                               R. Rahman
                                                                R. Asati
                                                                N. Kumar
                                                     Cisco Systems, Inc.
                                                             J. Tantsura
                                                                Ericsson
                                                            L. Andersson
                                                     Huawei Technologies
                                                                M. Bocci
                                                          Alcatel-Lucent
                                                               V. Beeram
                                                        Juniper Networks
                                                            S. Litkowski
                                                                  Orange

                                                            July 6, 2015


                 YANG Data Model for MPLS LDP and mLDP
                    draft-raza-mpls-ldp-mldp-yang-01

Abstract

   This document describes a YANG data model for Multi-Protocol Label
   Switching (MPLS) Label Distribution Protocol (LDP) and Multipoint LDP
   (mLDP).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Raza, et al.             Expires January 7, 2016                [Page 1]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  LDP YANG Model  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Configuration . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Configuration Hierarchy . . . . . . . . . . . . . . .   8
       3.2.2.  All-VRFs Configuration  . . . . . . . . . . . . . . .  11
     3.3.  Operational State . . . . . . . . . . . . . . . . . . . .  11
     3.4.  Notifications . . . . . . . . . . . . . . . . . . . . . .  11
     3.5.  Actions . . . . . . . . . . . . . . . . . . . . . . . . .  12
   4.  mLDP YANG Model . . . . . . . . . . . . . . . . . . . . . . .  13
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  Configuration . . . . . . . . . . . . . . . . . . . . . .  14
       4.2.1.  Configuration Hierarchy . . . . . . . . . . . . . . .  14
       4.2.2.  mldp container  . . . . . . . . . . . . . . . . . . .  16
       4.2.3.  Leveraging LDP containers . . . . . . . . . . . . . .  16
       4.2.4.  YANG tree . . . . . . . . . . . . . . . . . . . . . .  17
     4.3.  Operational State . . . . . . . . . . . . . . . . . . . .  19
     4.4.  Notifications . . . . . . . . . . . . . . . . . . . . . .  19
     4.5.  Actions . . . . . . . . . . . . . . . . . . . . . . . . .  20
   5.  YANG Specification  . . . . . . . . . . . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  54
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  54
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  54
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  55
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  55



Raza, et al.             Expires January 7, 2016                [Page 2]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


     9.2.  Informative References  . . . . . . . . . . . . . . . . .  56
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  57

1.  Introduction

   The Network Configuration Protocol (NETCONF) [RFC6241] is a network
   management protocol that defines mechanisms to manage network
   devices.  YANG [RFC6020] is a modular language that represents data
   structures in an XML tree format, and is used as a data modelling
   language for the NETCONF.

   This document introduces a YANG data model for MPLS Label
   Distribution Protocol (LDP) [RFC5036] and Multipoint LDP (mLDP)
   [RFC6388].  For LDP, it also covers LDP IPv6 [RFC7552] and LDP
   capabilities [RFC5561].

   The data model is defined for following constructs that are used for
   managing the protocol:

   o  Configuration

   o  Operational State

   o  Executables (Actions)

   o  Notifications

   Given mLDP tight coupling with LDP, mLDP model is defined under LDP
   tree.  The document is organized to first define the data model for
   the configuration, operational state, actions and notifications of
   LDP, followed by mLDP model in the same order.

2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In this document, the word "IP" is used to refer to both IPv4 and
   IPv6, unless otherwise explicitly stated.  For example, "IP address
   family" means and be read as "IPv4 and/or IPv6 address family"

3.  LDP YANG Model








Raza, et al.             Expires January 7, 2016                [Page 3]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


3.1.  Overview

   The LDP/mLDP Yang model is defined under "ietf-mpls-ldp" module and
   augments "routing-protocol" list in ietf-routing module
   [I-D.ietf-netmod-routing-cfg] with LDP and mLDP specific parameters.
   [Ed note: This model will be aligned with MPLS as and when a base
   tree for MPLS is defined and available].

   There are four containers in LDP module as follows:

   o  Read-Write parameters (for configuration)

   o  Read-only parameters (for operational state)

   o  Notifications (for events)

   o  RPCs (for executing commands to perform some action)

   Before going into data model details, it is important to take note of
   the following points:

   o  This module aims to address only the core LDP/mLDP parameters as
      per RFC specification, as well as some widely used and deployed
      non-RFC features.  Any vendor specific feature should be defined
      in a vendor-specific augmentation of this model.

   o  Multi-topology LDP [RFC7307] and Multi-topology mLDP
      [I-D.iwijnand-mpls-mldp-multi-topology] are beyond the scope of
      this document.

   o  This module does not cover any applications running on top of LDP
      and mLDP, nor does it cover any OAM procedures for LDP and mLDP.

   o  This model is a VRF-centric model and hence falls under a routing-
      instance.

   o  This model assumes platform-wide label space (i.e. label space Id
      of zero).

   o  A "routing-instance" refers to a VRF instance within the scope of
      this model.

   o  This model supports two address-families, namely "ipv4" and
      "ipv6".

   o  The label and neighbor policies and filters are typically defined
      using a prefix-list.  The prefix-list is referenced from routing-
      policy model as defined in [I-D.shaikh-rtgwg-policy-model].



Raza, et al.             Expires January 7, 2016                [Page 4]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   o  The use of grouping (templates) for bundling and grouping the
      configuration items is not employed in current model, and is a
      subject for consideration in future.

   A graphical representation of LDP YANG data model is presented in
   Figure 2, Figure 4, Figure 5, and Figure 6.  Whereas, the actual
   model definition in YANG is captured in Section 5.

3.2.  Configuration

   This specification defines the configuration parameters for base LDP
   as defined in [RFC5036] and LDP IPv6 [RFC7552].  Moreover, it
   incorporates provisions to enable LDP Capabilities [RFC5561], and
   defines some of the most significant and commonly used capabilities
   such as Typed Wildcard FEC [RFC5918], End-of-LIB [RFC5919], and LDP
   Upstream Label Assignment [RFC6389].

   This specification supports VRF-centric configuration.  For
   implementations that support protocol-centric configuration, with
   provision for inheritance and items that apply to all vrfs, we
   recommend an augmentation of this model such that any protocol-
   centric or all-vrf configuration is defined under their designated
   containers within the standard routing-instance (please see section
   Section 3.2.2)


   module: ietf-mpls-ldp
      +-- routing
       +-- routing-instance [name]
        +-- routing-protocols
          +-- routing-protocol [name]
             +-- mpls-ldp
                .
                .

                                 Figure 1

   Given the configuration hierarchy, the model allows inheritance such
   that an item in a child tree is able to derive value from a similar
   or related item in one of the parent.  For instance, hello holdtime
   can be configured per-VRF or per-VRF-interface, thus allowing
   inheritance as well flexibility to override with a different value on
   any child level.

   Following is a simplified graphical representation of the data model
   for LDP configuration.





Raza, et al.             Expires January 7, 2016                [Page 5]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


module: ietf-mpls-ldp
augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol:
   +--rw mpls-ldp
      +--rw lsr-id?                      yang:dotted-quad
      +--rw capability
      |  +--rw end-of-lib {capability-end-of-lib}?
      |  |  +--rw enable?   boolean
      |  +--rw typed-wildcard-fec {capability-typed-wildcard-fec}?
      |  |  +--rw enable?   boolean
      |  +--rw upstream-label-assignment {capability-upstream-label-assignment}?
      |     +--rw enable?   boolean
      +--rw graceful-restart
      |  +--rw enable?                boolean
      |  +--rw helper-enable?         boolean {graceful-restart-helper-mode}?
      |  +--rw reconnect-time?        uint16
      |  +--rw recovery-time?         uint16
      |  +--rw forwarding-holdtime?   uint16
      +--rw igp-synchronization-delay?   uint16
      +--rw nonstop-routing?             boolean
      +--rw address-family* [af]
      |  +--rw af              address-family-type
      |  +--rw enable?         boolean
      |  +--rw label-policy
      |  |  +--rw independent-mode
      |  |  |  +--rw assign {policy-label-assignment-config}?
      |  |  |  |  +--rw (prefix-option)?
      |  |  |  |     +--:(prefix-list)
      |  |  |  |     |  +--rw prefix-list?        prefix-list-ref
      |  |  |  |     +--:(host-routes-only)
      |  |  |  |        +--rw host-routes-only?   boolean
      |  |  |  +--rw advertise
      |  |  |  |  +--rw explicit-null!
      |  |  |  |  |  +--rw prefix-list?   prefix-list-ref
      |  |  |  |  +--rw prefix-list?     prefix-list-ref
      |  |  |  +--rw accept
      |  |  |     +--rw prefix-list?   prefix-list-ref
      |  |  +--rw ordered-mode {policy-ordered-label-config}?
      |  |     +--rw egress-lsr
      |  |     |  +--rw prefix-list?   prefix-list-ref
      |  |     +--rw advertise
      |  |     |  +--rw prefix-list?   prefix-list-ref
      |  |     +--rw accept
      |  |        +--rw prefix-list?   prefix-list-ref
      |  +--rw ipv4
      |  |  +--rw transport-address?   inet:ipv4-address
      |  +--rw ipv6
      |     +--rw transport-address?   inet:ipv6-address
      +--rw discovery



Raza, et al.             Expires January 7, 2016                [Page 6]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


      |  +--rw interfaces
      |  |  +--rw hello-holdtime?   uint16
      |  |  +--rw hello-interval?   uint16
      |  |  +--rw interface* [interface]
      |  |     +--rw interface                    if:interface-ref
      |  |     +--rw hello-holdtime?              uint16
      |  |     +--rw hello-interval?              uint16
      |  |     +--rw igp-synchronization-delay?   uint16 {per-interface-timer-config}?
      |  |     +--rw address-family* [af]
      |  |        +--rw af        address-family-type
      |  |        +--rw enable?   boolean
      |  |        +--rw ipv4
      |  |        |  +--rw transport-address?   union
      |  |        +--rw ipv6
      |  |           +--rw transport-address?   union
      |  +--rw targeted
      |     +--rw hello-holdtime?   uint16
      |     +--rw hello-interval?   uint16
      |     +--rw hello-accept {policy-extended-discovery-config}?
      |     |  +--rw enable?      boolean
      |     |  +--rw peer-list?   peer-list-ref
      |     +--rw address-family
      |        +--rw ipv4
      |        |  +--rw target* [address]
      |        |     +--rw address    inet:ipv4-address
      |        |     +--rw enable?    boolean
      |        +--rw ipv6
      |           +--rw target* [address]
      |              +--rw address    inet:ipv6-address
      |              +--rw enable?    boolean
      +--rw forwarding-nexthop {forwarding-nexthop-config}?
      |  +--rw interfaces
      |     +--rw interface* [interface]
      |        +--rw interface         if:interface-ref
      |        +--rw address-family* [af]
      |           +--rw af              address-family-type
      |           +--rw ldp-disable?    boolean
      +--rw neighbors
         +--rw md5-password?                   string
         +--rw session-ka-holdtime?            uint16
         +--rw session-ka-interval?            uint16
         +--rw session-downstream-on-demand {session-downstream-on-demand-config}?
         |  +--rw enable?      boolean
         |  +--rw peer-list?   peer-list-ref
         +--rw session-protection {session-protection}?
         |  +--rw enable?      boolean
         |  +--rw duration?    union
         |  +--rw peer-list?   peer-list-ref



Raza, et al.             Expires January 7, 2016                [Page 7]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


         +--rw neighbor* [lsr-id]
            +--rw lsr-id                 union
            +--rw admin-down?            boolean
            +--rw capability
            |  +--rw ...
            +--rw md5-password?          string
            +--rw graceful-restart
            |  +--rw enable?           boolean
            |  +--rw reconnect-time?   uint16
            |  +--rw recovery-time?    uint16
            +--rw session-ka-holdtime?   uint16
            +--rw session-ka-interval?   uint16
            +--rw session-protection {session-protection}?
            |  +--rw enable?     boolean
            |  +--rw duration?   union
            +--rw address-family
               +--rw ipv4
               |  +--rw label-policy
               |     +--rw advertise
               |     |  +--rw prefix-list?   prefix-list-ref
               |     +--rw accept
               |        +--rw prefix-list?   prefix-list-ref
               +--rw ipv6
                  +--rw label-policy
                     +--rw advertise
                     |  +--rw prefix-list?   prefix-list-ref
                     +--rw accept
                        +--rw prefix-list?   prefix-list-ref


                                 Figure 2

3.2.1.  Configuration Hierarchy

   The LDP configuration container is logically divided into following
   high level config areas:















Raza, et al.             Expires January 7, 2016                [Page 8]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


      Per-VRF parameters
          o Global parameters
          o Per-address-family parameters
          o LDP Capabilities parameters
          o Hello Discovery parameters
              - interfaces
                 - Per-interface:
                    Global
                    Per-address-family
              - targeted
                 - Per-target
         o Neighbor parameters
              - Global
              - Per-neighbor
                 Per-address-family
                 Capabilities parameters
         o Forwarding parameters

                                 Figure 3

   Following subsections briefly explain these configuration areas.

3.2.1.1.  Per-VRF parameters

   LDP module resides under a routing-instance and the scope of any LDP
   configuration defined under this tree is per routing-instance (per-
   VRF).  This configuration is further divided into sub categories as
   follows.

3.2.1.1.1.  Per-VRF global parameters

   There are configuration items that are available directly under a VRF
   instance and do not fall under any other sub tree.  Example of such a
   parameter is LDP lsr-id which is typically configured per VRF.

3.2.1.1.2.  Per-VRF Per-Address-Family parameters

   Any LDP configuration parameter related to IP address family (AF)
   whose scope is VRF wide is configured under this tree.  The examples
   of per-AF parameters include enabling the AF, prefix-list based label
   policies, and LDP transport address.

3.2.1.1.3.  Per-VRF Capabilities parameters

   This container holds the LDP capabilities that are to be enabled for
   certain features.  By default, an LDP capability is disabled unless
   explicitly enabled.  These capabilities are typically used to
   negotiate with LDP peer(s) the support/non-support related to a



Raza, et al.             Expires January 7, 2016                [Page 9]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   feature and its parameters.  The scope of a capability enabled under
   this container applies to all LDP neighbors in the given VRF
   instance.  There is also a per-neighbor level capability container
   that is provided to override a capability that is enabled/specified
   at VRF level.

3.2.1.1.4.  Per-VRF Hello Discovery parameters

   This container is used to hold LDP configuration related to Hello and
   discovery process for both basic (link) and extended (targeted)
   discovery.

   The "interfaces" is a container to configure parameters related to
   VRF interfaces.  There are parameters that apply to all interfaces
   (such as hello timers), as well as parameters that can be configured
   per-interface.  Hence, an interface list is defined under
   "interfaces" container.  The model defines parameters to configure
   per-interface non AF related items, as well as per-interface per-AF
   items.  The example of former is interface hello timers, and example
   of latter is enabling hellos for a given AF under an interface.

   The "targeted" container under a VRF instance allows to configure LDP
   targeted discovery related parameters.  Within this container, the
   "target" list provides a mean to configure multiple target addresses
   to perform extended discovery to a specific destination target, as
   well as to fine tune parameters per-target.

3.2.1.1.5.  Per-VRF Neighbor parameters

   This container is used to hold LDP configuration related to LDP
   neighbors (i.e. peers) under a VRF instance.  This container allows
   to configure parameters that either apply on VRF's all neighbors or a
   subset (peer-list) of VRF neighbors.  The example of such parameters
   include authentication password, session KA timers etc.  Moroever,
   the model also allows per-neighbor parameter tuning by specifying a
   "neighbor" list under the "neighbors" container.  A neighbor is
   uniquely identified using its LSR Id and hence lsr-id is the key for
   neighbor list

   Like per-interface parameters, some per-neighbor parameters are AF-
   agnostic (i.e. either non AF related or apply to both IP address
   families), and some that belong to an AF.  The example of former is
   per-neighbor password configuration, whereas the example of latter is
   prefix-list based label policies (inbound and outbound) that apply to
   a given neighbor.






Raza, et al.             Expires January 7, 2016               [Page 10]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


3.2.1.1.6.  Per-VRF Forwarding parameters

   This container is used to hold configuration used to control LDP
   forwarding behavior under a VRF instance.  One example of a
   configuration under this container is when a user wishes to enable
   neighbor discovery on an interface but wishes to disable use of the
   same interface as forwarding nexthop.  This example configuration
   makes sense only when there are more than one LDP enabled interfaces
   towards the neighbor.

3.2.2.  All-VRFs Configuration

   TODO.

3.3.  Operational State

   Operational state of LDP can be queried and obtained from this read-
   only container "mpls-ldp" which is augmented from "routing-state" of
   a routing-protocol (/rt:routing-state/rt:routing-instance/
   rt:routing-protocols/rt:routing-protocol).

   Following is a simplified graphical representation of the data model
   for LDP operational state.


   module: ietf-mpls-ldp
   augment /rt:routing-state/rt:routing-instance/rt:routing-protocols/
            rt:routing-protocol:
      +--ro mpls-ldp
         +-- ...
         +-- ...

   [Ed note: TODO (later revision)]

                                 Figure 4

3.4.  Notifications

   This model defines a list of notifications to inform client of
   important events detected during the protocol operation.  These
   events include events related to changes in the operational state of
   an LDP neighbor, hello adjacency, and FEC etc.  It is to be noted
   that an LDP FEC is treated as operational (up) as long as it has
   atleast 1 NHLFE with outgoing label.

   Following is a simplified graphical representation of the data model
   for LDP notifications.




Raza, et al.             Expires January 7, 2016               [Page 11]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   module: ietf-mpls-ldp
   notifications:
      +---n mpls-ldp-neighbor-event
      |  +--ro event-type?             oper-status-event-type
      |  +--ro routing-instance-ref?   rt:routing-instance-ref
      |  +--ro ldp-protocol-name?      leafref
      |  +--ro neighbor-ref?           leafref
      +---n mpls-ldp-adjacency-event
      |  +--ro event-type?             oper-status-event-type
      |  +--ro routing-instance-ref?   rt:routing-instance-ref
      |  +--ro ldp-protocol-name?      leafref
      |  +--ro (adjacency-type)?
      |     +--:(targeted)
      |     |  +--ro targeted
      |     |     +--ro target-address?   inet:ip-address
      |     +--:(link)
      |        +--ro link
      |           +--ro next-hop-interface?   if:interface-ref
      |           +--ro next-hop-address?     inet:ip-address
      +---n mpls-ldp-fec-event
         +--ro event-type?             oper-status-event-type
         +--ro routing-instance-ref?   rt:routing-instance-ref
         +--ro ldp-protocol-name?      leafref
         +--ro prefix?                 inet:ip-prefix


                                 Figure 5

3.5.  Actions

   This model defines a list of rpcs that allow performing an action or
   executing a command on the protocol.  For example, it allows to clear
   (reset) LDP neighbors, hello-adjacencies, and statistics.  The model
   makes an effort to provide different level of control so that a user
   is able to either clear all, or clear all of a given type, or clear a
   specific entity.

   Following is a simplified graphical representation of the data model
   for LDP actions.












Raza, et al.             Expires January 7, 2016               [Page 12]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   module: ietf-mpls-ldp
      +---x mpls-ldp-clear-neighbor
      |  +--ro input
      |     +--ro routing-instance-ref?   rt:routing-instance-ref
      |     +--ro ldp-protocol-name?      leafref
      |     +--ro lsr-id?                 union
      +---x mpls-ldp-clear-adjacency
      |  +--ro input
      |     +--ro routing-instance-ref?   rt:routing-instance-ref
      |     +--ro ldp-protocol-name?      leafref
      |     +--ro adjacency
      |        +--ro (adjacency-type)?
      |           +--:(targeted)
      |           |  +--ro targeted!
      |           |     +--ro target-address?   inet:ip-address
      |           +--:(link)
      |              +--ro link!
      |                 +--ro next-hop-interface?   if:interface-ref
      |                 +--ro next-hop-address?     inet:ip-address
      +---x mpls-ldp-clear-neighbor-statistics
         +--ro input
            +--ro routing-instance-ref?   rt:routing-instance-ref
            +--ro ldp-protocol-name?      leafref
            +--ro lsr-id?                 union

                                 Figure 6

4.  mLDP YANG Model

4.1.  Overview

   Due to tight dependency of mLDP on LDP, mLDP model builds on top of
   LDP model defined earlier in the document.  Following are the main
   mLDP areas and documents that are within the scope of this model:

   o  mLDP Base Specifiction [RFC6388]

   o  mLDP Recursive FEC [RFC6512]

   o  Targeted mLDP [RFC7060]

   o  mLDP Fast-Reroute (FRR)

      *  Node Protection [I-D.ietf-mpls-mldp-node-protection]

      *  Multicast-only

   o  Hub-and-Spoke Multipoint LSPs [RFC7140]



Raza, et al.             Expires January 7, 2016               [Page 13]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   o  mLDP Inband Signaling [RFC6826] (future revision)

   o  mLDP Inband Signaling with Wildcards [RFC7438] (future revision)

   o  Configured LSPs (manually privisioned)

   [Ed Note: Some of the topics in the above list are to be addressed/
   added in later revision of this document].

4.2.  Configuration

4.2.1.  Configuration Hierarchy

   In terms of overall configuration layout, following figure highlights
   extensions to LDP configuration model to incorporate mLDP:




































Raza, et al.             Expires January 7, 2016               [Page 14]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


      +-- mpls-ldp
         +-- ...
         +-- ...
         +-- mldp
         |  +-- ...
         |  +-- ...
         |  +-- address-family* [af]
         |     +-- af
         |        +-- ...
         |        +-- ...
         +-- capability
         |  +-- ...
         |  +-- ...
         |  +-- mldp
         |      +-- ...
         |      +-- ...
         +-- discovery
         |  +-- ...
         |  +-- ...
         +-- forwarding-nexthop
         |  +-- interfaces
         |     +-- interface* [interface]
         |        +-- interface
         |        +-- address-family* [af]
         |           +-- af
         |           +-- ...
         |           +-- mldp-disable
         +-- neighbors
            +-- ...
            +-- ...
            +-- neighbor* [lsr-id]
                +-- ...
                +-- ...
                +-- capability
                    +-- ...
                    +-- ...
                    +-- mldp
                        +-- ...
                        +-- ...

                                 Figure 7

   From above hierarchy, we can cateogrize mLDP configuration paramters
   into two types:

   o  Parameters that leverage/extend LDP containers and parameters

   o  Parameters that are mLDP specific



Raza, et al.             Expires January 7, 2016               [Page 15]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   Following subsections first describe mLDP specific configuration
   parameters, followed by those leveraging LDP.

4.2.2.  mldp container

   mldp container resides directly under "mpls-ldp" and holds the
   configuration related to items that are mLDP specific.  The main
   items under this container are:

   o  mLDP enabling: To enable mLDP under a (VRF) routing instance, mldp
      container is enabled under LDP.  Given that mLDP requires LDP
      signalling, it is not sensible to allow disabling LDP control
      plane under a (VRF) routing-instance while requiring mLDP to be
      enabled for the same.  However, if a user wishes only to allow
      signalling for multipoint FECs on an LDP/mLDP enabled VRF
      instance, he/she can use LDP label-policies to disable unicast
      FECs under the VRF.

   o  mLDP per-AF features: mLDP manages its own list of IP address-
      families and the features enabled underneath.  The per-AF mLDP
      configuration items include:

      *  Multicast-only FRR: This enables Multicast-only FRR
         functionality for a given AF under mLDP.  The feature allows
         route-policy to be configured for finer control/applicability
         of the feature.

      *  Recursive FEC: The recursive-fec feature [RFC6512] can be
         enabled per AF with a route-policy.

      *  Configured LSPs: To provision multipoint LSP manually, a
         container is provided per-AF under LDP.  The configuration is
         flexible and allows a user to specify MP LSPs of type p2mp or
         mp2mp with IPv4 or IPv6 root address(es) by using either LSP-Id
         or (S,G).

   Targeted mLDP feature specification [RFC7060] do not require any mLDP
   specific configuration.  It, however, requires LDP upstream-label-
   assignment capability to be enabled.

4.2.3.  Leveraging LDP containers

   mLDP configuration model leverages following configuration areas and
   containers that are already defined for LDP:

   o  Capabilities: A new container "mldp" is defined under Capabilities
      container.  This new container specifies any mLDP specific
      capabilities and their parameters.  Moreover, a new "mldp"



Raza, et al.             Expires January 7, 2016               [Page 16]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


      container is also added under per-neighbor capability container to
      override/control mLDP specific capabilities on a neighbor level.
      In the scope of this document, the most important capabilities
      related to mLDP are p2mp, mp2mp, make-before-break, hub-and-spoke,
      and node-protection.

   o  Discovery and Neighbor: mLDP requires LDP discovery and neighbor
      procedures to form mLDP peering.  A neighbor is treated as mLDP
      neighbor only when either P2MP or MP2MP capabilities have been
      successfully exchanged with the peer.  If a user wish to
      selectively enable or disable mLDP with a mLDP-enabled peer, he/
      she may use per-neighbor mLDP capabilities configuration.  [Ed
      Note: The option to control mLDP enabling/disabling on a neighbor-
      list is being explored for future ].  In most common deployments,
      it is desirable to disable mLDP (capabilities announcements) on a
      targeted-only LDP session, where targeted-only session is the one
      whose discovery sources are targeted only.  In future revision, a
      configuration option for this support will also be provided
      [TODO].

   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.

4.2.4.  YANG tree

   The following figure captures the YANG tree for mLDP configuration.
   The figure has been simplified to display only mLDP items and not LDP
   items to keep the focus.


module: ietf-mpls-ldp
augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol:
   +--rw mpls-ldp
      +--rw mldp {mldp}?
      |  +--rw enable?           boolean
      |  +--rw address-family* [af]
      |     +--rw af                    address-family-type
      |     +--rw multicast-only-frr {mldp-mofrr}?
      |     +--rw recursive-fec
      |     +--rw configured-lsps
      |        +--rw p2mp
      |        |  +--rw roots-ipv4
      |        |  |  +--rw root* [root-addr]



Raza, et al.             Expires January 7, 2016               [Page 17]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


      |        |  |     +--rw root-addr    inet:ipv4-address
      |        |  |     +--rw lsp* [lsp-id source-addr group-addr]
      |        |  |        +--rw lsp-id         uint16
      |        |  |        +--rw source-addr    inet:ipv4-address-no-zone
      |        |  |        +--rw group-addr     inet:ipv4-address-no-zone
      |        |  +--rw roots-ipv6
      |        |     +--rw root* [root-addr]
      |        |        +--rw root-addr    inet:ipv6-address
      |        |        +--rw lsp* [lsp-id source-addr group-addr]
      |        |           +--rw lsp-id         uint16
      |        |           +--rw source-addr    inet:ipv6-address-no-zone
      |        |           +--rw group-addr     inet:ipv6-address-no-zone
      |        +--rw mp2mp
      |           +--rw roots-ipv4
      |           |  +--rw root* [root-addr]
      |           |     +--rw root-addr    inet:ipv4-address
      |           |     +--rw lsp* [lsp-id source-addr group-addr]
      |           |        +--rw lsp-id         uint16
      |           |        +--rw source-addr    inet:ipv4-address-no-zone
      |           |        +--rw group-addr     inet:ipv4-address-no-zone
      |           +--rw roots-ipv6
      |              +--rw root* [root-addr]
      |                 +--rw root-addr    inet:ipv6-address
      |                 +--rw lsp* [lsp-id source-addr group-addr]
      |                    +--rw lsp-id         uint16
      |                    +--rw source-addr    inet:ipv6-address-no-zone
      |                    +--rw group-addr     inet:ipv6-address-no-zone
      +--rw 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
      +--rw forwarding-nexthop {forwarding-nexthop-config}?
      |  +--rw interfaces
      |     +--rw interface* [interface]
      |        +--rw interface         if:interface-ref



Raza, et al.             Expires January 7, 2016               [Page 18]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


      |        +--rw address-family* [af]
      |           +--rw af              address-family-type
      |           +--rw mldp-disable?   boolean {mldp}?
      +--rw neighbors
         +--rw neighbor* [lsr-id]
            +--rw lsr-id                 union
            +--rw 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


                                 Figure 8

4.3.  Operational State

   [Ed note: TODO (later revision)]

4.4.  Notifications

   mLDP notification module consists of notification related to changes
   in the operational state of an mLDP FEC.  Following is a simplified
   graphical representation of the data model for mLDP notifications:















Raza, et al.             Expires January 7, 2016               [Page 19]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   notifications:
      +---n mpls-mldp-fec-event
         +--ro event-type?             oper-status-event-type
         +--ro routing-instance-ref?   rt:routing-instance-ref
         +--ro ldp-protocol-name?      leafref
         +--ro tree-type?              multipoint-type
         +--ro root?                   inet:ip-address
         +--ro (lsp-key-type)?
            +--:(lsp-id-based)
            |  +--ro lsp-id?                 uint16
            +--:(source-group-based)
               +--ro source-addr?            inet:ip-address
               +--ro group-addr?             inet:ip-address

                                 Figure 9

4.5.  Actions

   Currently, no RPCs/actions are defined for mLDP.

5.  YANG Specification

   Following are actual YANG definition for LDP and mLDP constructs
   defined earlier in the document.


   <CODE BEGINS> file "ietf-mpls-ldp@2015-07-02.yang" -->

   module ietf-mpls-ldp {

     namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-ldp";
     // replace with IANA namespace when assigned
     prefix ldp;

     import ietf-inet-types {
       prefix "inet";
     }

     import ietf-yang-types {
       prefix "yang";
     }

     import ietf-interfaces {
       prefix "if";
     }

     import ietf-ip {



Raza, et al.             Expires January 7, 2016               [Page 20]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


       prefix "ip";
     }

     import ietf-routing {
       prefix "rt";
     }

     import routing-policy {
       prefix "rpl";
     }

     organization "TBD";
     contact "TBD";
     description
       "";

     revision 2015-07-02 {
       description
         "Initial revision.";
       reference
         "";
     }

     /*
      * Features
      */
     feature admin-down-config {
       description
         "This feature indicates that the system allows to configure
         administrative down on a VRF instance and a neighbor.";
     }

     feature capability-end-of-lib {
       description
         "This feature indicates that the system allows to configure
         LDP end-of-lib capability.";
     }

     feature capability-mldp-hsmp {
       description
         "This feature indicates that the system allows to configure
         mLDP hub-and-spoke-multipoint capability.";
     }

     feature capability-mldp-node-protection {
       description
         "This feature indicates that the system allows to configure
         mLDP node-protection capability.";



Raza, et al.             Expires January 7, 2016               [Page 21]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


     }

     feature capability-typed-wildcard-fec {
       description
         "This feature indicates that the system allows to configure
         LDP typed-wildcard-fec capability.";
     }

     feature capability-upstream-label-assignment {
       description
         "This feature indicates that the system allows to configure
         LDP upstream label assignment capability.";
     }

     feature forwarding-nexthop-config {
       description
         "This feature indicates that the system allows to configure
         forwarding nexthop on interfaces.";
     }

     feature global-session-authentication {
       description
         "This feature indicates that the system allows to configure
          authentication at global level.";
     }

     feature graceful-restart-helper-mode {
       description
         "This feature indicates that the system supports graceful
         restart helper mode.";
     }

     feature mldp {
       description
         "This feature indicates that the system supports Multicast
         LDP (mLDP).";
     }

     feature mldp-mofrr {
       description
         "This feature indicates that the system supports mLDP
         Multicast only FRR (MoFRR).";
     }

     feature per-interface-timer-config {
       description
         "This feature indicates that the system allows to configure
         interface hello timers at the per-interface level.";



Raza, et al.             Expires January 7, 2016               [Page 22]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


     }

     feature per-neighbor-graceful-restart-config {
       description
         "This feature indicates that the system allows to configure
         graceful restart at the per-neighbor level.";
     }

     feature per-neighbor-session-attributes-config {
       description
         "This feature indicates that the system allows to configure
         session attributes at the per-neighbor level.";
     }

     feature policy-extended-discovery-config {
       description
         "This feature indicates that the system allows to configure
         policies to control the acceptance of extended neighbor
         discovery hello messages.";
     }

     feature policy-label-assignment-config {
       description
         "This feature indicates that the system allows to configure
         policies to assign labels according to certain prefixes.";
     }

     feature policy-ordered-label-config {
       description
         "This feature indicates that the system allows to configure
         ordered label policies.";
     }

     feature session-downstream-on-demand-config {
       description
         "This feature indicates that the system allows to configure
         session downstream-on-demand";
     }

     feature session-protection {
       description
         "This feature indicates that the system supports session
         protection";
     }

     /*
      * Typedefs
      */



Raza, et al.             Expires January 7, 2016               [Page 23]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


     typedef address-family-type {
       type enumeration {
         enum ipv4 {
           description "IPv4";
         }
         enum ipv6 {
           description "IPv6";
         }
       }
       description
         "Address family type.";
     }

     typedef multipoint-type {
       type enumeration {
         enum p2mp {
           description "Point to multipoint.";
         }
         enum mp2mp {
           description "Multipoint to multipoint.";
         }
       }
       description
         "p2mp or mp2mp.";
     }

     typedef peer-list-ref {
       type leafref {
         path "/rpl:routing-policy/rpl:defined-sets/rpl:neighbor-set/"
           +"rpl:neighbor-set-name";
       }
       description
         "A type for a reference to a prefix list.";
     }

     typedef prefix-list-ref {
       type leafref {
         path "/rpl:routing-policy/rpl:defined-sets/rpl:prefix-set/"
           +"rpl:prefix-set-name";
       }
       description
         "A type for a reference to a prefix list.";
     }

     typedef oper-status-event-type {
       type enumeration {
         enum up {
           value 1;



Raza, et al.             Expires January 7, 2016               [Page 24]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


           description
             "Operational status changed to up.";
         }
         enum down {
           value 2;
           description
             "Operational status changed to down.";
         }
       }
       description "Operational status event type for notifications.";
     }

     /*
      * Identities
      */

     identity mpls-ldp {
       base "rt:routing-protocol";
       description "LDP";
     }

     /*
      * Groupings
      */
     grouping ldp-instance-ref {
       description
         "An absolute reference to an LDP instance.";
       leaf routing-instance-ref {
         type rt:routing-instance-ref;
         description
           "Reference to the routing instance.";
       }

       leaf ldp-protocol-name {
         type leafref {
           path "/rt:routing/rt:routing-instance"
             + "[rt:name = current()/../routing-instance-ref]/"
             + "rt:routing-protocols/rt:routing-protocol/rt:name";
         }
         description
           "Reference to an LDP protocal name.";
       }
     } // ldp-instance-ref

     grouping ldp-neighbor-ref {
       description
         "An absolute reference to an LDP neighbor.";
       uses ldp-instance-ref;



Raza, et al.             Expires January 7, 2016               [Page 25]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


       leaf neighbor-ref {
         type leafref {
           path "/rt:routing/rt:routing-instance"
             + "[rt:name = current()/../routing-instance-ref]/"
             + "rt:routing-protocols/rt:routing-protocol"
             + "[rt:name = current()/../ldp-protocol-name]/mpls-ldp/"
             + "neighbors/neighbor/lsr-id";
         }
         description
           "Reference to an LDP neighbor.";
       }
     } // ldp-neighbor-ref

     grouping ldp-adjacency-ref {
       description
         "An absolute reference to an LDP adjacency.";
       uses ldp-instance-ref;
       choice adjacency-type {
         description
           "Interface or targeted adjacency.";
         case targeted {
           container targeted {
             description "Targeted adjacency.";
             leaf target-address {
               type inet:ip-address;
               description
                 "The target address.";
             }
           } // targeted
         }
         case link {
           container link {
             description "Link adjacency.";
             leaf next-hop-interface {
               type if:interface-ref;
               description
                 "Interface connecting to next-hop.";
             }
             leaf next-hop-address {
               type inet:ip-address;
               must "../next-hop-interface" {
                 description
                   "Applicable when interface is specified.";
               }
               description
                 "IP address of next-hop.";
             }
           } // link



Raza, et al.             Expires January 7, 2016               [Page 26]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


         }
       }
     } // ldp-adjacency-ref

     grouping ldp-fec-event {
       description
         "A LDP FEC event.";
       uses ldp-instance-ref;
       leaf prefix {
         type inet:ip-prefix;
         description
           "FEC.";
       }
     } // ldp-fec-event

     grouping mldp-fec-event {
       description
         "A mLDP FEC event.";
       uses ldp-instance-ref;
       leaf tree-type {
         type multipoint-type;
         description
           "p2mp or mp2mp.";
       }
       leaf root {
         type inet:ip-address;
         description
           "Root address.";
       }
       choice lsp-key-type {
         description
           "LSP ID based or source-group based .";
         case lsp-id-based {
           leaf lsp-id {
             type uint16;
             description
               "ID to identify the LSP.";
           }
         }
         case source-group-based {
           leaf source-addr {
             type inet:ip-address;
             description
               "LSP source address.";
           }
           leaf group-addr {
             type inet:ip-address;
             description



Raza, et al.             Expires January 7, 2016               [Page 27]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


               "Multicast group address.";
           }
         } // case source-group-based
       }
     } // mldp-fec-event

     grouping basic-discovery-timers {
       description
         "Basic discovery timer attributes.";
       leaf hello-holdtime {
         type uint16 {
           range 15..3600;
         }
         units seconds;
         default 15;
         description
           "The time interval for which a LDP link Hello adjacency
           is maintained in the absence of link Hello messages from
           the LDP neighbor";
       }
       leaf hello-interval {
         type uint16 {
           range 5..1200;
         }
         units seconds;
         default 5;
         description
           "The interval between consecutive LDP link Hello messages
           used in basic LDP discovery";
       }
     } // basic-discovery-timers

     grouping extended-discovery-timers {
       description
         "Extended discovery timer attributes.";
       leaf hello-holdtime {
         type uint16 {
           range 15..3600;
         }
         units seconds;
         default 45;
         description
           "The time interval for which LDP targeted Hello adjacency
           is maintained in the absence of targeted Hello messages
           from an LDP neighbor.";
       }
       leaf hello-interval {
         type uint16 {



Raza, et al.             Expires January 7, 2016               [Page 28]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


           range 5..3600;
         }
         units seconds;
         default 15;
         description
           "The interval between consecutive LDP targeted Hello
           messages used in extended LDP discovery.";
       }
     } // extended-discovery-timers

     grouping graceful-restart-attributes {
       description
         "Graceful restart configuration attributes.";
       container graceful-restart {
         description
           "Attributes for graceful restart.";
         leaf enable {
           type boolean;
           description
             "Enable or disable graceful restart.";
         }
         leaf helper-enable {
           if-feature graceful-restart-helper-mode;
           type boolean;
           description
             "Enable or disable graceful restart helper mode.";
         }
         leaf reconnect-time {
           type uint16 {
             range 10..1800;
           }
           units seconds;
           description
             "Specifies the time interval that the remote LDP peer
             must wait for the local LDP peer to reconnect after the
             remote peer detects the LDP communication failure.";
         }
         leaf recovery-time {
           type uint16 {
             range 30..3600;
           }
           units seconds;
           description
             "";
         }
         leaf forwarding-holdtime {
           type uint16 {
             range 30..3600;



Raza, et al.             Expires January 7, 2016               [Page 29]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


           }
           units seconds;
           description
             "";
         }
       } // graceful-restart
     } // graceful-restart-attributes

     grouping graceful-restart-attributes-per-neighbor {
       description
         "Per neighbor graceful restart configuration attributes.";
       container graceful-restart {
         description
           "Attributes for graceful restart.";
         leaf enable {
           type boolean;
           description
             "Enable or disable graceful restart.";
         }
         leaf reconnect-time {
           type uint16 {
             range 10..1800;
           }
           units seconds;
           description
             "Specifies the time interval that the remote LDP peer
             must wait for the local LDP peer to reconnect after the
             remote peer detects the LDP communication failure.";
         }
         leaf recovery-time {
           type uint16 {
             range 30..3600;
           }
           units seconds;
           description
             "";
         }
       } // graceful-restart
     } // graceful-restart-attributes-per-neighbor

     grouping neighbor-attributes {
       description "Neighbor configuration attributes.";

       leaf session-ka-holdtime {
         type uint16 {
           range 45..3600;
         }
         units seconds;



Raza, et al.             Expires January 7, 2016               [Page 30]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


         description
           "The time interval after which an inactive LDP session
           terminates and the corresponding TCP session closes.
           Inactivity is defined as not receiving LDP packets from the
           neighbor.";
       }
       leaf session-ka-interval {
         type uint16 {
           range 15..1200;
         }
         units seconds;
         description
           "The interval between successive transmissions of keepalive
           packets. Keepalive packets are only sent in the absence of
           other LDP packets transmitted over the LDP session.";
       }
     } // neighbor-attributes

     grouping session-protection-per-vrf {
       description "Session protection attributes.";
       container session-protection {
         if-feature session-protection;
         description
           "Session protection attributes.";
         leaf enable {
           type boolean;
           description
             "'true' if session protection is enabled.";
         }
         leaf duration {
           type union {
             type uint32;
             type enumeration {
               enum "infinite" {
                 description "The duration is infinite.";
               }
             }
           }
           units seconds;
           description
             "Session protection duration.";
         }
         leaf peer-list {
           type peer-list-ref;
           description
             "The name of a peer ACL.";
         }
       } // session-protection



Raza, et al.             Expires January 7, 2016               [Page 31]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


     } // session-protection-per-vrf

     grouping session-protection-per-neighbor {
       description "Session protection attributes.";
       container session-protection {
         if-feature session-protection;
         description
           "Session protection attributes.";
         leaf enable {
           type boolean;
           description
             "'true' if session protection is enabled.";
         }
         leaf duration {
           type union {
             type uint32;
             type enumeration {
               enum "infinite" {
                 description "The duration is infinite.";
               }
             }
           }
           units seconds;
           description
             "Session protection duration.";
         }
       } // session-protection
     } // session-protection-per-neighbor

     grouping neighbor-authentication {
       description
         "Neighbor authentication attributes.";
       leaf md5-password {
         type string {
           length "1..80";
         }
         description
           "Assigns an encrypted MD5 password to an LDP
           neighbor";
       } // md5-password
     } // neighbor-authentication

     grouping neighbor-attributes-container {
       description "Container of neighbor configuration attributes.";
       container neighbors {
         description
           "Container of neighbor configuration attributes.";
         uses neighbor-authentication {



Raza, et al.             Expires January 7, 2016               [Page 32]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


           if-feature global-session-authentication;
         }
         uses neighbor-attributes;
       }
     } // neighbor-attributes-container

     grouping instance-attributes {
       description "Configuration attributes at instance level.";

       uses graceful-restart-attributes;

       leaf igp-synchronization-delay {
         type uint16 {
           range 3..60;
         }
         units seconds;
         description
           "Sets the interval that the LDP waits before notifying the
           Interior Gateway Protocol (IGP) that label exchange is
           completed so that IGP can start advertising the normal
           metric for the link.";
       }
     } // instance-attributes

     grouping global-attributes {
       description "Configuration attributes at global level.";

       uses instance-attributes;

       leaf nonstop-routing {
         type boolean;
         default false;
         description
           "Enables Nonstop Routing (NSR)";
       }
     } // global-attributes

     grouping policy-attributes {
       description
         "LDP policy attributes.";
       container label-policy {
         description
           "Label policy attributes.";
         container independent-mode {
           description
             "Independent label policy attributes.";
           container assign {
             if-feature policy-label-assignment-config;



Raza, et al.             Expires January 7, 2016               [Page 33]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


             description
               "Label assignment policies";
             choice prefix-option {
               description
                 "Use either prefix-list or host-routes-only.";
               case prefix-list {
                 leaf prefix-list {
                   type prefix-list-ref;
                   description
                     "Assign labels according to certain prefixes.";
                 }
               }
               case host-routes-only {
                 leaf host-routes-only {
                   type boolean;
                   description
                     "'true' to apply host routes only.";
                 }
               }
             } // prefix-option
           }
           container advertise {
             description
               "Label advertising policies.";
             container explicit-null {
               presence "Present to enable explicit null.";
               description
                 "Enables an egress router to advertise an
                 explicit null label (value 0) in place of an
                 implicit null label (value 3) to the
                 penultimate hop router.";
               leaf prefix-list {
                 type prefix-list-ref;
                 description
                   "Prefix list name. Applies the filters in the
                   specified prefix list to label
                   advertisements.
                   If the prefix list is not specified, explicit
                   null label advertisement is enabled for all
                   directly connected prefixes.";
               }
             }
             leaf prefix-list {
               type prefix-list-ref;
               description
                 "Applies the prefix list to outgoing label
                 advertisements.";
             }



Raza, et al.             Expires January 7, 2016               [Page 34]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


           }
           container accept {
             description
               "Label advertisement acceptance policies.";
             leaf prefix-list {
               type prefix-list-ref;
               description
                 "Applies the prefix list to incoming label
                 advertisements.";
             }
           }
         } // independent-mode
         container ordered-mode {
           if-feature policy-ordered-label-config;
           description
             "Ordered label policy attributes.";
           container egress-lsr {
             description
               "Egress LSR label assignment policies";
             leaf prefix-list {
               type prefix-list-ref;
               description
                 "Assign labels according to certain prefixes.";
             }
           }
           container advertise {
             description
               "Label advertising policies.";
             leaf prefix-list {
               type prefix-list-ref;
               description
                 "Applies the prefix list to outgoing label
                 advertisements.";
             }
           }
           container accept {
             description
               "Label advertisement acceptance policies.";
             leaf prefix-list {
               type prefix-list-ref;
               description
                 "Applies the prefix list to incoming label
                 advertisements.";
             }
           }
         } // ordered-mode
       } // label-policy
     } // policy-attributes



Raza, et al.             Expires January 7, 2016               [Page 35]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


     grouping neighbor-af-policy-attributes {
       description
         "LDP policy attributes under neighbor address-family.";
       container label-policy {
         description
           "Label policy attributes.";
         container advertise {
           description
             "Label advertising policies.";
           leaf prefix-list {
             type prefix-list-ref;
               description
                 "Applies the prefix list to outgoing label
                 advertisements.";
           }
         }
         container accept {
           description
             "Label advertisement acceptance policies.";
           leaf prefix-list {
             type prefix-list-ref;
             description
               "Applies the prefix list to incoming label
               advertisements.";
           }
         } // accept
       } // label-policy
     } // neighbor-af-policy-attributes

     grouping extended-discovery-policy-attributes {
       description
         "LDP policy to control the acceptance of extended neighbor
         discovery hello messages.";
       container hello-accept {
         if-feature policy-extended-discovery-config;
         description
           "Extended discovery acceptance policies.";

         leaf enable {
           type boolean;
           description
             "'true' to accept; 'false' to deny.";
         }
         leaf peer-list {
           type peer-list-ref;
           description
             "The name of a peer ACL.";
         }



Raza, et al.             Expires January 7, 2016               [Page 36]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


       } // hello-accept
     } // extended-discovery-policy-attributes

     grouping mldp-capabilities {
       description
         "mLDP capabilities.";
       container p2mp {
         description
           "Configure point-to-multipoint capability.";
         leaf enable {
           type boolean;
           description
             "Enable point-to-multipoint.";
         }
       }
       container mp2mp {
         description
           "Configure multipoint-to-multipoint capability.";
         leaf enable {
           type boolean;
           description
             "Enable multipoint-to-multipoint.";
         }
       }
       container make-before-break {
         description
           "Configure make-before-break capability.";
         leaf enable {
           type boolean;
           description
             "Enable make-before-break.";
         }
         leaf switchover-delay {
           type uint16;
           units seconds;
           description
             "Switchover delay in seconds.";
         }
         leaf timeout {
           type uint16;
           units seconds;
           description
             "Timeout in seconds.";
         }
       }
       container hub-and-spoke {
         if-feature capability-mldp-hsmp;
         description



Raza, et al.             Expires January 7, 2016               [Page 37]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


           "Configure hub-and-spoke-multipoint capability.";
         reference
           "RFC7140: LDP Extensions for Hub and Spoke Multipoint
           Label Switched Path";
         leaf enable {
           type boolean;
           description
             "Enable hub-and-spoke-multipoint.";
         }
       }
       container node-protection {
         if-feature capability-mldp-node-protection;
         description
           "Configure node-protection capability.";
         reference
           "draft-ietf-mpls-mldp-node-protection: mLDP Node
           Protection.";
         leaf plr {
           type boolean;
           description
             "Point of Local Repair capable for MP LSP node
             protection.";
         }
         container merge-point {
           description
             "Merge Point capable for MP LSP node protection.";
           leaf enable {
             type boolean;
             description
               "Enable merge point capability.";
           }
           leaf targeted-session-teardown-delay {
             type uint16;
             units seconds;
             description
               "Targeted session teardown delay.";
           }
         } // merge-point
       }
     } // mldp-capabilities

     grouping  mldp-configured-lsp-roots {
       description
         "mLDP roots containers.";

       container roots-ipv4 {
         when "../../../af = 'ipv4'" {
           description



Raza, et al.             Expires January 7, 2016               [Page 38]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


             "Only for IPv4.";
         }
         description
           "Configured IPv4 multicast LSPs.";
         list root {
           key "root-addr";
           description
             "List of roots for configured multicast LSPs.";

           leaf root-addr {
             type inet:ipv4-address;
             description
               "Root address.";
           }

           list lsp {
             must "(lsp-id = 0 and source-addr != '0.0.0.0' and "
               + "group-addr != '0.0.0.0') or "
               + "(lsp-id != 0 and source-addr = '0.0.0.0' and "
               + "group-addr = '0.0.0.0')" {
               description
                 "A LSP can be identified by either lsp-id or
                 (source-addr, group-addr).";
             }
             key "lsp-id source-addr group-addr";
             description
               "List of LSPs.";
             leaf lsp-id {
               type uint16;
               description "ID to identify the LSP.";
             }
             leaf source-addr {
               type inet:ipv4-address-no-zone;
               description
                 "Source address.";
             }
             leaf group-addr {
               type inet:ipv4-address-no-zone;
               description
                 "Group address.";
             }
           } // list lsp
         } // list root
       } // roots-ipv4

       container roots-ipv6 {
         when "../../../af = 'ipv6'" {
           description



Raza, et al.             Expires January 7, 2016               [Page 39]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


             "Only for IPv6.";
         }
         description
           "Configured IPv6 multicast LSPs.";

         list root {
           key "root-addr";
           description
             "List of roots for configured multicast LSPs.";

           leaf root-addr {
             type inet:ipv6-address;
             description
               "Root address.";
           }

           list lsp {
             must "(lsp-id = 0 and source-addr != '::' and "
               + "group-addr != '::') or "
               + "(lsp-id != 0 and source-addr = '::' and "
               + "group-addr = '::')" {
               description
                 "A LSP can be identified by either lsp-id or
                 (source-addr, group-addr).";
             }
             key "lsp-id source-addr group-addr";
             description
               "List of LSPs.";
             leaf lsp-id {
               type uint16;
               description "ID to identify the LSP.";
             }
             leaf source-addr {
               type inet:ipv6-address-no-zone;
               description
                 "Source address.";
             }
             leaf group-addr {
               type inet:ipv6-address-no-zone;
               description
                 "Group address.";
             }
           } // list lsp
         } // list root
       } // roots-ipv6
     } // mldp-configured-lsp-roots

     /*



Raza, et al.             Expires January 7, 2016               [Page 40]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


      * Configuration data nodes
      */

     augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
       + "rt:routing-protocol" {
       when "rt:type = 'ldp:mpls-ldp'" {
         description
           "This augment is only valid for a protocol instance
           of LDP.";
       }
       description "LDP augmentation.";

       container mpls-ldp {
         description
           "LDP.";

         leaf lsr-id {
           type yang:dotted-quad;
           description "Router ID.";
         }

         container mldp {
           if-feature mldp;
           description
             "mLDP attributes at per instance level. Defining attributes
             here does not enable any MP capabilities. MP capabilities
             need to be explicitly enabled under container capability.";

           leaf enable {
             type boolean;
             description
               "Enable mLDP.";
           }

           list address-family {
             key "af";
             description
               "Per-af params.";
             leaf af {
               type address-family-type;
               description
                 "Address family type value.";
             }

             container multicast-only-frr {
               if-feature mldp-mofrr;
               description
                 "Multicast only FRR (MoFRR) policy.";



Raza, et al.             Expires January 7, 2016               [Page 41]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


               leaf prefix-list {
                 type prefix-list-ref;
                 description
                   "Enables MoFRR for the specified access list.";
               }
             } // multicast-only-frr
             container recursive-fec {
               description
                 "Recursive FEC policy.";
               leaf prefix-list {
                 type prefix-list-ref;
                 description
                   "Enables recursive FEC for the specified access
                   list.";
               }
             } // recursive-for

             container configured-lsps {
               description
                 "Configured multicast LSPs.";

               container p2mp {
                 description
                   "Configured point-to-multipoint LSPs.";
                 uses mldp-configured-lsp-roots;
               }
               container mp2mp {
                 description
                   "Configured multipoint-to-multipoint LSPs.";
                 uses mldp-configured-lsp-roots;
               }
             } // configured-lsps
           } // list address-family
         } // mldp

         container capability {
           description "Configure capability.";
           container end-of-lib {
             if-feature capability-end-of-lib;
             description
               "Configure upstream label assignment capability.";
             leaf enable {
               type boolean;
               description
                 "Enable end-of-lib capability.";
             }
           }
           container typed-wildcard-fec {



Raza, et al.             Expires January 7, 2016               [Page 42]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


             if-feature capability-typed-wildcard-fec;
             description
               "Configure typed-wildcard-fec capability.";
             leaf enable {
               type boolean;
               description
                 "Enable typed-wildcard-fec capability.";
             }
           }
           container upstream-label-assignment {
             if-feature capability-upstream-label-assignment;
             description
               "Configure upstream label assignment capability.";
             leaf enable {
               type boolean;
               description
                 "Enable upstream label assignment.";
             }
           }
           container mldp {
             if-feature mldp;
             description
               "Multipoint capabilities.";
             uses mldp-capabilities;
           }
         } // capability

         uses global-attributes;

         list address-family {
           key "af";
           description
             "Per-vrf per-af params.";
           leaf af {
             type address-family-type;
             description
               "Address family type value.";
           }

           leaf enable {
             type boolean;
             description
               "'true' to enable the address family.";
           }
           uses policy-attributes;

           container ipv4 {
             when "../af = 'ipv4'" {



Raza, et al.             Expires January 7, 2016               [Page 43]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


               description
                 "Only for IPv4.";
             }
             description
               "IPv4 address family.";
             leaf transport-address {
               type inet:ipv4-address;
               description
                 "The transport address advertised in LDP Hello
                 messages.";
             }
           } // ipv4
           container ipv6 {
             when "../af = 'ipv6'" {
               description
                 "Only for IPv6.";
             }
             description
               "IPv6 address family.";
             leaf transport-address {
               type inet:ipv6-address;
               description
                 "The transport address advertised in LDP Hello
                 messages.";
             }
           } // ipv6
         }

         container discovery {
           description
             "Neibgbor discovery configuration.";

           container interfaces {
             description
               "A list of interfaces for basic descovery.";
             uses basic-discovery-timers;

             list interface {
               key "interface";
               description
                 "List of LDP interfaces.";
               leaf interface {
                 type if:interface-ref;
                 description
                   "Interface.";
               }
               uses basic-discovery-timers {
                 if-feature per-interface-timer-config;



Raza, et al.             Expires January 7, 2016               [Page 44]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


               }
               leaf igp-synchronization-delay {
                 if-feature per-interface-timer-config;
                 type uint16 {
                   range 3..60;
                 }
                 units seconds;
                 description
                   "Sets the interval that the LDP waits before
                   notifying the Interior Gateway Protocol (IGP) that
                   label exchange is completed so that IGP can start
                   advertising the normal metric for the link.";
               }

               list address-family {
                 key "af";
                 description
                   "Per-vrf per-af params.";
                 leaf af {
                   type address-family-type;
                   description
                     "Address family type value.";
                 }
                 leaf enable {
                   type boolean;
                   description
                     "Enable the address family on the interface.";
                 }

                 container ipv4 {
                   must "/if:interfaces/if:interface"
                     + "[name = current()/../../interface]/ip:ipv4" {
                     description
                       "Only if IPv4 is enabled on the interface.";
                   }
                   description
                     "IPv4 address family.";
                   leaf transport-address {
                     type union {
                       type enumeration {
                         enum "use-interface-address" {
                           description
                           "Use interface address as the transport
                           address.";
                         }
                       }
                       type inet:ipv4-address;
                     }



Raza, et al.             Expires January 7, 2016               [Page 45]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


                     description
                       "IP address to be advertised as the LDP
                       transport address.";
                   }
                 }
                 container ipv6 {
                   must "/if:interfaces/if:interface"
                     + "[name = current()/../../interface]/ip:ipv6" {
                     description
                       "Only if IPv6 is enabled on the interface.";
                   }
                   description
                     "IPv6 address family.";
                   leaf transport-address {
                     type union {
                       type enumeration {
                         enum "use-interface-address" {
                           description
                           "Use interface address as the transport
                           address.";
                         }
                       }
                       type inet:ipv4-address;
                     }
                     description
                       "IP address to be advertised as the LDP
                       transport address.";
                   }
                 } // ipv6
               } // address-family
             } // list interface
           } // interfaces

           container targeted
           {
             description
               "A list of targeted neighbors for extended discovery.";
             uses extended-discovery-timers;
             uses extended-discovery-policy-attributes;

             container address-family {
               description
                 "Per-vrf per-af params.";
               container ipv4 {
                 description
                   "IPv4 address family.";
                 list target {
                   key "address";



Raza, et al.             Expires January 7, 2016               [Page 46]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


                   description
                     "Targeted discovery params.";

                   leaf address {
                     type inet:ipv4-address;
                     description
                       "Configures a remote LDP neighbor and enables
                       extended LDP discovery of the specified
                       neighbor.";
                   }
                   leaf enable {
                     type boolean;
                     description
                       "Enable the target.";
                   }
                 }
               } // ipv4
               container ipv6 {
                 description
                   "IPv6 address family.";
                 list target {
                   key "address";
                   description
                     "Targeted discovery params.";

                   leaf address {
                     type inet:ipv6-address;
                     description
                       "Configures a remote LDP neighbor and enables
                       extended LDP discovery of the specified
                       neighbor.";
                   }
                   leaf enable {
                     type boolean;
                     description
                       "Enable the target.";
                   }
                 }
               } // ipv6
             } // address-family
           } // targeted
         } // discovery

         container forwarding-nexthop {
           if-feature forwarding-nexthop-config;
           description
             "Configuration for forwarding nexthop.";




Raza, et al.             Expires January 7, 2016               [Page 47]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


           container interfaces {
             description
               "A list of interfaces on which forwarding is disabled.";

             list interface {
               key "interface";
               description
                 "List of LDP interfaces.";
               leaf interface {
                 type if:interface-ref;
                 description
                   "Interface.";
               }
               list address-family {
                 key "af";
                 description
                   "Per-vrf per-af params.";
                 leaf af {
                   type address-family-type;
                   description
                     "Address family type value.";
                 }
                 leaf ldp-disable {
                   type boolean;
                   description
                     "Disable LDP forwarding on the interface.";
                 }
                 leaf mldp-disable {
                   if-feature mldp;
                   type boolean;
                   description
                     "Disable mLDP forwarding on the interface.";
                 }
               } // address-family
             } // list interface
           } // interfaces
         } // forwarding-nexthop

         container neighbors {
           description
             "Neighbors configuration attributes.";

           uses neighbor-authentication {
             if-feature global-session-authentication;
           }
           uses neighbor-attributes;

           container session-downstream-on-demand {



Raza, et al.             Expires January 7, 2016               [Page 48]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


             if-feature session-downstream-on-demand-config;
             description
               "Session downstream-on-demand attributes.";
             leaf enable {
               type boolean;
               description
                 "'true' if session downstream-on-demand is enabled.";
             }
             leaf peer-list {
               type peer-list-ref;
               description
                 "The name of a peer ACL.";
             }
           }

           uses session-protection-per-vrf;

           list neighbor {
             key "lsr-id";
             description
               "List of neighbors.";

             leaf lsr-id {
               type union {
                 type yang:dotted-quad;
                 type uint32;
               }
               description "LSR ID.";
             }

             leaf admin-down {
               type boolean;
               default false;
               description
                 "'true' to disable the neighbor.";
             }

             container capability {
               description
                 "Per neighbor capability";
               container mldp {
                 if-feature mldp;
                 description
                   "mLDP capabilities.";
                 uses mldp-capabilities;
               }
             }




Raza, et al.             Expires January 7, 2016               [Page 49]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


             uses neighbor-authentication;

             uses graceful-restart-attributes-per-neighbor {
               if-feature per-neighbor-graceful-restart-config;
             }

             uses neighbor-attributes {
               if-feature per-neighbor-session-attributes-config;
             }
             uses session-protection-per-neighbor;

             container address-family {
               description
                 "Per-vrf per-af params.";
               container ipv4 {
                 description
                   "IPv4 address family.";
                 uses neighbor-af-policy-attributes;
               }
               container ipv6 {
                 description
                   "IPv6 address family.";
                 uses neighbor-af-policy-attributes;
               } // ipv6
             } // address-family
           } // list neighbor
         } // neighbors
       } // container mpls-ldp
     }

     /*
      * Operational state data nodes
      */

     augment "/rt:routing-state/rt:routing-instance/"
       + "rt:routing-protocols/rt:routing-protocol" {
       when "rt:type = 'ldp:mpls-ldp'"  {
         description
           "This augment is only valid for a protocol instance
           of type 'ldp'.";
       }
       description
         "LDP state.";
       container mpls-ldp {
         description "LDP";

       }
     }



Raza, et al.             Expires January 7, 2016               [Page 50]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


     /*
      * RPCs
      */
     rpc mpls-ldp-clear-neighbor {
       description
         "Clears the session to the neighbor.";
       input {
         uses ldp-instance-ref {
           description
             "VRF instance name. If this is not provided
             then all instances are cleared.";
         }
         leaf lsr-id {
           type union {
             type yang:dotted-quad;
             type uint32;
           }
           description
             "LSR ID of neighbor to be cleared. If this is not provided
             then all neighbors are cleared";
         }
       }
     }

     rpc mpls-ldp-clear-adjacency {
       description
         "Clears the hello adjacency";
       input {
         uses ldp-instance-ref {
           description
             "VRF instance name. If this is not provided
             then all instances are cleared.";
         }
         container adjacency {
           description
             "Link adjacency or targettted adjacency. If this is not
             provided then all hello adjacencies are cleared";
           choice adjacency-type {
             description "Adjacency type.";
             case targeted {
               container targeted {
                 presence "Present to clear targeted adjacencies.";
                 description
                   "Clear targeted adjacencies.";
                 leaf target-address {
                   type inet:ip-address;
                   description
                     "The target address. If this is not provided then



Raza, et al.             Expires January 7, 2016               [Page 51]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


                     all targeted adjacencies are cleared";
                 }
               } // targeted
             }
             case link {
               container link {
                 presence "Present to clear link adjacencies.";
                 description
                   "Clear link adjacencies.";
                 leaf next-hop-interface {
                   type if:interface-ref;
                   description
                     "Interface connecting to next-hop. If this is not
                     provided then all link adjacencies are cleared.";
                 }
                 leaf next-hop-address {
                   type inet:ip-address;
                   must "../next-hop-interface" {
                     description
                       "Applicable when interface is specified.";
                   }
                   description
                     "IP address of next-hop. If this is not provided
                     then adjacencies to all next-hops on the given
                     interface are cleared.";
                 } // next-hop-address
               } // link
             }
           }
         }
       }
     }

     rpc mpls-ldp-clear-neighbor-statistics {
       description
         "Clears protocol statistics (e.g. sent and received
         counters).";
       input {
         uses ldp-instance-ref {
           description
             "VRF instance name. If this is not provided
             then all instances are cleared.";
         }
         leaf lsr-id {
           type union {
             type yang:dotted-quad;
             type uint32;
           }



Raza, et al.             Expires January 7, 2016               [Page 52]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


           description
             "LSR ID of neighbor whose statistic are to be cleared.
             If this is not provided then all neighbors statistics are
             cleared";
         }
       }
     }

     /*
      * Notifications
      */
     notification mpls-ldp-neighbor-event {
       description
         "Notification event for a change of LDP neighbor operational
         status.";
       leaf event-type {
         type oper-status-event-type;
         description "Event type.";
       }
       uses ldp-neighbor-ref;
     }

     notification mpls-ldp-adjacency-event {
       description
         "Notification event for a change of LDP adjacency operational
         status.";
       leaf event-type {
         type oper-status-event-type;
         description "Event type.";
       }
       uses ldp-adjacency-ref;
     }

     notification mpls-ldp-fec-event {
       description
         "Notification event for a change of FEC status.";
       leaf event-type {
         type oper-status-event-type;
         description "Event type.";
       }
       uses ldp-fec-event;
     }

     notification mpls-mldp-fec-event {
       description
         "Notification event for a change of FEC status.";
       leaf event-type {
         type oper-status-event-type;



Raza, et al.             Expires January 7, 2016               [Page 53]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


         description "Event type.";
       }
       uses mldp-fec-event;
     }
   }

   <CODE ENDS>



                                 Figure 10

6.  Security Considerations

   The configuration, state, action and notification data defined in
   this document are designed to be accessed via the NETCONF protocol
   [RFC6241].  The lowest NETCONF layer is the secure transport layer
   and the mandatory-to-implement secure transport is SSH [RFC6242].
   The NETCONF access control model [RFC6536] provides means to restrict
   access for particular NETCONF users to a pre-configured subset of all
   available NETCONF protocol operations and content.

   LDP is a MPLS protocol that is used to establish MPLS transport LSPs.
   So it is critical to ensure security of the protocol to avoid
   disruption of the services that depend on these transport LSPs.

   There are a number of data nodes defined in the LDP and mLDP YANG
   module that are writable/creatable/deletable (i.e., config true,
   which is the default).  These data nodes may be considered sensitive
   or vulnerable in some network environments.  Write operations (e.g.,
   edit-config) to these data nodes without proper protection can have a
   negative effect on network operations.

   The security concerns listed above are, however, no different than
   faced by other routing protocols.  Hence, this draft does not change
   any underlying security issues inherent in [I-D.ietf-netmod-routing-
   cfg]

7.  IANA Considerations

   None.

8.  Acknowledgments

   The authors would like to acknowledge Eddie Chami, Mannan Venkatesan,
   and Sowmya Krishnaswamy for their contribution to this document.  We
   also acknowledge Ladislav Lhotka and Danial Johari for their useful
   comments.



Raza, et al.             Expires January 7, 2016               [Page 54]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


9.  References

9.1.  Normative References

   [I-D.ietf-mpls-mldp-node-protection]
              Wijnands, I., Raza, K., Rosen, E., Atlas, A., Tantsura,
              J., and Q. Zhao, "mLDP Node Protection", draft-ietf-mpls-
              mldp-node-protection-05 (work in progress), February 2015.

   [I-D.ietf-netmod-routing-cfg]
              Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", draft-ietf-netmod-routing-cfg-19 (work in
              progress), May 2015.

   [I-D.shaikh-rtgwg-policy-model]
              Shaikh, A., Shakir, R., D'Souza, K., and C. Chase,
              "Routing Policy Configuration Model for Service Provider
              Networks", draft-shaikh-rtgwg-policy-model-01 (work in
              progress), July 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

   [RFC5918]  Asati, R., Minei, I., and B. Thomas, "Label Distribution
              Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
              (FEC)", RFC 5918, August 2010.

   [RFC5919]  Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
              "Signaling LDP Label Advertisement Completion", RFC 5919,
              August 2010.

   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
              "Label Distribution Protocol Extensions for Point-to-
              Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, November 2011.

   [RFC6389]  Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
              Assignment for LDP", RFC 6389, November 2011.

   [RFC6512]  Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
              "Using Multipoint LDP When the Backbone Has No Route to
              the Root", RFC 6512, February 2012.



Raza, et al.             Expires January 7, 2016               [Page 55]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   [RFC6826]  Wijnands, IJ., 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, January 2013.

   [RFC7060]  Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP
              Multipoint Extensions on Targeted LDP Sessions", RFC 7060,
              November 2013.

   [RFC7140]  Jin, L., Jounay, F., Wijnands, IJ., and N. Leymann, "LDP
              Extensions for Hub and Spoke Multipoint Label Switched
              Path", RFC 7140, March 2014.

   [RFC7438]  Wijnands, IJ., Rosen, E., Gulko, A., Joorde, U., and J.
              Tantsura, "Multipoint LDP (mLDP) In-Band Signaling with
              Wildcards", RFC 7438, January 2015.

   [RFC7552]  Asati, R., Pignataro, C., Raza, K., Manral, V., and R.
              Papneja, "Updates to LDP for IPv6", RFC 7552, June 2015.

9.2.  Informative References

   [I-D.iwijnand-mpls-mldp-multi-topology]
              Wijnands, I. and K. Raza, "mLDP Extensions for Multi
              Topology Routing", draft-iwijnand-mpls-mldp-multi-
              topology-03 (work in progress), June 2013.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, June 2011.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March
              2012.

   [RFC7307]  Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
              King, "LDP Extensions for Multi-Topology", RFC 7307, July
              2014.






Raza, et al.             Expires January 7, 2016               [Page 56]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


Authors' Addresses

   Kamran Raza
   Cisco Systems, Inc.
   Email: skraza@cisco.com


   Xufeng Liu
   Ericsson
   Email: xufeng.liu@ericsson.com


   Santosh Esale
   Juniper Networks
   Email: sesale@juniper.net


   Xia Chen
   Huawei Technologies
   Email: jescia.chenxia@huawei.com


   Himanshu Shah
   Ciena Corporation
   Email: hshah@ciena.com


   Reshad Rahman
   Cisco Systems, Inc.
   Email: rrahman@cisco.com


   Rajiv Asati
   Cisco Systems, Inc.
   Email: rajiva@cisco.com


   Nagendra Kumar
   Cisco Systems, Inc.
   Email: naikumar@cisco.com



Raza, et al.             Expires January 7, 2016               [Page 57]


Internet-Draft      YANG Data Model for LDP and mLDP           July 2015


   Jeff Tantsura
   Ericsson
   Email: jeff.tantsura@ericsson.com


   Loa Andersson
   Huawei Technologies
   Email: loa@pi.nu


   Matthew Bocci
   Alcatel-Lucent
   Email: matthew.bocci@alcatel-lucent.com


   Vishnu P. Beeram
   Juniper Networks
   Email: vbeeram@juniper.net


   Stephane Litkowski
   Orange
   Email: stephane.litkowski@orange.com























Raza, et al.             Expires January 7, 2016               [Page 58]