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]