Internet DRAFT - draft-chen-i2rs-mpls-ldp-info-model

draft-chen-i2rs-mpls-ldp-info-model







Network Working Group                                            X. Chen
Internet-Draft                                                     Z. Li
Intended status: Standards Track                                S. Hares
Expires: April 30, 2015                              Huawei Technologies
                                                                R. White
                                                             J. Tantsura
                                                                Ericsson
                                                        October 27, 2014


                  I2RS Information Model for MPLS LDP
                 draft-chen-i2rs-mpls-ldp-info-model-00

Abstract

   The Label Distribution Protocol (LDP) ([RFC5036]) is a protocol
   defined for distributing labels in MPLS domain.  Traditionally LDP
   protocol may be managed via CLI, SNMP or NETCONF.  The Interface to
   the Routing System's (I2RS) Programmatic interface (draft-ietf-i2rs-
   architecture) provides an alternate way to control the configuration
   and diagnose the operation of the LDP protocol.

   This document specifies an information model for the LDP protocol to
   facilitate the definition of a standardized data model, which can be
   used to define interfaces to the LDP from an entity that may even be
   external to the routing system.  Based on standardized data model and
   interfaces, use cases of I2RS interface to LDP protocol (draft-chen-
   i2rs-mpls-ldp-usecases) can be supported.

Requirements Language

   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 RFC 2119 [RFC2119].

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




Chen, et al.             Expires April 30, 2015                 [Page 1]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


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

   This Internet-Draft will expire on April 30, 2015.

Copyright Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  LDP Data  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  LDP Instance  . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.1.  LDP Instance Parameters . . . . . . . . . . . . . . .   4
       2.1.2.  LDP Interface . . . . . . . . . . . . . . . . . . . .   4
       2.1.3.  LDP Remote Peer . . . . . . . . . . . . . . . . . . .   5
       2.1.4.  LDP Peer  . . . . . . . . . . . . . . . . . . . . . .   7
       2.1.5.  LDP Peer Information  . . . . . . . . . . . . . . . .   7
       2.1.6.  LDP Session . . . . . . . . . . . . . . . . . . . . .   9
       2.1.7.  LDP LSP . . . . . . . . . . . . . . . . . . . . . . .  11
       2.1.8.  LDP Policy  . . . . . . . . . . . . . . . . . . . . .  12
       2.1.9.  LDP Status  . . . . . . . . . . . . . . . . . . . . .  13
   3.  LDP notification  . . . . . . . . . . . . . . . . . . . . . .  14
   4.  I2RS YANG model of LDP  . . . . . . . . . . . . . . . . . . .  15
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   The Label Distribution Protocol (LDP) ([RFC5036]) is a protocol
   defined for distributing labels in MPLS domain.  Traditionally LDP
   protocol may be managed via CLI, SNMP or NETCONF.  With the expansion
   and complication of modern networks, the necessity for rapid and



Chen, et al.             Expires April 30, 2015                 [Page 2]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


   dynamic control has been increased.  The Interface to the Routing
   System's (I2RS) Programmatic interface ([I-D.ietf-i2rs-architecture])
   provides an alternate way to control the configuration and diagnose
   the operation of the LDP protocol and achieve this goal.

   This document specifies an information model for the LDP protocol to
   facilitate the definition of a standardized data model, which can be
   used to define interfaces to the LDP from an entity that may even be
   external to the routing system.  Based on standardized data model and
   interfaces, use cases and requirements for I2RS interface to LDP
   Protocol [I-D.chen-i2rs-mpls-ldp-usecases] can be supported.

   Please note I2RS utilizes ephemeral configuration plus status
   information.  This draft proposes needs of this ephemeral
   configuration, and the authors of this draft intent to collaborate
   with related work on yang configuration for MPLS LDP.

