idnits 2.17.1 draft-ietf-mpls-mp-ldp-reqs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 859. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The P2MP LDP mechanism MUST allow the dynamic addition and removal of leaves to and from a P2MP LSP, without any restriction (provided there is network connectivity). It is RECOMMENDED that these operations be leaf-initiated. These operations MUST not impact the data transfer (packet loss, duplication, delay) towards other leaves. It is RECOMMENDED that these operations do not cause any additional processing except on the path from the added/removed Leaf LSR to the Branch LSR. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The P2MP LDP extension MUST have a mechanism to detect routing loops. This may rely on extensions to the LDP Loop detection mechanism defined in [RFC5036]. A loop detection mechanism may require recording the set of LSRs traversed on the P2MP Tree. The P2MP loop avoidance mechanism MUST not impact the scalability of the P2MP LDP solution. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms and inherit its capability sets from [RFC5036]. The P2MP LDP solution MUST not impede the operation of P2P/MP2P LSPs. A P2MP LDP solution MUST be designed in such a way that it allows P2P/MP2P and P2MP LSPs to be signalled on the same interface. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The MP2MP LDP procedures MUST not impede the operations of P2MP LSP. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: - It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a specific LSR called root LSR; - It is RECOMMENDED to define several root LSRs (e.g. a primary and a backup) to ensure redundancy upon root LSR failure; - The receiver SHOULD not receive back a packet it has sent on the MP2MP LSP; - The solution SHOULD avoid that all traffic between any pair of leaves is traversing a root LSR, and SHOULD as much as possible minimize the distance between two leaves (similarly to PIM-Bidir trees); - It MUST be possible to check connectivity of a MP2MP LSP in both directions. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The proposed solution SHOULD not introduce complexity to the current LDP operations to such a degree that it would affect the stability and diminish the benefits of deploying such solution. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2008) is 5884 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3031' is mentioned on line 134, but not defined == Missing Reference: 'MPLS-SEC' is mentioned on line 714, but not defined Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.-L. Le Roux (Editor) 3 Internet Draft France Telecom 4 Category: Informational 5 Expires: August 2008 7 March 2008 9 Requirements for Point-To-Multipoint Extensions to 10 the Label Distribution Protocol 12 draft-ietf-mpls-mp-ldp-reqs-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 Abstract 37 This document lists a set of functional requirements for Label 38 Distribution Protocol (LDP) extensions for setting up point-to- 39 multipoint (P2MP) Label Switched Paths (LSP), in order to deliver 40 point-to-multipoint applications over a Multi Protocol Label 41 Switching (MPLS) infrastructure. It is intended that solutions that 42 specify LDP procedures for setting up P2MP LSP satisfy these 43 requirements. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in [RFC2119]. 51 Table of Contents 53 1. Contributing Authors........................................3 54 2. Definitions.................................................3 55 2.1. Acronyms....................................................3 56 2.2. Terminology.................................................3 57 3. Introduction................................................5 58 4. Problem Statement and Requirements Overview.................6 59 4.1. Problem Statement...........................................6 60 4.2. Requirements overview.......................................6 61 5. Application scenario........................................7 62 6. Detailed Requirements.......................................8 63 6.1. P2MP LSPs...................................................8 64 6.2. P2MP LSP FEC................................................8 65 6.3. P2MP LDP routing............................................9 66 6.4. Setting up, tearing down and modifying P2MP LSPs............9 67 6.5. Label Advertisement.........................................9 68 6.6. Data Duplication............................................9 69 6.7. Detecting and Avoiding Loops...............................10 70 6.8. P2MP LSP Re-routing........................................10 71 6.8.1. Rerouting upon Network Failure.............................10 72 6.8.2. Rerouting on a Better Path.................................10 73 6.8.3. Rerouting upon Planned Maintenance.........................11 74 6.9. Support for LAN interfaces.................................11 75 6.10. Support for encapsulation in P2P and P2MP TE tunnels.......11 76 6.11. Label spaces...............................................11 77 6.12. IPv4/IPv6 support..........................................11 78 6.13. Multi-Area/AS LSPs.........................................12 79 6.14. OAM........................................................12 80 6.15. Graceful Restart and Fault Recovery........................12 81 6.16. Robustness.................................................12 82 6.17. Scalability................................................12 83 6.17.1. Orders of magnitude expected in operational networks......13 84 6.18. Backward Compatibility.....................................13 85 7. Shared Trees...............................................13 86 7.1. Requirements for MP2MP LSPs................................14 87 8. Evaluation criteria........................................14 88 8.1. Performances...............................................14 89 8.2. Complexity and Risks.......................................15 90 9. Security Considerations....................................15 91 10. IANA Considerations........................................15 92 11. Acknowledgments............................................15 93 12. References.................................................15 94 12.1. Normative references.......................................15 95 12.2. Informative references.....................................16 96 13. Editor's Address...........................................16 97 14. Contributors' Addresses....................................17 98 15. Intellectual Property Statement............................18 100 1. Contributing Authors 102 The co-authors listed below contributed to the text and content of 103 this document. 105 Shane Amante, Level 3 Communications, LLC. 106 Luyuan Fang, Cisco Systems. 107 Yuji Kamite, NTT Communications Corporation. 108 Jean-Louis Le Roux, France Telecom. 109 Thomas Morin, France Telecom. 110 Vincent Parfait, Orange Business Services. 111 Lei Wang, Telenor. 113 2. Definitions 115 2.1. Acronyms 117 P2P: Point-To-Point 119 P2MP: Point-To-MultiPoint 121 MP2MP: MultiPoint-To-Multipoint 123 PE: Provider Edge router 125 P: Provider router 127 IGP: Interior Gateway Protocol 129 AS: Autonomous System 131 2.2. Terminology 133 The reader is assumed to be familiar with the terminology in 134 [RFC3031], [RFC5036], and [RFC4026]. 136 Ingress LSR: 138 Router acting as a sender of an LSP 140 Egress LSR: 142 Router acting as a receiver of an LSP 144 P2P LSP: 146 A LSP that has one unique Ingress LSR and one unique 147 Egress LSR 149 MP2P LSP: 151 A LSP that has one or more Ingress LSRs and one unique 152 Egress LSR 154 P2MP LSP: 156 A LSP that has one unique Ingress LSR and one or more 157 Egress LSRs 159 MP2MP LSP: 161 A LSP that as one or more Leaf LSRs acting indifferently as 162 Ingress or Egress LSR 164 Leaf LSR: 166 Egress LSR of a P2MP LSP or Ingress/Egress LSR of a MP2MP LSP 168 Transit LSR: 170 A LSR of a P2MP or MP2MP LSP that has one or more Downstream 171 LSRs 173 Branch LSR: 175 A LSR of a P2MP or MP2MP LSP that has more than one 176 downstream LSR 178 Bud LSR: 180 A LSR of a P2MP or MP2MP LSP that is an egress but also 181 has one or more directly connected downstream LSR(s) 183 P2MP tree: 185 The ordered set of LSRs and links that comprise the path of a 186 P2MP LSP from its ingress LSR to all of its egress LSRs. 188 3. Introduction 190 LDP [RFC5036] has been deployed for setting up point-to-point (P2P) 191 and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point 192 services in MPLS backbones. 194 There are emerging requirements for supporting delivery of point-to- 195 multipoint applications in MPLS backbones, such as those defined in 196 [RFC4834] and [L2VPN-MCAST-REQ]. 198 This requires mechanisms for setting up point-to-multipoint LSPs 199 (P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, and 200 with MPLS traffic replication at some Branch LSRs. 202 RSVP-TE extensions for setting up Point-To-Multipoint Traffic 203 Engineered LSPs (P2MP TE LSPs), have been defined in [RFC4875]. 204 They meet requirements expressed in [RFC4461]. This approach is 205 useful, in network environments where P2MP Traffic Engineering 206 capabilities are needed (Optimization, QoS, Fast recovery). 208 However for operators who want to support point-to-multipoint traffic 209 delivery on an MPLS backbone, without Traffic Engineering needs, and 210 have already deployed LDP for P2P traffic, an interesting and useful 211 approach would be to rely on LDP extensions in order to setup point- 212 to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS 213 applications and would ease the delivery of point-to-multipoint 214 services in an MPLS backbone. 216 This document focuses on the LDP approach for setting up P2MP LSPs. 217 It lists a detailed set of requirements for P2MP extensions to LDP, 218 so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. 219 These requirements should be used as guidelines when specifying LDP 220 extensions. It is intended that solutions that specify LDP procedures 221 for P2MP LSP setup, satisfy these requirements. 223 Note that generic requirements for P2MP extensions to MPLS are out of 224 the scope of this document. Rather this document describes solution 225 specific requirements related to LDP extensions in order to set up 226 P2MP LSPs. 228 Note also that other mechanisms could be used for setting up P2MP 229 LSPs, such as for instance PIM extensions, but these are out of the 230 scope of this document. The objective is not to compare these 231 mechanisms but rather to focus on the requirements for an LDP 232 extension approach. 234 The document is structured as follows: 235 - Section 4 points out the problem statement; 236 - Section 5 illustrates an application scenario; 237 - Section 6 addresses detailed requirements for P2MP LSPs; 238 - Section 7 finally discusses requirements for 239 MultiPoint-to-MultiPoint (MP2MP) LSPs. 241 4. Problem Statement and Requirements Overview 243 4.1. Problem Statement 245 LDP [RFC5036] has been deployed for setting up P2P and MP2P MPLS LSPs 246 as PE-to-PE tunnels so as to carry point-to-point traffic essentially 247 in Layer 3 and Layer 2 VPN networks. There are emerging requirements 248 for supporting multicast traffic delivery within these VPN 249 infrastructures ([RFC4834] and [L2VPN-MCAST-REQ]). For various 250 reasons, including consistency with P2P applications, and taking full 251 advantages of MPLS network infrastructure, it would be highly 252 desirable to use MPLS LSPs for the delivery of multicast traffic. 253 This could be implemented by setting up a group of P2P or MP2P LSPs, 254 but such an approach may be sub-optimal since it would result in data 255 replication at the ingress LSR, and bandwidth inefficiency (duplicate 256 data traffic within the network). Hence new mechanisms are required 257 that would allow traffic from an Ingress LSR to be efficiently 258 delivered to a number of Egress LSRs in an MPLS backbone, avoiding 259 duplicate copies of a packet on a given link. 261 Such efficient traffic delivery requires setting up P2MP LSPs. A P2MP 262 LSP is an LSP starting at an Ingress LSR, and ending on a set of one 263 or more Egress LSRs. Traffic sent by the Ingress LSR is replicated on 264 one or more Branch LSRs down to Egress LSRs. 266 RSVP-TE extensions for setting up P2MP TE LSPs, which meet 267 requirements expressed in [RFC4461], have been defined in [RFC4875]. 268 This approach is useful, in network environments where Traffic 269 Engineering capabilities are required. However, for operators that 270 deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and without 271 the need for traffic engineering, an interesting approach would be 272 using LDP extensions for setting up P2MP LSPs. 274 The following gives a set of guidelines that a specification of LDP 275 extensions for setting up P2MP LSPs should follow. 277 4.2. Requirements overview 279 The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs 280 with one Ingress LSR and one or more Egress LSRs, with traffic 281 replication at some Branch LSRs. 283 The P2MP LDP mechanism MUST allow the addition or removal of leaves 284 associated with a P2MP LSP. 286 The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and 287 inherit its capability sets from [RFC5036]. It is of paramount 288 importance that the P2MP LDP mechanism MUST NOT impede the operation 289 of existing P2P/MP2P LDP LSPs. Also the P2MP LDP mechanism MUST co- 290 exist with P2P and P2MP RSVP-TE mechanisms [RFC3209], [RFC4875]. It 291 is of paramount importance that the P2MP LDP mechanism MUST NOT 292 impede the operation of existing P2P and P2MP RSVP-TE LSPs. 294 The P2MP LDP mechanism MAY also allow setting up multipoint-to- 295 multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting 296 indifferently as Ingress LSR or Egress LSR. This may allow a 297 reduction in the amount of LDP state that needs to be maintained by a 298 LSR. 300 5. Application scenario 302 Figure 1 below illustrates an LDP enabled MPLS provider network, used 303 to carry both unicast and multicast traffic of VPN customers 304 following for instance the architecture defined in [2547-MCAST] for 305 BGP/MPLS VPNs, or the one defined in [VPLS-MCAST]. 307 In this example, a set of MP2P LDP LSPs are setup between Provider 308 Edge (PE) routers to carry unicast VPN traffic within the MPLS 309 backbone. 311 And in this example a set of P2MP LDP LSPs are setup between PE 312 routers acting as Ingress LSRs and PE routers acting as Egress LSRs, 313 so as to support multicast VPN traffic delivery within the MPLS 314 backbone. 316 For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and 317 Egress LSRs PE2, PE3, and PE4. It is used to transport multicast 318 traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it 319 replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are 320 non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3 321 and PE4 respectively. 323 PE1 324 *| *** P2MP LDP LSP 325 *| **** 326 P1-----PE2 327 */ \* 328 */ \* 329 *****/ \* **** 330 PE3----P2 P3----PE4 331 | | 332 | | 333 | | 334 PE5 PE6 336 Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4. 338 If later there are new receivers attached to PE5 and PE6, then PE5 339 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and 340 replicate traffic received from P1, to PE3 and PE5, and to PE4 and 341 PE6 respectively (see figure 2 below). 343 PE1 344 *| *** P2MP LDP LSP 345 *| **** 346 P1-----PE2 347 */ \* 348 */ \* 349 *****/ \* *** 350 PE3----P2 P3----PE4 351 *| |* 352 *| |* 353 *| |* 354 PE5 PE6 356 Figure 2: Attachment of PE5 and PE6. 358 The above example is provided for the sake of illustration. 359 Note that P2MP LSPs ingress and egress LSRs may not necessarily be PE 360 routers. Also branch LSRs may not necessarily be P routers. 362 6. Detailed Requirements 364 6.1. P2MP LSPs 366 The P2MP LDP mechanism MUST support setting up P2MP LSPs. 367 Data plane aspects related to P2MP LSPs are those already defined in 368 [RFC4461]. That is, a P2MP LSP has one Ingress LSR and one or 369 more Egress LSRs. Traffic sent by the Ingress LSR is received by all 370 Egress LSRs. The specific aspects related to P2MP LSPs is the action 371 required at a Branch LSR, where data replication occurs. 372 Incoming labelled data is appropriately replicated to several 373 outgoing interfaces which may use different labels. Only one copy of 374 a packet MUST be sent on a given link of a P2MP LSP. 376 A P2MP LSP MUST be identified by a constant and unique identifier 377 within the whole LDP domain, whatever the number of leaves, which 378 may vary dynamically. This identifier will be used so as to 379 add/remove leaves to/from the P2MP tree. 381 6.2. P2MP LSP FEC 383 As with P2P MPLS technology [RFC5036], traffic MUST be classified 384 into a FEC in this P2MP extension. All packets which belong to a 385 particular P2MP FEC and which travel from a particular node MUST use 386 the same P2MP LSP. 388 As such, a new LDP FEC that is suitable for P2MP forwarding MUST be 389 specified. 391 6.3. P2MP LDP routing 393 As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support 394 hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the 395 information maintained in LSR Routing Information Bases (RIB). 397 It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path 398 to the Ingress LSR so as to setup an MPLS shortest path tree. 400 6.4. Setting up, tearing down and modifying P2MP LSPs 402 The P2MP LDP mechanism MUST support the establishment, maintenance 403 and teardown of P2MP LSPs in a scalable manner. This MUST include 404 both the existence of a large amount of P2MP LSPs within a single 405 network and a large amount of leaf LSRs for a single P2MP LSP (see 406 also section 5.17 for scalability considerations and figures). 408 In order to scale well with a large number of leaves it is 409 RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For 410 that purpose, leaves will have to be aware of the P2MP LSP 411 identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely 412 on the applications that will use P2MP LSPs, and are out of the scope 413 of this document. 415 The P2MP LDP mechanism MUST allow the dynamic addition and removal of 416 leaves to and from a P2MP LSP, without any restriction (provided 417 there is network connectivity). It is RECOMMENDED that these 418 operations be leaf-initiated. 419 These operations MUST not impact the data transfer (packet loss, 420 duplication, delay) towards other leaves. It is RECOMMENDED that 421 these operations do not cause any additional processing except on the 422 path from the added/removed Leaf LSR to the Branch LSR. 424 6.5. Label Advertisement 426 The P2MP LDP mechanism MUST support downstream unsolicited label 427 advertisement mode. This is well suited to a leaf-initiated approach 428 and is consistent with P2P/MP2P LDP operations. 430 Other advertisement modes MAY also be supported. 432 6.6. Data Duplication 434 Data duplication refers to the receipt of multiple copies of a packet 435 by any leaf. Although this may be a marginal situation, it may also 436 be detrimental for certain applications. Hence, data duplication 437 SHOULD as much as possible be avoided, and limited to (hopefully 438 rare) transitory conditions. 440 Note, in particular, that data duplication might occur if P2MP LSP 441 rerouting is being performed (See also section 6.8). 443 6.7. Detecting and Avoiding Loops 445 The P2MP LDP extension MUST have a mechanism to detect routing loops. 446 This may rely on extensions to the LDP Loop detection mechanism 447 defined in [RFC5036]. A loop detection mechanism may require 448 recording the set of LSRs traversed on the P2MP Tree. The P2MP loop 449 avoidance mechanism MUST not impact the scalability of the P2MP LDP 450 solution. 452 The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops 453 in the data plane even during transient events. 455 Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the 456 data plane, that may trigger unexpected non-localized exponential 457 growth of traffic. 459 6.8. P2MP LSP Re-routing 461 The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in 462 the following cases: 463 - Network failure (link or node); 464 - A better path exists (e.g. new link, metric change); 465 - Planned maintenance. 467 Given that P2MP LDP routing should rely on the RIB, the achievement 468 of the following requirements also implies the underlying routing 469 protocols (IGP, etc.). 471 6.8.1. Rerouting upon Network Failure 473 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 474 of link or node failure(s), by relying upon update of the routes in 475 the RIB. The rerouting time SHOULD be minimized as much as possible 476 so as to reduce traffic disruption. 478 A mechanism MUST be defined to prevent constant P2MP LSP teardown and 479 rebuild which may be caused by the instability of a specific 480 link/node in the network. This will rely on IGP dampening but may be 481 completed by specific dampening at the LDP level. 483 6.8.2. Rerouting on a Better Path 485 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 486 a better path is created in the network, for instance as a result of 487 a metric change, a link repair, or the addition of links or nodes. 488 This will rely on update of the routes in the RIB. 490 6.8.3. Rerouting upon Planned Maintenance 492 The P2MP LDP mechanism MUST support planned maintenance operations. 493 It MUST be possible to reroute a P2MP LSP before a link/node is 494 deactivated for maintenance purposes. 495 Traffic disruption and data duplication SHOULD be minimized as much 496 as possible during such planned maintenance. 497 P2MP LSP rerouting upon planned maintenance MAY rely on a make before 498 break procedure. 500 6.9. Support for LAN interfaces 502 The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send 503 a single copy of the data onto an Ethernet LAN interface and reach 504 multiple adjacent downstream nodes. This requires that the same label 505 be negotiated with all downstream LSRs for the LSP. 507 When there are several candidate upstream LSRs on a LAN interface, 508 the P2MP LDP mechanism SHOULD provide a way for all downstream LSRs 509 of a given P2MP LSP to select the same upstream LSR, so as to avoid 510 traffic replication. In addition, the P2MP LDP mechanism SHOULD allow 511 for an efficient balancing of a set of P2MP LSPs among a set of 512 candidate upstream LSRs on a LAN interface. 514 6.10. Support for encapsulation in P2P and P2MP TE tunnels 516 The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and 517 P2MP TE tunnels. 519 The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP 520 LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a 521 single copy of the data onto the tunnel and reach all downstream LSRs 522 on the P2MP LSP, which are also Egress LSRs of the tunnel. As with 523 LAN interfaces, this requires that the same label be negotiated with 524 all downstream LSRs of the P2MP LDP LSP. 526 6.11. Label spaces 528 Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or 529 dedicated label spaces. 531 Note that dedicated label spaces will require the establishment of 532 separate P2P and P2MP LDP sessions. 534 6.12. IPv4/IPv6 support 536 The P2MP LDP mechanism MUST support the establishment of LDP sessions 537 over both IPv4 and IPv6 control planes. 539 6.13. Multi-Area/AS LSPs 541 The P2MP LDP mechanism MUST support the establishment of multi-area 542 P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP 543 area as the Ingress LSR. This SHOULD be possible without requiring 544 the advertisement of Ingress LSRs' addresses across IGP areas. 546 The P2MP LDP mechanism MUST also support the establishment of inter- 547 AS P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same AS 548 as the Ingress LSR. This SHOULD be possible without requiring the 549 advertisement of Ingress LSRs' addresses across ASes. 551 6.14. OAM 553 LDP management tools ([RFC3815], etc.) will have to be enhanced to 554 support P2MP LDP extensions. This may yield a new MIB module, which 555 may possibly be inherited from the LDP MIB. 557 Built-in diagnostic tools MUST be defined to check the connectivity, 558 trace the path and ensure fast detection of data plane failures on 559 P2MP LDP LSPs. 561 Further and precise requirements and mechanisms for P2MP MPLS OAM 562 purpose are out of the scope of this document and are addressed in 563 [RFC4687]. 565 6.15. Graceful Restart and Fault Recovery 567 LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery 568 mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs. 570 6.16. Robustness 572 A solution MUST avoid single points of failures provided there is 573 enough network connectivity. 575 6.17. Scalability 577 Scalability is a key requirement for the P2MP LDP mechanism. 578 It MUST be designed to scale well with an increase in the number of 579 any of the following: 580 - number of Leaf LSRs per P2MP LSP; 581 - number of Downstream LSRs per Branch LSR; 582 - number of P2MP LSPs per LSR. 584 In order to scale well with an increase in the number of leaves, it 585 is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one 586 particular LSP, depend only on the number of adjacent LSRs on the 587 LSP. 589 6.17.1. Orders of magnitude expected in operational networks 591 Typical orders of magnitude that we expect should be supported are: 592 - tens of thousands of P2MP trees spread out across core network 593 routers; 594 - hundreds, or a few thousands, of leaves per tree; 596 See also section 4.2 of [RFC4834]. 598 6.18. Backward Compatibility 600 In order to allow for a smooth migration, the P2MP LDP mechanism 601 SHOULD offer as much backward compatibility as possible. In 602 particular, the solution SHOULD allow the setup of a P2MP LSP along 603 non-Branch Transit LSRs that do not support P2MP LDP extensions. 605 Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms 606 and inherit its capability sets from [RFC5036]. The P2MP LDP solution 607 MUST not impede the operation of P2P/MP2P LSPs. A P2MP LDP solution 608 MUST be designed in such a way that it allows P2P/MP2P and P2MP LSPs 609 to be signalled on the same interface. 611 7. Shared Trees 613 For traffic delivery between a group of N Leaf LSRs which are acting 614 indifferently as Ingress or Egress LSRs, it may be useful to 615 setup a shared tree connecting all these LSRs, instead of having N 616 P2MP LSPs. This would reduce the amount of control and forwarding 617 state that has to be maintained on a given LSR. 619 There are actually two main options for supporting such shared trees: 621 - This could rely on the applications protocols that use LDP 622 LSPs. A shared tree could consist of the combination of a 623 MP2P LDP LSP from Leafs LSRs to a given root node, with a P2MP 624 LSP from this root to Leaf LSRs. For instance with 625 Multicast L3 VPN applications, it would be possible to build a 626 shared tree by combining (see [2547-MCAST]): 627 - a MP2P unicast LDP LSP, from each PE of the group to a 628 particular root PE acting as tree root, 629 - with a P2MP LDP LSP from this root PE to each PE of the 630 group. 632 - Or this could rely on a specific LDP mechanism allowing to 633 setup multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). 635 The former approach (Combination of MP2P and P2MP LSPs at the 636 application level) is out of the scope of this document while the 637 latter (MP2MP LSPs) belong to the scope of this document. 638 Requirements for the set up of MP2MP LSPs are listed below. 640 7.1. Requirements for MP2MP LSPs 642 A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting 643 indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf LSR 644 is received by all other Leaf LSRs of the group. 646 Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. 647 An implementation that support P2MP LDP LSPs MAY also support MP2MP 648 LDP LSP. 650 The MP2MP LDP procedures MUST not impede the operations of P2MP LSP. 652 Requirements for P2MP LSPs, set forth in section 6, apply equally to 653 MP2MP LSPs. Particular attention should be given on the below 654 requirements: 656 - The solution MUST support recovery upon link and transit node 657 failure and there MUST NOT be any single point of failure (provided 658 network connectivity is redundant); 659 - The size of MP2MP state on a LSR, for one particular MP2MP LSP, 660 SHOULD only depend on the number of adjacent LSRs on the LSP; 661 - Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that 662 may trigger exponential growth of traffic. Note that this 663 requirement is more challenging with MP2MP LSPs as a LSR can 664 receive traffic for a given LSP on multiple interfaces. 666 There are additional requirements specific to MP2MP LSPs: 668 - It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a 669 specific LSR called root LSR; 670 - It is RECOMMENDED to define several root LSRs (e.g. a primary and 671 a backup) to ensure redundancy upon root LSR failure; 672 - The receiver SHOULD not receive back a packet it has sent on the 673 MP2MP LSP; 674 - The solution SHOULD avoid that all traffic between any pair of 675 leaves is traversing a root LSR, and SHOULD as much as possible 676 minimize the distance between two leaves (similarly to PIM-Bidir 677 trees); 678 - It MUST be possible to check connectivity of a MP2MP LSP in both 679 directions. 681 8. Evaluation criteria 683 8.1. Performances 685 The solution will be evaluated with respect to the following 686 criteria: 688 (1) Time to add or remove a Leaf LSR; 689 (2) Time to repair a P2MP LSP in case of link or node 690 failure; 691 (3) Scalability (state size, number of messages, message size). 693 Particularly the P2MP LDP mechanism SHOULD be designed with as key 694 objective to minimize the additional amount of state and additional 695 processing required in the network. 697 Also, the P2MP LDP mechanism SHOULD be designed so that convergence 698 times in case of link or node failure are minimized, in order to 699 limit traffic disruption. 701 8.2. Complexity and Risks 703 The proposed solution SHOULD not introduce complexity to the current 704 LDP operations to such a degree that it would affect the stability 705 and diminish the benefits of deploying such solution. 707 9. Security Considerations 709 This document does not introduce any new security issue beyond those 710 inherent to LDP, and a P2MP LDP solution will rely on the security 711 mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature). 713 An evaluation of the security features for MPLS networks may be found 714 in [MPLS-SEC], and where issues or further work is identified by that 715 document, new security features or procedures for the MPLS protocols 716 will need to be developed. 718 10. IANA Considerations 720 This informational document makes no requests to IANA for action. 722 11. Acknowledgments 724 We would like to thank Christian Jacquenet (France Telecom), 725 Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper), Dean 726 Cheng (Cisco Systems), and Benjamin Niven-Jenkins (British Telecom), 727 for their highly useful comments and suggestions. 729 We would also like to thank authors of [RFC4461] from which some text 730 of this document has been inspired. 732 12. References 734 12.1. Normative references 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, March 1997. 739 [RFC5036] L. Andersson, I. Minei, B. Thomas, "LDP Specification", RFC 740 5036, September 2006. 742 [RFC3815] J. Cuchiarra et al. "Definitions of Managed Objects for the 743 Multiprotocol Label Switching (MPLS), Label Distribution Protocol 744 (LDP)", RFC 3815, June 2004. 746 [RFC3478] M. Leelanivas, Y. Rekhter, R. Aggarwal, "Graceful Restart 747 Mechanism for Label Distribution Protocol" RFC 3478, February 2003. 749 [RFC3479] A. Farrel, "Fault Tolerance for the Label Distribution 750 Protocol (LDP)", RFC 3479, February 2003. 752 12.2. Informative references 754 [RFC4834] T. Morin, Ed., "Requirements for Multicast in L3 755 Provider-Provisioned VPNs", RFC 4834, April 2007. 757 [L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast 758 Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls- 759 mcast-reqts, work in progress. 761 [2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP 762 IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress. 764 [VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, "VPLS Multicast" draft- 765 ietf-l2vpn-vpls-mcast, work in progress. 767 [RFC4687] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM 768 Requirements for Point-To-Multipoint MPLS Networks", RFC 4687, 769 September 2006. 771 [RFC4461] S. Yasukawa, et. al., "Requirements for Point-to-Multipoint 772 capability extension to MPLS", RFC 4461, April 2006. 774 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al., 775 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875, 776 May 2007. 778 [RFC4026] Andersson, L., Madsen, T., "PPVPN Terminology", RFC 4026, 779 March 2005. 781 [RFC3209] Awduche, D, Berger, L., Gan, D., Li, T., Srinivasan, V., 782 Swallow, G. "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, 783 December 2001. 785 13. Editor's Address 787 Jean-Louis Le Roux 788 France Telecom 789 2, avenue Pierre-Marzin 790 22307 Lannion Cedex 791 FRANCE 792 Email: jeanlouis.leroux@orange-ftgroup.com 794 14. Contributors' Addresses 796 Thomas Morin 797 France Telecom 798 2, avenue Pierre-Marzin 799 22307 Lannion Cedex 800 FRANCE 801 Email: thomas.morin@orange-ftgroup.com 803 Vincent Parfait 804 Orange Business Services 805 1041 Route des Dolines 806 Sophia Antipolis 807 06560 Valbonne 808 FRANCE 809 Email: vincent.parfait@orange-ftgroup.com 811 Luyuan Fang 812 Cisco Systems, Inc. 813 Email: lufang@cisco.com 815 Lei Wang 816 Telenor 817 Snaroyveien 30 818 Fornebu 1331 819 NORWAY 820 Email: lei.wang@telenor.com 822 Yuji Kamite 823 NTT Communications Corporation 824 Tokyo Opera City Tower 825 3-20-2 Nishi Shinjuku, Shinjuku-ku, 826 Tokyo 163-1421, 827 JAPAN 828 Email: y.kamite@ntt.com 830 Shane Amante 831 Level 3 Communications, LLC 832 1025 Eldorado Blvd 833 Broomfield, CO 80021 834 USA 835 Email: shane@level3.net 837 15. Intellectual Property Statement 839 The IETF takes no position regarding the validity or scope of any 840 Intellectual Property Rights or other rights that might be claimed to 841 pertain to the implementation or use of the technology described in 842 this document or the extent to which any license under such rights 843 might or might not be available; nor does it represent that it has 844 made any independent effort to identify any such rights. Information 845 on the procedures with respect to rights in RFC documents can be 846 found in BCP 78 and BCP 79. 848 Copies of IPR disclosures made to the IETF Secretariat and any 849 assurances of licenses to be made available, or the result of an 850 attempt made to obtain a general license or permission for the use of 851 such proprietary rights by implementers or users of this 852 specification can be obtained from the IETF on-line IPR repository at 853 http://www.ietf.org/ipr. 855 The IETF invites any interested party to bring to its attention any 856 copyrights, patents or patent applications, or other proprietary 857 rights that may cover technology that may be required to implement 858 this standard. Please address the information to the IETF at 859 ietf-ipr@ietf.org. 861 Disclaimer of Validity 863 This document and the information contained herein are provided 864 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 865 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 866 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 867 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 868 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 869 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 870 FOR A PARTICULAR PURPOSE. 872 Copyright Statement 874 Copyright (C) The IETF Trust (2007). This document is subject to the 875 rights, licenses and restrictions contained in BCP 78, and except as 876 set forth therein, the authors retain all their rights.