idnits 2.17.1 draft-chen-i2rs-mpls-ldp-info-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The abstract seems to contain references ([RFC5036]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3461 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5443' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'RFC6388' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC6720' is defined on line 809, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-chen-i2rs-mpls-ldp-usecases (ref. 'I-D.chen-i2rs-mpls-ldp-usecases') == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-05 ** Downref: Normative reference to an Informational draft: draft-ietf-i2rs-architecture (ref. 'I-D.ietf-i2rs-architecture') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-ldp-ip-pw-capability-08 ** Downref: Normative reference to an Informational RFC: RFC 5443 ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Chen 3 Internet-Draft Z. Li 4 Intended status: Standards Track S. Hares 5 Expires: April 30, 2015 Huawei Technologies 6 R. White 7 J. Tantsura 8 Ericsson 9 October 27, 2014 11 I2RS Information Model for MPLS LDP 12 draft-chen-i2rs-mpls-ldp-info-model-00 14 Abstract 16 The Label Distribution Protocol (LDP) ([RFC5036]) is a protocol 17 defined for distributing labels in MPLS domain. Traditionally LDP 18 protocol may be managed via CLI, SNMP or NETCONF. The Interface to 19 the Routing System's (I2RS) Programmatic interface (draft-ietf-i2rs- 20 architecture) provides an alternate way to control the configuration 21 and diagnose the operation of the LDP protocol. 23 This document specifies an information model for the LDP protocol to 24 facilitate the definition of a standardized data model, which can be 25 used to define interfaces to the LDP from an entity that may even be 26 external to the routing system. Based on standardized data model and 27 interfaces, use cases of I2RS interface to LDP protocol (draft-chen- 28 i2rs-mpls-ldp-usecases) can be supported. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 30, 2015. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. LDP Data . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.1. LDP Instance . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1.1. LDP Instance Parameters . . . . . . . . . . . . . . . 4 74 2.1.2. LDP Interface . . . . . . . . . . . . . . . . . . . . 4 75 2.1.3. LDP Remote Peer . . . . . . . . . . . . . . . . . . . 5 76 2.1.4. LDP Peer . . . . . . . . . . . . . . . . . . . . . . 7 77 2.1.5. LDP Peer Information . . . . . . . . . . . . . . . . 7 78 2.1.6. LDP Session . . . . . . . . . . . . . . . . . . . . . 9 79 2.1.7. LDP LSP . . . . . . . . . . . . . . . . . . . . . . . 11 80 2.1.8. LDP Policy . . . . . . . . . . . . . . . . . . . . . 12 81 2.1.9. LDP Status . . . . . . . . . . . . . . . . . . . . . 13 82 3. LDP notification . . . . . . . . . . . . . . . . . . . . . . 14 83 4. I2RS YANG model of LDP . . . . . . . . . . . . . . . . . . . 15 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 8. Normative References . . . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 The Label Distribution Protocol (LDP) ([RFC5036]) is a protocol 93 defined for distributing labels in MPLS domain. Traditionally LDP 94 protocol may be managed via CLI, SNMP or NETCONF. With the expansion 95 and complication of modern networks, the necessity for rapid and 96 dynamic control has been increased. The Interface to the Routing 97 System's (I2RS) Programmatic interface ([I-D.ietf-i2rs-architecture]) 98 provides an alternate way to control the configuration and diagnose 99 the operation of the LDP protocol and achieve this goal. 101 This document specifies an information model for the LDP protocol to 102 facilitate the definition of a standardized data model, which can be 103 used to define interfaces to the LDP from an entity that may even be 104 external to the routing system. Based on standardized data model and 105 interfaces, use cases and requirements for I2RS interface to LDP 106 Protocol [I-D.chen-i2rs-mpls-ldp-usecases] can be supported. 108 Please note I2RS utilizes ephemeral configuration plus status 109 information. This draft proposes needs of this ephemeral 110 configuration, and the authors of this draft intent to collaborate 111 with related work on yang configuration for MPLS LDP. 113 2. LDP Data 115 This section describes the data involved in the LDP information model 116 in detail. LDP data includes information related to LDP instances, 117 LDP entities, LDP peers, LDP sessions, LDP LSPs and LDP policies. 119 There are two kinds of LDP entities which are used for LDP discovery. 120 One kind of LDP entity uses interface to engage in LDP basic 121 discovery which is to set up the sessions between directly connected 122 LSRs. The other uses remote peer to engage in extended discovery 123 which is to set up the sessions between non-directly connected LSRs. 125 A high-level architecture of the LDP contents is shown as below. 127 LDP protocol 128 | 129 | 130 LDP instance 131 |0..N 132 | 133 +-----------+-------+--------+-------------+------+-----+-----+ 134 |0..N |0..N |0..N |0..N |0..N |0..N | | 135 | | | | | | | | 136 Interface Remote Peer | | Session Lsp Policy Status 137 Peer Peer Information 139 Figure 1: Architecture of LDP information model 141 2.1. LDP Instance 143 In the context of LDP information model, LDP instance is virtual 144 private network (VPN) instance or public network instance which 145 contains the instance name of VPN or public network, the parameters 146 of LDP instance and the data of LDP instance. Multiple instances MAY 147 be supported in one network device. 149 The corresponding YANG description of the top level is below. 151 module: i2rs-mplsldp 152 +--rw mplsLdp 153 +--rw ldpInstances 154 +--rw ldpInstance* [vrfName] 155 +--rw vrfName string 156 +--rw lsrid inet:ipv4-address 157 +--rw ldpInterfaces 158 | ... 159 +--rw ldpRemotePeers 160 | ... 161 +--rw ldpPeers 162 | ... 163 +--rw ldpPeerInfos 164 | ... 165 +--rw ldpSessions 166 | ... 167 +--rw ldpLsps 168 | ... 169 +--rw ldpPolicy 170 | ... 171 +--ro ldpInstanceStatus 172 ... 174 2.1.1. LDP Instance Parameters 176 o vrfName: A name uniquely identifying LDP instance which is from the 177 name of VPN instance. If the name string is empty the instance means 178 a public instance whose name is _public_. 180 o lsrid: LSR ID of a LDP instance. 182 2.1.2. LDP Interface 184 LDP interface is one kind of LDP entity which is engaged in LDP basic 185 discovery which is to set up the sessions between directly connected 186 LSRs in LDP instance. 188 This section describes the information model related to LDP interface 189 which is shown in the Yang high-level description and interprets the 190 meaning of each element. 192 +--rw ldpInterfaces 193 | +--rw ldpInterface* [ifName] 194 | +--rw ifName ifName 195 | +--rw helloSendTime? uint16 196 | +--rw helloHoldTime? uint16 197 | +--rw keepaliveSendTime? uint16 198 | +--rw keepaliveHoldTime? uint16 199 | +--rw igpSyncDelayTime? uint32 200 | +--rw transportAddrInterface? ifName 201 | +--rw localLsrIdAddrInterface? ifName 202 | +--rw labelAdvMode? ldpLabelDistMode 204 o ifName: the name of interface which is enabled as an LDP entity. 206 o helloSendTime: the value of the timer for periodically sending 207 hello packet. The value is in seconds. 209 o helloHoldTime: the interval value of the Hello hold timer. The 210 value is in seconds. 212 o keepaliveSendTime: the value of the timer for periodically sending 213 keepalive packet. The value is in seconds. 215 o keepaliveHoldTime: the interval value of the keepalive hold timer. 216 The value is in seconds. 218 o igpSyncDelayTime: the interval value at which an interface waits to 219 establish an LSP after an LDP session is set up. The value is in 220 seconds. 222 o transportAddrInterface: an interface address to be used as the 223 transport address. 225 o localLsrIdAddrInterface: an interface address to be used as local 226 LSR-ID address. 228 o labelAdvMode: the label distribution mode used by a session which 229 is DU or DoD. 231 2.1.3. LDP Remote Peer 233 LDP Remote Peer is one kind of LDP entity which is engaged in 234 extended discovery which is to set up the sessions between non- 235 directly connected LSRs in LDP instance. 237 This section describes the information model related to LDP remote 238 peer which is shown in the Yang high-level description and interprets 239 the meaning of each element. 241 +--rw ldpRemotePeers 242 | +--rw ldpRemotePeer* [remotePeerName] 243 | +--rw remotePeerName string 244 | +--rw remoteIp? inet:ipv4-address 245 | +--rw helloSendTime? uint16 246 | +--rw helloHoldTime? uint16 247 | +--rw keepaliveSendTime? uint16 248 | +--rw keepaliveHoldTime? uint16 249 | +--rw igpSyncDelayTime? uint32 250 | +--rw localLsrIdAddrInterface? ifName 251 | +--rw labelAdvMode? ldpLabelDistMode 252 | +--rw remoteIpAutoDoDRequest? boolean 254 o remotePeerName: the name of a remote neighbor which is as an remote 255 entity. 257 o remoteIp: the IPv4 address of a remote neighbor which the LDP 258 targeted hello packet will be sent to. 260 o helloSendTime: the value of the timer for periodically sending 261 hello packet. The value is in seconds. 263 o helloHoldTime: the interval value of the Hello hold timer. The 264 value is in seconds. 266 o keepaliveSendTime: the value of the timer for periodically sending 267 keepalive packet. The value is in seconds. 269 o keepaliveHoldTime: the interval value of the keepalive hold timer. 270 The value is in seconds. 272 o igpSyncDelayTime: the interval value at which a remote peer waits 273 to establish an LSP after an LDP session is set up. The value is in 274 seconds. 276 o localLsrIdAddrInterface: an interface address to be used as local 277 LSR-ID address. 279 o labelAdvMode: the label distribution mode used by a session which 280 is DU or DoD. 282 o remoteIpAutoDoDRequest: the policy of triggering LDP DoD requests 283 for some prefixes. 285 2.1.4. LDP Peer 287 LDP Peer is used to configure local parameters which are used or sent 288 to peer LSR for negotiation in LDP session establishment. 290 This section describes the information model related to local 291 parameters of specified LDP peer which is shown in the yang high- 292 level description and interprets the meaning of each element. 294 +--rw ldpPeers 295 | +--rw ldpPeer* [peerid] 296 | +--rw peerid inet:ipv4-address 297 | +--rw labelAdvMode? ldpLabelDistMode 298 | +--rw localLsrIdAddrInterface? ifName 299 | +--rw announcementCapability? boolean 300 | +--rw mldpP2mpCapability? boolean 301 | +--rw mldpMBBCapability? boolean 302 | +--rw ldpSACCapability? uint32 304 o peerid: LDP peer ip address which composes the LDP LSR ID. 306 o labelAdvMode: the label distribution mode used by a session which 307 is DU or DoD. 309 o localLsrIdAddrInterface: an interface address to be used as local 310 lsr-id address. 312 o announcementCapability: specifiy that if the announcement 313 capability is supported locally which will be used to negotiate with 314 peer. 316 o mldpP2mpCapability: specify that if the p2mp capability is 317 supported locally which will be used to negotiate with peer. 319 o mldpMBBCapability: specify that if the mldp MBB capability is 320 supported locally which will be used to negotiate with peer. 322 o ldpSACCapability: specify that the application types of ldp 323 SAC(State Advertisement Control) capability supported locally which 324 will be used to negotiate with peer. SAC capability is defined in 325 [I-D.ietf-mpls-ldp-ip-pw-capability]. 327 2.1.5. LDP Peer Information 329 LDP Peer information is peer parameters which are received from peer 330 LSR or configured for the peer LSR. 332 This section describes the information model related to information 333 of LDP peer which is shown in the Yang high-level description and 334 interprets the meaning of each element. 336 +--rw ldpPeerInfos 337 | +--rw ldpPeerInfo* [peerLsrid] 338 | +--rw peerLsrid string 339 | +--rw peerMaxPduLen uint16 340 | +--rw peerLoopDetect boolean 341 | +--rw peerPVLimit uint16 342 | +--rw peerFtFlag? boolean 343 | +--rw peerTportAddr? inet:ipv4-address 344 | +--rw keepaliveHoldTime? uint16 345 | +--rw recoveryTime? uint16 346 | +--rw reconnectTime? uint16 347 | +--rw labelAdvMode? ldpLabelDistMode 348 | +--rw announcementCapability? boolean 349 | +--rw mldpP2mpCapability? boolean 350 | +--rw mldpMBBCapability? boolean 351 | +--rw ldpSACCapability? uint32 353 o peerLsrid: peer LDP identifier which is a six octet quantity used 354 to identify an LSR label space. The first four octets identify the 355 LSR and must be a globally unique value, such as a 32-bit router Id 356 assigned to the LSR. The last two octets identify a specific label 357 space within the LSR. 359 o peerMaxPduLen: max length of the PDU peer sends 361 o peerLoopDetect: specify that if the peer support the loop detect 362 capability. 364 o peerPVLimit: specify that the path vector limit supported by the 365 peer. 367 o peerFtFlag: specify that if the peer support the FT(Fault 368 Tolerance) capability. 370 o peerTportAddr: transport address of peer used for transport 371 connection. 373 o keepaliveHoldTime: keepalive hold time of peer. 375 o recoveryTime: recovery time used for graceful restart of peer. 377 o reconnectTime: reconnect time used for graceful restart of peer. 379 o labelAdvMode: the label distribution mode used by a session which 380 is DU or DoD. 382 o announcementCapability: specify that if the peer support the 383 announcement capability. 385 o mldpP2mpCapability: specify that if the peer support the p2mp 386 capability. 388 o mldpMBBCapability: specify that if the peer support the mldp 389 MBB(Make Before Break) capability. 391 o ldpSACCapability: specify the application types of ldp SAC 392 capability of peer. 394 2.1.6. LDP Session 396 LDP session is established over a TCP transport connection. Normally 397 in the LDP session initialization phase the session parameters are 398 negotiated. LDP Capabilities in [RFC5661] defines a mechanism for 399 advertising LDP enhancements at session initialization time, as well 400 as a mechanism to enable and disable enhancements after LDP session 401 establishment. 403 This section describes the information model related to LDP session 404 which is shown in the Yang high-level description and interprets the 405 meaning of each element. 407 +--rw ldpSessions 408 | +--rw ldpSession* [peerLsrid] 409 | +--rw peerLsrid string 410 | +--rw localLsrid? string 411 | +--rw tcpSourceAddr? inet:ipv4-address 412 | +--rw tcpDestAddr? inet:ipv4-address 413 | +--ro sessionState? enumeration 414 | +--ro sessionRole? enumeration 415 | +--ro sessionType? enumeration 416 | +--rw negotiatedKaHoldTime? uint32 417 | +--ro kaSent? uint32 418 | +--ro kaReceived? uint32 419 | +--rw sessionDistMode? enumeration 420 | +--rw ftFlag? boolean 421 | +--ro md5Flag? boolean 422 | +--rw reconnetTime? uint32 423 | +--rw recoveryTime? uint32 424 | +--ro sessionAge? uint32 425 | +--rw announcementCapability? boolean 426 | +--rw mldpP2mpCapability? boolean 427 | +--rw mldpMBBCapability? boolean 428 | +--rw ldpSACCapability? uint32 430 o peerLsrid: peer LDP identifier which is a six octet quantity used 431 to identify an LSR label space. The first four octets identify the 432 LSR and must be a globally unique value, such as a 32-bit router Id 433 assigned to the LSR. The last two octets identify a specific label 434 space within the LSR. 436 o localLsrid: local LDP identifier. 438 o tcpSourceAddr: TCP connection source address used by a session. 440 o tcpDestAddr: destination address of the TCP connection used by a 441 session. 443 o sessionState: session state according to the state machine. 445 o sessionRole: session role of the LSR which is active or passive. 447 o sessionType: session type which is local, remote or both. 449 o negotiatedKaHoldTime: the value of the Keepalive hold timer 450 negotiated by local and peer LSR. 452 o kaSent: the number of keepalive messages which are sent. 454 o kaReceived: the number of keepalive messages which are received. 456 o sessionDistMode: the label distribution mode negotiated by local 457 and peer LSR. 459 o ftFlag: specify if the session support the FT capability. 461 o md5Flag: specify if the session support the MD5 capability. 463 o reconnetTime: reconnect time used for graceful restart. 465 o recoveryTime: recovery time used for graceful restart. 467 o sessionAge: duration since the session is set up. 469 o announcementCapability: specify if the session support the 470 announcement capability. 472 o mldpP2mpCapability: specify if the session support the p2mp 473 capability. 475 o mldpMBBCapability: specify if the session support the mldp MBB 476 capability. 478 o ldpSACCapability: specify the application types of ldp SAC(State 479 Advertisement Control ) capability of session. 481 2.1.7. LDP LSP 483 LDP LSP is the LSP established according to the LDP protocol. It has 484 three types which are ingress, transit and egress LSP. The FEC may 485 has multiple ingress or transit LSPs which have different outgoing 486 interface and next hop. 488 This section describes the information model related to LDP LSP which 489 is shown in the Yang high-level description and interprets the 490 meaning of each element. 492 +--rw ldpLsps 493 | +--rw ldpLsp* [lspAddr prefixLength lspIndex lspType outIfaceName nextHop] 494 | +--ro lspAddr inet:ipv4-address 495 | +--ro prefixLength uint32 496 | +--ro lspIndex uint32 497 | +--ro lspType enumeration 498 | +--ro outIfaceName ifName 499 | +--ro nextHop inet:ipv4-address 500 | +--ro inLabel? uint32 501 | +--ro outLabel? uint32 502 | +--ro isFrrLsp? boolean 503 | +--ro lspMtu? uint32 504 | +--ro lspAge? uint32 506 o lspAddr: prefix address of an LDP LSP. 508 o prefixLength: prefix length of the prefix address of an LSP. 510 o lspIndex: an LSP index. 512 o lspType: LSP type which is ingress, transit or egress. 514 o outIfaceName: outgoing interface. 516 o nextHop: next hop address. 518 o inLabel: the value of incoming label. 520 o outLabel: the value of outgoing label. 522 o isFrrLsp: specify if the LDP LSP is FRR LSP. 524 o lspMtu: specifies an LSP MTU for the outgoing packet. 526 o lspAge: duration since the LSP is setup. 528 2.1.8. LDP Policy 530 LDP policy can be used to limit the set up of LDP LSP by controlling 531 the advertisement of LDP label mappings or other method. The 532 outbound policy can be used for specified peer, a group of peers or 533 all the peers. 535 This section describes the information model related to LDP policy 536 which is shown in the Yang high-level description and interprets the 537 meaning of each element. 539 +--rw ldpPolicy 540 | +--rw ldpOutBoundFecPeers 541 | | +--rw ldpOutBoundFecPeer* [peerid] 542 | | +--rw peerid inet:ipv4-address 543 | | +--rw fecPolicyMode? fecIpPrefixGroupType 544 | | +--rw fecIpPrefixName? string 545 | +--rw ldpOutBoundPeerFecGroups 546 | | +--rw ldpOutBoundPeerFecGroup* [peerid] 547 | | +--rw peerGroupName string 548 | | +--rw fecPolicyMode? fecIpPrefixGroupType 549 | | +--rw fecIpPrefixName? string 550 | +--rw ldpOutBoundFecPeerAll 551 | +--rw fecPolicyMode? fecIpPrefixGroupType 552 | +--rw fecIpPrefixName? string 554 o peerid: LDP peer IP address which composes the LDP LSR ID. 556 o fecPolicyMode: the mode which specifies the scope of FECs which is 557 none, all or ip-prefix. 559 o fecIpPrefixName: the name of IP prefix which represents the group 560 of FECs whose label mappings can be sent. (Why is there only 561 permit?) 563 o peerGroupName: the name of IP prefix which represents the group of 564 peers which use the same policy. 566 2.1.9. LDP Status 568 LDP Status is about the state or statistics of LDP data. 570 This section describes the information model related to LDP status 571 which is shown in the Yang high-level description and interprets the 572 meaning of each element. 574 +--ro ldpInstanceStatus 575 +--ro sessionNum? uint32 576 +--ro adjacencyNum? uint32 577 +--ro interfaceNum? uint32 578 +--ro fecNum? uint32 579 +--ro lspNum? uint32 580 | +--ro ingressLsp? uint32 581 | +--ro egressLsp? uint32 582 | +--ro transitLsp? uint32 583 | +--ro totalLsp? uint32 584 +--ro p2mpLspNum 585 +--ro ingressLsp? uint32 586 +--ro egressLsp? uint32 587 +--ro transitLsp? uint32 588 +--ro budLsp? uint32 589 +--ro totalLsp? uint32 591 o sessionNum: number of sessions. 593 o adjacencyNum: number of adjacencies. 595 o interfaceNum: number of interfaces served as LDP interface 596 entities. 598 o fecNum: number of FECs. 600 o ingressLsp: number of ingress P2P LDP LSPs or mLDP P2MP LSPs. 602 o egressLsp: number of egress P2P LDP LSPs or mLDP P2MP LSPs. 604 o transitLsp: number of transit P2P LDP LSPs or mLDP P2MP LSPs. 606 o totalLsp: number of total P2P LDP LSPs or mLDP P2MP LSPs. 608 o budLsp: number of bud mLDP P2MP LSPs. 610 3. LDP notification 612 The notification features within the I2RS interface would allow 613 applications associated with an I2RS client to subscribe to a stream 614 of state changes regarding LDP protocol from the I2RS Agent. An LDP 615 protocol data-model MUST support sending asynchronous notifications. 616 A brief list of suggested notifications is as below: 618 o LDP session state change(up/down) notification 620 o LDP Ingress LSP state change(up/down) notification for ip-prefix 621 with prefix length being 32 622 o LDP LSP count(total LSP number) reaches the upper limit 623 notification 625 o LDP LSP count(total LSP number) exceeds the threshold(threshold LSP 626 number) notification 628 4. I2RS YANG model of LDP 630 module: i2rs-mplsldp 631 +--rw mplsLdp 632 +--rw ldpInstances 633 +--rw ldpInstance* [vrfName] 634 +--rw vrfName string 635 +--rw lsrid inet:ipv4-address 636 +--rw ldpInterfaces 637 | +--rw ldpInterface* [ifName] 638 | +--rw ifName ifName 639 | +--rw helloSendTime? uint16 640 | +--rw helloHoldTime? uint16 641 | +--rw keepaliveSendTime? uint16 642 | +--rw keepaliveHoldTime? uint16 643 | +--rw igpSyncDelayTime? uint32 644 | +--rw transportAddrInterface? ifName 645 | +--rw localLsrIdAddrInterface? ifName 646 | +--rw labelAdvMode? ldpLabelDistMode 647 +--rw ldpRemotePeers 648 | +--rw ldpRemotePeer* [remotePeerName] 649 | +--rw remotePeerName string 650 | +--rw remoteIp? inet:ipv4-address 651 | +--rw helloSendTime? uint16 652 | +--rw helloHoldTime? uint16 653 | +--rw keepaliveSendTime? uint16 654 | +--rw keepaliveHoldTime? uint16 655 | +--rw igpSyncDelayTime? uint32 656 | +--rw localLsrIdAddrInterface? ifName 657 | +--rw labelAdvMode? ldpLabelDistMode 658 | +--rw remoteIpAutoDoDRequest? boolean 659 +--rw ldpPeers 660 | +--rw ldpPeer* [peerid] 661 | +--rw peerid inet:ipv4-address 662 | +--rw labelAdvMode? ldpLabelDistMode 663 | +--rw localLsrIdAddrInterface? ifName 664 | +--rw announcementCapability? boolean 665 | +--rw mldpP2mpCapability? boolean 666 | +--rw mldpMBBCapability? boolean 667 | +--rw ldpSACCapability? uint32 668 +--rw ldpPeerInfos 669 | +--rw ldpPeerInfo* [peerLsrid] 670 | +--rw peerLsrid string 671 | +--rw peerMaxPduLen uint16 672 | +--rw peerLoopDetect boolean 673 | +--rw peerPVLimit uint16 674 | +--rw peerFtFlag? boolean 675 | +--rw peerTportAddr? inet:ipv4-address 676 | +--rw keepaliveHoldTime? uint16 677 | +--rw recoveryTimer? uint16 678 | +--rw reconnectTimer? uint16 679 | +--rw labelAdvMode? ldpLabelDistMode 680 | +--rw announcementCapability? boolean 681 | +--rw mldpP2mpCapability? boolean 682 | +--rw mldpMBBCapability? boolean 683 | +--rw ldpSACCapability? uint32 684 +--rw ldpSessions 685 | +--rw ldpSession* [peerLsrid] 686 | +--rw peerLsrid string 687 | +--rw localLsrid? string 688 | +--rw tcpSourceAddr? inet:ipv4-address 689 | +--rw tcpDestAddr? inet:ipv4-address 690 | +--ro sessionState? enumeration 691 | +--ro sessionRole? enumeration 692 | +--ro sessionType? enumeration 693 | +--rw negotiatedKaHoldTime? uint32 694 | +--ro kaSent? uint32 695 | +--ro kaReceived? uint32 696 | +--rw sessionDistMode? enumeration 697 | +--rw ftFlag? boolean 698 | +--ro md5Flag? boolean 699 | +--rw reconnetTime? uint32 700 | +--rw recoveryTime? uint32 701 | +--ro sessionAge? string 702 | +--rw announcementCapability? boolean 703 | +--rw mldpP2mpCapability? boolean 704 | +--rw mldpMBBCapability? boolean 705 | +--rw ldpSACCapability? uint32 706 +--rw ldpLsps 707 | +--rw ldpLsp* [lspAddr prefixLength lspIndex lspType outIfaceName nextHop] 708 | +--ro lspAddr inet:ipv4-address 709 | +--ro prefixLength uint32 710 | +--ro lspIndex uint32 711 | +--ro lspType enumeration 712 | +--ro outIfaceName ifName 713 | +--ro nextHop inet:ipv4-address 714 | +--ro inLabel? uint32 715 | +--ro outLabel? uint32 716 | +--ro isFrrLsp? boolean 717 | +--ro lspMtu? uint32 718 | +--ro lspTimeStamp? uint32 719 +--rw ldpPolicy 720 | +--rw ldpOutBoundFecPeers 721 | | +--rw ldpOutBoundFecPeer* [peerid] 722 | | +--rw peerid inet:ipv4-address 723 | | +--rw fecPolicyMode? fecIpPrefixGroupType 724 | | +--rw fecIpPrefixName? string 725 | +--rw ldpOutBoundPeerFecGroups 726 | | +--rw ldpOutBoundPeerFecGroup* [peerid] 727 | | +--rw peerGroupName string 728 | | +--rw fecPolicyMode? fecIpPrefixGroupType 729 | | +--rw fecIpPrefixName? string 730 | +--rw ldpOutBoundFecPeerAll 731 | +--rw fecPolicyMode? fecIpPrefixGroupType 732 | +--rw fecIpPrefixName? string 733 +--ro ldpInstanceStatus 734 +--ro sessionNum? uint32 735 +--ro adjacencyNum? uint32 736 +--ro interfaceNum? uint32 737 +--ro fecNum? uint32 738 +--ro lspNum? uint32 739 | +--ro ingressLsp? uint32 740 | +--ro egressLsp? uint32 741 | +--ro transitLsp? uint32 742 | +--ro totalLsp? uint32 743 +--ro p2mpLspNum 744 +--ro ingressLsp? uint32 745 +--ro egressLsp? uint32 746 +--ro transitLsp? uint32 747 +--ro budLsp? uint32 748 +--ro totalLsp? uint32 750 Figure 2 The I2RS YANG model of LDP 752 5. IANA Considerations 754 This draft includes no request to IANA. 756 6. Security Considerations 758 This document introduces no new security threat and SHOULD follow the 759 security requirements as stated in [I-D.ietf-i2rs-architecture]. 761 7. Acknowledgements 763 TBD 765 8. Normative References 767 [I-D.chen-i2rs-mpls-ldp-usecases] 768 Chen, X. and Z. Li, "Use Cases for an Interface to LDP 769 Protocol", draft-chen-i2rs-mpls-ldp-usecases-00 (work in 770 progress), October 2013. 772 [I-D.ietf-i2rs-architecture] 773 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 774 Nadeau, "An Architecture for the Interface to the Routing 775 System", draft-ietf-i2rs-architecture-05 (work in 776 progress), July 2014. 778 [I-D.ietf-mpls-ldp-ip-pw-capability] 779 Raza, K. and S. Boutros, "Controlling State Advertisements 780 Of Non-negotiated LDP Applications", draft-ietf-mpls-ldp- 781 ip-pw-capability-08 (work in progress), October 2014. 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, March 1997. 786 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 787 Specification", RFC 5036, October 2007. 789 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 790 Synchronization", RFC 5443, March 2009. 792 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 793 System (NFS) Version 4 Minor Version 1 Protocol", RFC 794 5661, January 2010. 796 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 797 Network Configuration Protocol (NETCONF)", RFC 6020, 798 October 2010. 800 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 801 Bierman, "Network Configuration Protocol (NETCONF)", RFC 802 6241, June 2011. 804 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 805 "Label Distribution Protocol Extensions for Point-to- 806 Multipoint and Multipoint-to-Multipoint Label Switched 807 Paths", RFC 6388, November 2011. 809 [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security 810 Mechanism (GTSM) for the Label Distribution Protocol 811 (LDP)", RFC 6720, August 2012. 813 Authors' Addresses 815 Xia Chen 816 Huawei Technologies 817 Huawei Bld., No.156 Beiqing Rd. 818 Beijing 100095 819 China 821 Email: jescia.chenxia@huawei.com 823 Zhenbin Li 824 Huawei Technologies 825 Huawei Bld., No.156 Beiqing Rd. 826 Beijing 100095 827 China 829 Email: lizhenbin@huawei.com 831 Susan Hares 832 Huawei Technologies 833 Saline, MI 48176 834 US 836 Email: shares@ndzh.com 838 Russ White 839 Ericsson 840 US 842 Email: russ.white@ericsson.com 844 Jeff Tantsura 845 Ericsson 847 Email: jeff.tantsura@ericsson.com