2.  LDP Data

   This section describes the data involved in the LDP information model
   in detail.  LDP data includes information related to LDP instances,
   LDP entities, LDP peers, LDP sessions, LDP LSPs and LDP policies.

   There are two kinds of LDP entities which are used for LDP discovery.
   One kind of LDP entity uses interface to engage in LDP basic
   discovery which is to set up the sessions between directly connected
   LSRs.  The other uses remote peer to engage in extended discovery
   which is to set up the sessions between non-directly connected LSRs.

   A high-level architecture of the LDP contents is shown as below.

                                 LDP protocol
                                       |
                                       |
                                 LDP instance
                                       |0..N
                                       |
     +-----------+-------+--------+-------------+------+-----+-----+
     |0..N       |0..N   |0..N    |0..N         |0..N  |0..N |     |
     |           |       |        |             |      |     |     |
 Interface  Remote Peer  |        |           Session Lsp  Policy Status
                        Peer  Peer Information


             Figure 1: Architecture of LDP information model






Chen, et al.             Expires April 30, 2015                 [Page 3]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


2.1.  LDP Instance

   In the context of LDP information model, LDP instance is virtual
   private network (VPN) instance or public network instance which
   contains the instance name of VPN or public network, the parameters
   of LDP instance and the data of LDP instance.  Multiple instances MAY
   be supported in one network device.

   The corresponding YANG description of the top level is below.

   module: i2rs-mplsldp
      +--rw mplsLdp
         +--rw ldpInstances
            +--rw ldpInstance* [vrfName]
               +--rw vrfName             string
               +--rw lsrid               inet:ipv4-address
               +--rw ldpInterfaces
               |     ...
               +--rw ldpRemotePeers
               |     ...
               +--rw ldpPeers
               |     ...
               +--rw ldpPeerInfos
               |     ...
               +--rw ldpSessions
               |     ...
               +--rw ldpLsps
               |     ...
               +--rw ldpPolicy
               |     ...
               +--ro ldpInstanceStatus
                     ...

2.1.1.  LDP Instance Parameters

   o vrfName: A name uniquely identifying LDP instance which is from the
   name of VPN instance.  If the name string is empty the instance means
   a public instance whose name is _public_.

   o lsrid: LSR ID of a LDP instance.

2.1.2.  LDP Interface

   LDP interface is one kind of LDP entity which is engaged in LDP basic
   discovery which is to set up the sessions between directly connected
   LSRs in LDP instance.





Chen, et al.             Expires April 30, 2015                 [Page 4]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


   This section describes the information model related to LDP interface
   which is shown in the Yang high-level description and interprets the
   meaning of each element.

               +--rw ldpInterfaces
               |  +--rw ldpInterface* [ifName]
               |     +--rw ifName                     ifName
               |     +--rw helloSendTime?             uint16
               |     +--rw helloHoldTime?             uint16
               |     +--rw keepaliveSendTime?         uint16
               |     +--rw keepaliveHoldTime?         uint16
               |     +--rw igpSyncDelayTime?          uint32
               |     +--rw transportAddrInterface?    ifName
               |     +--rw localLsrIdAddrInterface?   ifName
               |     +--rw labelAdvMode?              ldpLabelDistMode

   o ifName: the name of interface which is enabled as an LDP entity.

   o helloSendTime: the value of the timer for periodically sending
   hello packet.  The value is in seconds.

   o helloHoldTime: the interval value of the Hello hold timer.  The
   value is in seconds.

   o keepaliveSendTime: the value of the timer for periodically sending
   keepalive packet.  The value is in seconds.

   o keepaliveHoldTime: the interval value of the keepalive hold timer.
   The value is in seconds.

   o igpSyncDelayTime: the interval value at which an interface waits to
   establish an LSP after an LDP session is set up.  The value is in
   seconds.

   o transportAddrInterface: an interface address to be used as the
   transport address.

   o localLsrIdAddrInterface: an interface address to be used as local
   LSR-ID address.

   o labelAdvMode: the label distribution mode used by a session which
   is DU or DoD.

2.1.3.  LDP Remote Peer

   LDP Remote Peer is one kind of LDP entity which is engaged in
   extended discovery which is to set up the sessions between non-
   directly connected LSRs in LDP instance.



Chen, et al.             Expires April 30, 2015                 [Page 5]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


   This section describes the information model related to LDP remote
   peer which is shown in the Yang high-level description and interprets
   the meaning of each element.

               +--rw ldpRemotePeers
               |  +--rw ldpRemotePeer* [remotePeerName]
               |     +--rw remotePeerName             string
               |     +--rw remoteIp?                  inet:ipv4-address
               |     +--rw helloSendTime?             uint16
               |     +--rw helloHoldTime?             uint16
               |     +--rw keepaliveSendTime?         uint16
               |     +--rw keepaliveHoldTime?         uint16
               |     +--rw igpSyncDelayTime?          uint32
               |     +--rw localLsrIdAddrInterface?   ifName
               |     +--rw labelAdvMode?              ldpLabelDistMode
               |     +--rw remoteIpAutoDoDRequest?    boolean

   o remotePeerName: the name of a remote neighbor which is as an remote
   entity.

   o remoteIp: the IPv4 address of a remote neighbor which the LDP
   targeted hello packet will be sent to.

   o helloSendTime: the value of the timer for periodically sending
   hello packet.  The value is in seconds.

   o helloHoldTime: the interval value of the Hello hold timer.  The
   value is in seconds.

   o keepaliveSendTime: the value of the timer for periodically sending
   keepalive packet.  The value is in seconds.

   o keepaliveHoldTime: the interval value of the keepalive hold timer.
   The value is in seconds.

   o igpSyncDelayTime: the interval value at which a remote peer waits
   to establish an LSP after an LDP session is set up.  The value is in
   seconds.

   o localLsrIdAddrInterface: an interface address to be used as local
   LSR-ID address.

   o labelAdvMode: the label distribution mode used by a session which
   is DU or DoD.

   o remoteIpAutoDoDRequest: the policy of triggering LDP DoD requests
   for some prefixes.




Chen, et al.             Expires April 30, 2015                 [Page 6]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


2.1.4.  LDP Peer

   LDP Peer is used to configure local parameters which are used or sent
   to peer LSR for negotiation in LDP session establishment.

   This section describes the information model related to local
   parameters of specified LDP peer which is shown in the yang high-
   level description and interprets the meaning of each element.

               +--rw ldpPeers
               |  +--rw ldpPeer* [peerid]
               |     +--rw peerid                      inet:ipv4-address
               |     +--rw labelAdvMode?               ldpLabelDistMode
               |     +--rw localLsrIdAddrInterface?    ifName
               |     +--rw announcementCapability?     boolean
               |     +--rw mldpP2mpCapability?         boolean
               |     +--rw mldpMBBCapability?          boolean
               |     +--rw ldpSACCapability?           uint32

   o peerid: LDP peer ip address which composes the LDP LSR ID.

   o labelAdvMode: the label distribution mode used by a session which
   is DU or DoD.

   o localLsrIdAddrInterface: an interface address to be used as local
   lsr-id address.

   o announcementCapability: specifiy that if the announcement
   capability is supported locally which will be used to negotiate with
   peer.

   o mldpP2mpCapability: specify that if the p2mp capability is
   supported locally which will be used to negotiate with peer.

   o mldpMBBCapability: specify that if the mldp MBB capability is
   supported locally which will be used to negotiate with peer.

   o ldpSACCapability: specify that the application types of ldp
   SAC(State Advertisement Control) capability supported locally which
   will be used to negotiate with peer.  SAC capability is defined in
   [I-D.ietf-mpls-ldp-ip-pw-capability].

2.1.5.  LDP Peer Information

   LDP Peer information is peer parameters which are received from peer
   LSR or configured for the peer LSR.





Chen, et al.             Expires April 30, 2015                 [Page 7]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


   This section describes the information model related to information
   of LDP peer which is shown in the Yang high-level description and
   interprets the meaning of each element.

               +--rw ldpPeerInfos
               |  +--rw ldpPeerInfo* [peerLsrid]
               |     +--rw peerLsrid                   string
               |     +--rw peerMaxPduLen               uint16
               |     +--rw peerLoopDetect              boolean
               |     +--rw peerPVLimit                 uint16
               |     +--rw peerFtFlag?                 boolean
               |     +--rw peerTportAddr?              inet:ipv4-address
               |     +--rw keepaliveHoldTime?          uint16
               |     +--rw recoveryTime?               uint16
               |     +--rw reconnectTime?              uint16
               |     +--rw labelAdvMode?               ldpLabelDistMode
               |     +--rw announcementCapability?     boolean
               |     +--rw mldpP2mpCapability?         boolean
               |     +--rw mldpMBBCapability?          boolean
               |     +--rw ldpSACCapability?           uint32

   o peerLsrid: peer LDP identifier which is a six octet quantity used
   to identify an LSR label space.  The first four octets identify the
   LSR and must be a globally unique value, such as a 32-bit router Id
   assigned to the LSR.  The last two octets identify a specific label
   space within the LSR.

   o peerMaxPduLen: max length of the PDU peer sends

   o peerLoopDetect: specify that if the peer support the loop detect
   capability.

   o peerPVLimit: specify that the path vector limit supported by the
   peer.

   o peerFtFlag: specify that if the peer support the FT(Fault
   Tolerance) capability.

   o peerTportAddr: transport address of peer used for transport
   connection.

   o keepaliveHoldTime: keepalive hold time of peer.

   o recoveryTime: recovery time used for graceful restart of peer.

   o reconnectTime: reconnect time used for graceful restart of peer.





Chen, et al.             Expires April 30, 2015                 [Page 8]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


   o labelAdvMode: the label distribution mode used by a session which
   is DU or DoD.

   o announcementCapability: specify that if the peer support the
   announcement capability.

   o mldpP2mpCapability: specify that if the peer support the p2mp
   capability.

   o mldpMBBCapability: specify that if the peer support the mldp
   MBB(Make Before Break) capability.

   o ldpSACCapability: specify the application types of ldp SAC
   capability of peer.

2.1.6.  LDP Session

   LDP session is established over a TCP transport connection.  Normally
   in the LDP session initialization phase the session parameters are
   negotiated.  LDP Capabilities in [RFC5661] defines a mechanism for
   advertising LDP enhancements at session initialization time, as well
   as a mechanism to enable and disable enhancements after LDP session
   establishment.

   This section describes the information model related to LDP session
   which is shown in the Yang high-level description and interprets the
   meaning of each element.
























Chen, et al.             Expires April 30, 2015                 [Page 9]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


               +--rw ldpSessions
               |  +--rw ldpSession* [peerLsrid]
               |     +--rw peerLsrid                   string
               |     +--rw localLsrid?                 string
               |     +--rw tcpSourceAddr?              inet:ipv4-address
               |     +--rw tcpDestAddr?                inet:ipv4-address
               |     +--ro sessionState?               enumeration
               |     +--ro sessionRole?                enumeration
               |     +--ro sessionType?                enumeration
               |     +--rw negotiatedKaHoldTime?       uint32
               |     +--ro kaSent?                     uint32
               |     +--ro kaReceived?                 uint32
               |     +--rw sessionDistMode?            enumeration
               |     +--rw ftFlag?                     boolean
               |     +--ro md5Flag?                    boolean
               |     +--rw reconnetTime?               uint32
               |     +--rw recoveryTime?               uint32
               |     +--ro sessionAge?                 uint32
               |     +--rw announcementCapability?     boolean
               |     +--rw mldpP2mpCapability?         boolean
               |     +--rw mldpMBBCapability?          boolean
               |     +--rw ldpSACCapability?           uint32

   o peerLsrid: peer LDP identifier which is a six octet quantity used
   to identify an LSR label space.  The first four octets identify the
   LSR and must be a globally unique value, such as a 32-bit router Id
   assigned to the LSR.  The last two octets identify a specific label
   space within the LSR.

   o localLsrid: local LDP identifier.

   o tcpSourceAddr: TCP connection source address used by a session.

   o tcpDestAddr: destination address of the TCP connection used by a
   session.

   o sessionState: session state according to the state machine.

   o sessionRole: session role of the LSR which is active or passive.

   o sessionType: session type which is local, remote or both.

   o negotiatedKaHoldTime: the value of the Keepalive hold timer
   negotiated by local and peer LSR.

   o kaSent: the number of keepalive messages which are sent.

   o kaReceived: the number of keepalive messages which are received.



Chen, et al.             Expires April 30, 2015                [Page 10]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


   o sessionDistMode: the label distribution mode negotiated by local
   and peer LSR.

   o ftFlag: specify if the session support the FT capability.

   o md5Flag: specify if the session support the MD5 capability.

   o reconnetTime: reconnect time used for graceful restart.

   o recoveryTime: recovery time used for graceful restart.

   o sessionAge: duration since the session is set up.

   o announcementCapability: specify if the session support the
   announcement capability.

   o mldpP2mpCapability: specify if the session support the p2mp
   capability.

   o mldpMBBCapability: specify if the session support the mldp MBB
   capability.

   o ldpSACCapability: specify the application types of ldp SAC(State
   Advertisement Control ) capability of session.

2.1.7.  LDP LSP

   LDP LSP is the LSP established according to the LDP protocol.  It has
   three types which are ingress, transit and egress LSP.  The FEC may
   has multiple ingress or transit LSPs which have different outgoing
   interface and next hop.

   This section describes the information model related to LDP LSP which
   is shown in the Yang high-level description and interprets the
   meaning of each element.
















Chen, et al.             Expires April 30, 2015                [Page 11]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


            +--rw ldpLsps
            |  +--rw ldpLsp* [lspAddr prefixLength lspIndex lspType outIfaceName nextHop]
            |     +--ro lspAddr                     inet:ipv4-address
            |     +--ro prefixLength                uint32
            |     +--ro lspIndex                    uint32
            |     +--ro lspType                     enumeration
            |     +--ro outIfaceName                ifName
            |     +--ro nextHop                     inet:ipv4-address
            |     +--ro inLabel?                    uint32
            |     +--ro outLabel?                   uint32
            |     +--ro isFrrLsp?                   boolean
            |     +--ro lspMtu?                     uint32
            |     +--ro lspAge?                     uint32

   o lspAddr: prefix address of an LDP LSP.

   o prefixLength: prefix length of the prefix address of an LSP.

   o lspIndex: an LSP index.

   o lspType: LSP type which is ingress, transit or egress.

   o outIfaceName: outgoing interface.

   o nextHop: next hop address.

   o inLabel: the value of incoming label.

   o outLabel: the value of outgoing label.

   o isFrrLsp: specify if the LDP LSP is FRR LSP.

   o lspMtu: specifies an LSP MTU for the outgoing packet.

   o lspAge: duration since the LSP is setup.

2.1.8.  LDP Policy

   LDP policy can be used to limit the set up of LDP LSP by controlling
   the advertisement of LDP label mappings or other method.  The
   outbound policy can be used for specified peer, a group of peers or
   all the peers.

   This section describes the information model related to LDP policy
   which is shown in the Yang high-level description and interprets the
   meaning of each element.





Chen, et al.             Expires April 30, 2015                [Page 12]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


            +--rw ldpPolicy
               |  +--rw ldpOutBoundFecPeers
               |  |  +--rw ldpOutBoundFecPeer* [peerid]
               |  |     +--rw peerid             inet:ipv4-address
               |  |     +--rw fecPolicyMode?     fecIpPrefixGroupType
               |  |     +--rw fecIpPrefixName?   string
               |  +--rw ldpOutBoundPeerFecGroups
               |  |  +--rw ldpOutBoundPeerFecGroup* [peerid]
               |  |     +--rw peerGroupName      string
               |  |     +--rw fecPolicyMode?     fecIpPrefixGroupType
               |  |     +--rw fecIpPrefixName?   string
               |  +--rw ldpOutBoundFecPeerAll
               |     +--rw fecPolicyMode?     fecIpPrefixGroupType
               |     +--rw fecIpPrefixName?   string

   o peerid: LDP peer IP address which composes the LDP LSR ID.

   o fecPolicyMode: the mode which specifies the scope of FECs which is
   none, all or ip-prefix.

   o fecIpPrefixName: the name of IP prefix which represents the group
   of FECs whose label mappings can be sent.  (Why is there only
   permit?)

   o peerGroupName: the name of IP prefix which represents the group of
   peers which use the same policy.

2.1.9.  LDP Status

   LDP Status is about the state or statistics of LDP data.

   This section describes the information model related to LDP status
   which is shown in the Yang high-level description and interprets the
   meaning of each element.

















Chen, et al.             Expires April 30, 2015                [Page 13]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


               +--ro ldpInstanceStatus
                  +--ro sessionNum?             uint32
                  +--ro adjacencyNum?           uint32
                  +--ro interfaceNum?           uint32
                  +--ro fecNum?                 uint32
                  +--ro lspNum?                 uint32
                  |  +--ro ingressLsp?          uint32
                  |  +--ro egressLsp?           uint32
                  |  +--ro transitLsp?          uint32
                  |  +--ro totalLsp?            uint32
                  +--ro p2mpLspNum
                     +--ro ingressLsp?          uint32
                     +--ro egressLsp?           uint32
                     +--ro transitLsp?          uint32
                     +--ro budLsp?              uint32
                     +--ro totalLsp?            uint32

   o sessionNum: number of sessions.

   o adjacencyNum: number of adjacencies.

   o interfaceNum: number of interfaces served as LDP interface
   entities.

   o fecNum: number of FECs.

   o ingressLsp: number of ingress P2P LDP LSPs or mLDP P2MP LSPs.

   o egressLsp: number of egress P2P LDP LSPs or mLDP P2MP LSPs.

   o transitLsp: number of transit P2P LDP LSPs or mLDP P2MP LSPs.

   o totalLsp: number of total P2P LDP LSPs or mLDP P2MP LSPs.

   o budLsp: number of bud mLDP P2MP LSPs.

3.  LDP notification

   The notification features within the I2RS interface would allow
   applications associated with an I2RS client to subscribe to a stream
   of state changes regarding LDP protocol from the I2RS Agent.  An LDP
   protocol data-model MUST support sending asynchronous notifications.
   A brief list of suggested notifications is as below:

   o LDP session state change(up/down) notification

   o LDP Ingress LSP state change(up/down) notification for ip-prefix
   with prefix length being 32



Chen, et al.             Expires April 30, 2015                [Page 14]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


   o LDP LSP count(total LSP number) reaches the upper limit
   notification

   o LDP LSP count(total LSP number) exceeds the threshold(threshold LSP
   number) notification

4.  I2RS YANG model of LDP

module: i2rs-mplsldp
   +--rw mplsLdp
      +--rw ldpInstances
         +--rw ldpInstance* [vrfName]
            +--rw vrfName             string
            +--rw lsrid               inet:ipv4-address
            +--rw ldpInterfaces
            |  +--rw ldpInterface* [ifName]
            |     +--rw ifName                     ifName
            |     +--rw helloSendTime?             uint16
            |     +--rw helloHoldTime?             uint16
            |     +--rw keepaliveSendTime?         uint16
            |     +--rw keepaliveHoldTime?         uint16
            |     +--rw igpSyncDelayTime?          uint32
            |     +--rw transportAddrInterface?    ifName
            |     +--rw localLsrIdAddrInterface?   ifName
            |     +--rw labelAdvMode?              ldpLabelDistMode
            +--rw ldpRemotePeers
            |  +--rw ldpRemotePeer* [remotePeerName]
            |     +--rw remotePeerName             string
            |     +--rw remoteIp?                  inet:ipv4-address
            |     +--rw helloSendTime?             uint16
            |     +--rw helloHoldTime?             uint16
            |     +--rw keepaliveSendTime?         uint16
            |     +--rw keepaliveHoldTime?         uint16
            |     +--rw igpSyncDelayTime?          uint32
            |     +--rw localLsrIdAddrInterface?   ifName
            |     +--rw labelAdvMode?              ldpLabelDistMode
            |     +--rw remoteIpAutoDoDRequest?    boolean
            +--rw ldpPeers
            |  +--rw ldpPeer* [peerid]
            |     +--rw peerid                      inet:ipv4-address
            |     +--rw labelAdvMode?               ldpLabelDistMode
            |     +--rw localLsrIdAddrInterface?    ifName
            |     +--rw announcementCapability?     boolean
            |     +--rw mldpP2mpCapability?         boolean
            |     +--rw mldpMBBCapability?          boolean
            |     +--rw ldpSACCapability?           uint32
            +--rw ldpPeerInfos
            |  +--rw ldpPeerInfo* [peerLsrid]



Chen, et al.             Expires April 30, 2015                [Page 15]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


            |     +--rw peerLsrid                   string
            |     +--rw peerMaxPduLen               uint16
            |     +--rw peerLoopDetect              boolean
            |     +--rw peerPVLimit                 uint16
            |     +--rw peerFtFlag?                 boolean
            |     +--rw peerTportAddr?              inet:ipv4-address
            |     +--rw keepaliveHoldTime?          uint16
            |     +--rw recoveryTimer?              uint16
            |     +--rw reconnectTimer?             uint16
            |     +--rw labelAdvMode?               ldpLabelDistMode
            |     +--rw announcementCapability?     boolean
            |     +--rw mldpP2mpCapability?         boolean
            |     +--rw mldpMBBCapability?          boolean
            |     +--rw ldpSACCapability?           uint32
            +--rw ldpSessions
            |  +--rw ldpSession* [peerLsrid]
            |     +--rw peerLsrid                   string
            |     +--rw localLsrid?                 string
            |     +--rw tcpSourceAddr?              inet:ipv4-address
            |     +--rw tcpDestAddr?                inet:ipv4-address
            |     +--ro sessionState?               enumeration
            |     +--ro sessionRole?                enumeration
            |     +--ro sessionType?                enumeration
            |     +--rw negotiatedKaHoldTime?       uint32
            |     +--ro kaSent?                     uint32
            |     +--ro kaReceived?                 uint32
            |     +--rw sessionDistMode?            enumeration
            |     +--rw ftFlag?                     boolean
            |     +--ro md5Flag?                    boolean
            |     +--rw reconnetTime?               uint32
            |     +--rw recoveryTime?               uint32
            |     +--ro sessionAge?                 string
            |     +--rw announcementCapability?     boolean
            |     +--rw mldpP2mpCapability?         boolean
            |     +--rw mldpMBBCapability?          boolean
            |     +--rw ldpSACCapability?           uint32
            +--rw ldpLsps
            |  +--rw ldpLsp* [lspAddr prefixLength lspIndex lspType outIfaceName nextHop]
            |     +--ro lspAddr                     inet:ipv4-address
            |     +--ro prefixLength                uint32
            |     +--ro lspIndex                    uint32
            |     +--ro lspType                     enumeration
            |     +--ro outIfaceName                ifName
            |     +--ro nextHop                     inet:ipv4-address
            |     +--ro inLabel?                    uint32
            |     +--ro outLabel?                   uint32
            |     +--ro isFrrLsp?                   boolean
            |     +--ro lspMtu?                     uint32



Chen, et al.             Expires April 30, 2015                [Page 16]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


            |     +--ro lspTimeStamp?               uint32
            +--rw ldpPolicy
            |  +--rw ldpOutBoundFecPeers
            |  |  +--rw ldpOutBoundFecPeer* [peerid]
            |  |     +--rw peerid             inet:ipv4-address
            |  |     +--rw fecPolicyMode?     fecIpPrefixGroupType
            |  |     +--rw fecIpPrefixName?   string
            |  +--rw ldpOutBoundPeerFecGroups
            |  |  +--rw ldpOutBoundPeerFecGroup* [peerid]
            |  |     +--rw peerGroupName      string
            |  |     +--rw fecPolicyMode?     fecIpPrefixGroupType
            |  |     +--rw fecIpPrefixName?   string
            |  +--rw ldpOutBoundFecPeerAll
            |     +--rw fecPolicyMode?     fecIpPrefixGroupType
            |     +--rw fecIpPrefixName?   string
            +--ro ldpInstanceStatus
               +--ro sessionNum?             uint32
               +--ro adjacencyNum?           uint32
               +--ro interfaceNum?           uint32
               +--ro fecNum?                 uint32
               +--ro lspNum?                 uint32
               |  +--ro ingressLsp?          uint32
               |  +--ro egressLsp?           uint32
               |  +--ro transitLsp?          uint32
               |  +--ro totalLsp?            uint32
               +--ro p2mpLspNum
                  +--ro ingressLsp?          uint32
                  +--ro egressLsp?           uint32
                  +--ro transitLsp?          uint32
                  +--ro budLsp?              uint32
                  +--ro totalLsp?            uint32

              Figure 2 The I2RS YANG model of LDP

5.  IANA Considerations

   This draft includes no request to IANA.

6.  Security Considerations

   This document introduces no new security threat and SHOULD follow the
   security requirements as stated in [I-D.ietf-i2rs-architecture].

7.  Acknowledgements

   TBD





Chen, et al.             Expires April 30, 2015                [Page 17]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


8.  Normative References

   [I-D.chen-i2rs-mpls-ldp-usecases]
              Chen, X. and Z. Li, "Use Cases for an Interface to LDP
              Protocol", draft-chen-i2rs-mpls-ldp-usecases-00 (work in
              progress), October 2013.

   [I-D.ietf-i2rs-architecture]
              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-ietf-i2rs-architecture-05 (work in
              progress), July 2014.

   [I-D.ietf-mpls-ldp-ip-pw-capability]
              Raza, K. and S. Boutros, "Controlling State Advertisements
              Of Non-negotiated LDP Applications", draft-ietf-mpls-ldp-
              ip-pw-capability-08 (work in progress), October 2014.

   [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.

   [RFC5443]  Jork, M., Atlas, A., and L. Fang, "LDP IGP
              Synchronization", RFC 5443, March 2009.

   [RFC5661]  Shepler, S., Eisler, M., and D. Noveck, "Network File
              System (NFS) Version 4 Minor Version 1 Protocol", RFC
              5661, January 2010.

   [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.

   [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.

   [RFC6720]  Pignataro, C. and R. Asati, "The Generalized TTL Security
              Mechanism (GTSM) for the Label Distribution Protocol
              (LDP)", RFC 6720, August 2012.




Chen, et al.             Expires April 30, 2015                [Page 18]

Internet-Draft     I2RS Information Model for MPLS LDP      October 2014


Authors' Addresses

   Xia Chen
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: jescia.chenxia@huawei.com


   Zhenbin Li
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com


   Susan Hares
   Huawei Technologies
   Saline, MI  48176
   US

   Email: shares@ndzh.com


   Russ White
   Ericsson
   US

   Email: russ.white@ericsson.com


   Jeff Tantsura
   Ericsson

   Email: jeff.tantsura@ericsson.com












Chen, et al.             Expires April 30, 2015                [Page 19]