idnits 2.17.1 draft-ietf-mpls-mp-ldp-reqs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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: o The receiver SHOULD not receive back a packet it has sent on the MP2MP 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: 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 (November 26, 2010) is 4872 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-l2vpn-vpls-mcast-08 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS J. Le Roux, Ed. 3 Internet-Draft T. Morin 4 Intended status: Informational V. Parfait 5 Expires: May 30, 2011 France Telecom - Orange 6 L. Fang 7 Cisco 8 L. Wang 9 Telenor 10 Y. Kamite 11 NTT 12 S. Amante 13 Level3 14 November 26, 2010 16 Requirements for Point-To-Multipoint Extensions to the Label 17 Distribution Protocol 18 draft-ietf-mpls-mp-ldp-reqs-05 20 Abstract 22 This document lists a set of functional requirements for Label 23 Distribution Protocol (LDP) extensions for setting up point-to- 24 multipoint (P2MP) Label Switched Paths (LSP), in order to deliver 25 point-to-multipoint applications over a Multi Protocol Label 26 Switching (MPLS) infrastructure. It is intended that solutions that 27 specify LDP procedures for setting up P2MP LSP satisfy these 28 requirements. 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 [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 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 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on May 30, 2011. 59 Copyright Notice 61 Copyright (c) 2010 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the BSD License. 74 Table of Contents 76 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3. Problem Statement and Requirements Overview . . . . . . . . . 6 81 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 82 3.2. Requirements overview . . . . . . . . . . . . . . . . . . 7 83 4. Application scenario . . . . . . . . . . . . . . . . . . . . . 7 84 5. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9 85 5.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9 86 5.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 9 87 5.3. P2MP LDP routing . . . . . . . . . . . . . . . . . . . . . 9 88 5.4. Setting up, tearing down and modifying P2MP LSPs . . . . . 9 89 5.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10 90 5.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 10 91 5.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 10 92 5.8. P2MP LSP Re-routing . . . . . . . . . . . . . . . . . . . 11 93 5.9. Support for LAN interfaces . . . . . . . . . . . . . . . . 12 94 5.10. Support for encapsulation in P2P and P2MP TE tunnels . . . 12 95 5.11. Label spaces . . . . . . . . . . . . . . . . . . . . . . . 12 96 5.12. IPv4/IPv6 support . . . . . . . . . . . . . . . . . . . . 12 97 5.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 12 98 5.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 5.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 13 100 5.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 13 101 5.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 102 5.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14 103 6. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 14 104 6.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15 105 7. Evaluation criteria . . . . . . . . . . . . . . . . . . . . . 16 106 7.1. Performances . . . . . . . . . . . . . . . . . . . . . . . 16 107 7.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 16 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 110 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 112 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 113 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 116 1. Definitions 118 1.1. Acronyms 120 P2P: Point-To-Point 122 P2MP: Point-To-MultiPoint 124 MP2MP: MultiPoint-To-Multipoint 126 PE: Provider Edge router 128 P: Provider router 130 IGP: Interior Gateway Protocol 132 AS: Autonomous System 134 1.2. Terminology 136 The reader is assumed to be familiar with the terminology in 137 [RFC3031], [RFC5036], and [RFC4026]. 139 Ingress LSR: 140 Router acting as a sender of an LSP 142 Egress LSR: 143 Router acting as a receiver of an LSP 145 P2P LSP: 146 A LSP that has one unique Ingress LSR and one unique Egress LSR 148 MP2P LSP: 149 A LSP that has one or more Ingress LSRs and one unique Egress LSR 151 P2MP LSP: 152 A LSP that has one unique Ingress LSR and one or more Egress LSRs 154 MP2MP LSP: 155 A LSP that as one or more Leaf LSRs acting indifferently as 156 Ingress or Egress LSR 158 Leaf LSR: 159 Egress LSR of a P2MP LSP or Ingress/Egress LSR of a MP2MP LSP 161 Transit LSR: 162 A LSR of a P2MP or MP2MP LSP that has one or more Downstream LSRs 164 Branch LSR: 165 A LSR of a P2MP or MP2MP LSP that has more than one downstream LSR 167 Bud LSR: 168 A LSR of a P2MP or MP2MP LSP that is an egress but also has one or 169 more directly connected downstream LSR(s) 171 P2MP tree: 172 The ordered set of LSRs and links that comprise the path of a P2MP 173 LSP from its ingress LSR to all of its egress LSRs. 175 2. Introduction 177 LDP [RFC5036] has been deployed for setting up point-to-point (P2P) 178 and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point 179 services in MPLS backbones. 181 There are emerging requirements for supporting delivery of point-to- 182 multipoint applications in MPLS backbones, such as those defined in 183 [RFC4834] and [RFC5501]. 185 This requires mechanisms for setting up point-to-multipoint LSPs 186 (P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, 187 and with MPLS traffic replication at some Branch LSRs. 189 RSVP-TE extensions for setting up Point-To-Multipoint Traffic 190 Engineered LSPs (P2MP TE LSPs), have been defined in [RFC4875]. They 191 meet requirements expressed in [RFC4461]. This approach is useful, 192 in network environments where P2MP Traffic Engineering capabilities 193 are needed (Optimization, QoS, Fast recovery). 195 However for operators who want to support point-to-multipoint traffic 196 delivery on an MPLS backbone, without Traffic Engineering needs, and 197 have already deployed LDP for P2P traffic, an interesting and useful 198 approach would be to rely on LDP extensions in order to setup point- 199 to-multipoint (P2MP) LSPs. This would bring consistency with P2P 200 MPLS applications and would ease the delivery of point-to-multipoint 201 services in an MPLS backbone. 203 This document focuses on the LDP approach for setting up P2MP LSPs. 204 It lists a detailed set of requirements for P2MP extensions to LDP, 205 so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. 206 These requirements should be used as guidelines when specifying LDP 207 extensions. It is intended that solutions that specify LDP 208 procedures for P2MP LSP setup, satisfy these requirements. 210 Note that generic requirements for P2MP extensions to MPLS are out of 211 the scope of this document. Rather this document describes solution 212 specific requirements related to LDP extensions in order to set up 213 P2MP LSPs. 215 Note also that other mechanisms could be used for setting up P2MP 216 LSPs, such as for instance PIM extensions, but these are out of the 217 scope of this document. The objective is not to compare these 218 mechanisms but rather to focus on the requirements for an LDP 219 extension approach. 221 The document is structured as follows: 223 o Section 3 points out the problem statement; 225 o Section 4 illustrates an application scenario; 227 o Section 5 addresses detailed requirements for P2MP LSPs; 229 o Section Section 6 finally discusses requirements for shared trees 230 and MultiPoint-to-MultiPoint (MP2MP) LSPs. 232 3. Problem Statement and Requirements Overview 234 3.1. Problem Statement 236 LDP [RFC5036] has been deployed for setting up P2P and MP2P MPLS LSPs 237 as PE-to-PE tunnels so as to carry point-to-point traffic essentially 238 in Layer 3 and Layer 2 VPN networks. There are emerging requirements 239 for supporting multicast traffic delivery within these VPN 240 infrastructures ([RFC4834] and [RFC5501]). For various reasons, 241 including consistency with P2P applications, and taking full 242 advantages of MPLS network infrastructure, it would be highly 243 desirable to use MPLS LSPs for the delivery of multicast traffic. 244 This could be implemented by setting up a group of P2P or MP2P LSPs, 245 but such an approach may be sub-optimal since it would result in data 246 replication at the ingress LSR, and bandwidth inefficiency (duplicate 247 data traffic within the network). Hence new mechanisms are required 248 that would allow traffic from an Ingress LSR to be efficiently 249 delivered to a number of Egress LSRs in an MPLS backbone, avoiding 250 duplicate copies of a packet on a given link. 252 Such efficient traffic delivery requires setting up P2MP LSPs. A 253 P2MP LSP is an LSP starting at an Ingress LSR, and ending on a set of 254 one or more Egress LSRs. Traffic sent by the Ingress LSR is 255 replicated on one or more Branch LSRs down to Egress LSRs. 257 RSVP-TE extensions for setting up P2MP TE LSPs, which meet 258 requirements expressed in [RFC4461], have been defined in [RFC4875]. 259 This approach is useful, in network environments where Traffic 260 Engineering capabilities are required. However, for operators that 261 deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and without 262 the need for traffic engineering, an interesting approach would be 263 using LDP extensions for setting up P2MP LSPs. 265 The following gives a set of guidelines that a specification of LDP 266 extensions for setting up P2MP LSPs should follow. 268 3.2. Requirements overview 270 The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs 271 with one Ingress LSR and one or more Egress LSRs, with traffic 272 replication at some Branch LSRs. 274 The P2MP LDP mechanism MUST allow the addition or removal of leaves 275 associated with a P2MP LSP. 277 The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and 278 inherit its capability sets from [RFC5036]. It is of paramount 279 importance that the P2MP LDP mechanism MUST NOT impede the operation 280 of existing P2P/MP2P LDP LSPs. Also the P2MP LDP mechanism MUST co- 281 exist with P2P and P2MP RSVP-TE mechanisms [RFC3209], [RFC4875]. It 283 is of paramount importance that the P2MP LDP mechanism MUST NOT 284 impede the operation of existing P2P and P2MP RSVP-TE LSPs. 286 The P2MP LDP mechanism MAY also allow setting up multipoint-to- 287 multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting 288 indifferently as Ingress LSR or Egress LSR. This may allow a 289 reduction in the amount of LDP state that needs to be maintained by a 290 LSR. 292 4. Application scenario 294 Figure 1 below illustrates an LDP enabled MPLS provider network, used 295 to carry both unicast and multicast traffic of VPN customers 296 following for instance the architecture defined in 297 [I-D.ietf-l3vpn-2547bis-mcast] for BGP/MPLS VPNs, or the one defined 298 in [I-D.ietf-l2vpn-vpls-mcast]. 300 In this example, a set of MP2P LDP LSPs are setup between Provider 301 Edge (PE) routers to carry unicast VPN traffic within the MPLS 302 backbone. 304 And in this example a set of P2MP LDP LSPs are setup between PE 305 routers acting as Ingress LSRs and PE routers acting as Egress LSRs, 306 so as to support multicast VPN traffic delivery within the MPLS 307 backbone. 309 For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and 310 Egress LSRs PE2, PE3, and PE4. It is used to transport multicast 311 traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it 312 replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are 313 non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3 314 and PE4 respectively. 316 PE1 317 *| *** P2MP LDP LSP 318 *|***** 319 P1-----PE2 320 */ \* 321 */ \* 322 *****/ \****** 323 PE3----P2 P3----PE4 324 | | 325 | | 326 | | 327 PE5 PE6 329 Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4. 331 If later there are new receivers attached to PE5 and PE6, then PE5 332 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and 333 replicate traffic received from P1, to PE3 and PE5, and to PE4 and 334 PE6 respectively (see Figure 2 below). 336 PE1 337 *| *** P2MP LDP LSP 338 *|***** 339 P1-----PE2 340 */ \* 341 */ \* 342 *****/ \****** 343 PE3----P2 P3----PE4 344 *| |* 345 *| |* 346 *| |* 347 PE5 PE6 349 Figure 2: Attachment of PE5 and PE6. 351 The above example is provided for the sake of illustration. Note 352 that P2MP LSPs ingress and egress LSRs may not necessarily be PE 353 routers. Also branch LSRs may not necessarily be P routers. 355 5. Detailed Requirements 357 5.1. P2MP LSPs 359 The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane 360 aspects related to P2MP LSPs are those already defined in [RFC4461]. 361 That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs. 362 Traffic sent by the Ingress LSR is received by all Egress LSRs. The 363 specific aspects related to P2MP LSPs is the action required at a 364 Branch LSR, where data replication occurs. Incoming labelled data is 365 appropriately replicated to several outgoing interfaces which may use 366 different labels. Only one copy of a packet MUST be sent on a given 367 link of a P2MP LSP. 369 A P2MP LSP MUST be identified by a constant and unique identifier 370 within the whole LDP domain, whatever the number of leaves, which may 371 vary dynamically. This identifier will be used so as to add/remove 372 leaves to/from the P2MP tree. 374 5.2. P2MP LSP FEC 376 As with P2P MPLS technology [RFC5036], traffic MUST be classified 377 into a FEC in this P2MP extension. All packets which belong to a 378 particular P2MP FEC and which travel from a particular node MUST use 379 the same P2MP LSP. 381 As such, a new LDP FEC that is suitable for P2MP forwarding MUST be 382 specified. 384 5.3. P2MP LDP routing 386 As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support 387 hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the 388 information maintained in LSR Routing Information Bases (RIB). 390 It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path 391 to the Ingress LSR so as to setup an MPLS shortest path tree. 393 5.4. Setting up, tearing down and modifying P2MP LSPs 395 The P2MP LDP mechanism MUST support the establishment, maintenance 396 and teardown of P2MP LSPs in a scalable manner. This MUST include 397 both the existence of a large amount of P2MP LSPs within a single 398 network and a large amount of leaf LSRs for a single P2MP LSP (see 399 also section 5.17 for scalability considerations and figures). 401 In order to scale well with a large number of leaves it is 402 RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For 403 that purpose, leaves will have to be aware of the P2MP LSP 404 identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely 405 on the applications that will use P2MP LSPs, and are out of the scope 406 of this document. 408 The P2MP LDP mechanism MUST allow the dynamic addition and removal of 409 leaves to and from a P2MP LSP, without any restriction (provided 410 there is network connectivity). It is RECOMMENDED that these 411 operations be leaf-initiated. These operations MUST not impact the 412 data transfer (packet loss, duplication, delay) towards other leaves. 413 It is RECOMMENDED that these operations do not cause any additional 414 processing except on the path from the added/removed Leaf LSR to the 415 Branch LSR. 417 5.5. Label Advertisement 419 The P2MP LDP mechanism MUST support downstream unsolicited label 420 advertisement mode. This is well suited to a leaf-initiated approach 421 and is consistent with P2P/MP2P LDP operations. 423 Other advertisement modes MAY also be supported. 425 5.6. Data Duplication 427 Data duplication refers to the receipt of multiple copies of a packet 428 by any leaf. Although this may be a marginal situation, it may also 429 be detrimental for certain applications. Hence, data duplication 430 SHOULD as much as possible be avoided, and limited to (hopefully 431 rare) transitory conditions. 433 Note, in particular, that data duplication might occur if P2MP LSP 434 rerouting is being performed (See also section 6.8). 436 5.7. Detecting and Avoiding Loops 438 The P2MP LDP extension MUST have a mechanism to detect routing loops. 439 This may rely on extensions to the LDP Loop detection mechanism 440 defined in [RFC5036]. A loop detection mechanism may require 441 recording the set of LSRs traversed on the P2MP Tree. The P2MP loop 442 avoidance mechanism MUST not impact the scalability of the P2MP LDP 443 solution. 445 The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops 446 in the data plane even during transient events. 448 Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the 449 data plane, that may trigger unexpected non-localized exponential 450 growth of traffic. 452 5.8. P2MP LSP Re-routing 454 The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in 455 the following cases: 457 o Network failure (link or node); 459 o A better path exists (e.g. new link, metric change); 461 o Planned maintenance. 463 Given that P2MP LDP routing should rely on the RIB, the achievement 464 of the following requirements also implies the underlying routing 465 protocols (IGP, etc.). 467 5.8.1. Rerouting upon Network Failure 469 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 470 of link or node failure(s), by relying upon update of the routes in 471 the RIB. The rerouting time SHOULD be minimized as much as possible 472 so as to reduce traffic disruption. 474 A mechanism MUST be defined to prevent constant P2MP LSP teardown and 475 rebuild which may be caused by the instability of a specific link/ 476 node in the network. This will rely on IGP dampening but may be 477 completed by specific dampening at the LDP level. 479 5.8.2. Rerouting on a Better Path 481 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 482 a better path is created in the network, for instance as a result of 483 a metric change, a link repair, or the addition of links or nodes. 484 This will rely on update of the routes in the RIB. 486 5.8.3. Rerouting upon Planned Maintenance 488 The P2MP LDP mechanism MUST support planned maintenance operations. 489 It MUST be possible to reroute a P2MP LSP before a link/node is 490 deactivated for maintenance purposes. Traffic disruption and data 491 duplication SHOULD be minimized as much as possible during such 492 planned maintenance. P2MP LSP rerouting upon planned maintenance MAY 493 rely on a make before break procedure. 495 5.9. Support for LAN interfaces 497 The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send 498 a single copy of the data onto an Ethernet LAN interface and reach 499 multiple adjacent downstream nodes. This requires that the same 500 label be negotiated with all downstream LSRs for the LSP. 502 When there are several candidate upstream LSRs on a LAN interface, 503 the P2MP LDP mechanism SHOULD provide a way for all downstream LSRs 504 of a given P2MP LSP to select the same upstream LSR, so as to avoid 505 traffic replication. In addition, the P2MP LDP mechanism SHOULD 506 allow for an efficient balancing of a set of P2MP LSPs among a set of 507 candidate upstream LSRs on a LAN interface. 509 5.10. Support for encapsulation in P2P and P2MP TE tunnels 511 The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and 512 P2MP TE tunnels. 514 The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP 515 LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a 516 single copy of the data onto the tunnel and reach all downstream LSRs 517 on the P2MP LSP, which are also Egress LSRs of the tunnel. As with 518 LAN interfaces, this requires that the same label be negotiated with 519 all downstream LSRs of the P2MP LDP LSP. 521 5.11. Label spaces 523 Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or 524 dedicated label spaces. 526 Note that dedicated label spaces will require the establishment of 527 separate P2P and P2MP LDP sessions. 529 5.12. IPv4/IPv6 support 531 The P2MP LDP mechanism MUST support the establishment of LDP sessions 532 over both IPv4 and IPv6 control planes. 534 5.13. Multi-Area/AS LSPs 536 The P2MP LDP mechanism MUST support the establishment of multi-area 537 P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP 538 area as the Ingress LSR. This SHOULD be possible without requiring 539 the advertisement of Ingress LSRs' addresses across IGP areas. 541 The P2MP LDP mechanism MUST also support the establishment of 542 inter-AS P2MP LSPs, i.e. LSPs whose leaves do not all reside in the 543 same AS as the Ingress LSR. This SHOULD be possible without 544 requiring the advertisement of Ingress LSRs' addresses across ASes. 546 5.14. OAM 548 LDP management tools ([RFC3815], etc.) will have to be enhanced to 549 support P2MP LDP extensions. This may yield a new MIB module, which 550 may possibly be inherited from the LDP MIB. 552 Built-in diagnostic tools MUST be defined to check the connectivity, 553 trace the path and ensure fast detection of data plane failures on 554 P2MP LDP LSPs. 556 Further and precise requirements and mechanisms for P2MP MPLS OAM 557 purpose are out of the scope of this document and are addressed in 558 [RFC4687]. 560 5.15. Graceful Restart and Fault Recovery 562 LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery 563 mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs. 565 5.16. Robustness 567 A solution MUST avoid single points of failures provided there is 568 enough network connectivity. 570 5.17. Scalability 572 Scalability is a key requirement for the P2MP LDP mechanism. It MUST 573 be designed to scale well with an increase in the number of any of 574 the following: 576 o number of Leaf LSRs per P2MP LSP; 578 o number of Downstream LSRs per Branch LSR; 580 o number of P2MP LSPs per LSR. 582 In order to scale well with an increase in the number of leaves, it 583 is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one 584 particular LSP, depend only on the number of adjacent LSRs on the 585 LSP. 587 5.17.1. Orders of magnitude expected in operational networks 589 Typical orders of magnitude that we expect should be supported are: 591 o tens of thousands of P2MP trees spread out across core network 592 routers; 594 o hundreds, or a few thousands, of leaves per tree; 596 See also section 4.2 of [RFC4834]. 598 5.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 607 solution MUST not impede the operation of P2P/MP2P LSPs. A P2MP LDP 608 solution MUST be designed in such a way that it allows P2P/MP2P and 609 P2MP LSPs to be signalled on the same interface. 611 6. 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 setup a 615 shared tree connecting all these LSRs, instead of having N P2MP LSPs. 616 This would reduce the amount of control and forwarding state that has 617 to be maintained on a given LSR. 619 There are actually two main options for supporting such shared trees: 621 o This could rely on the applications protocols that use LDP LSPs. 622 A shared tree could consist of the combination of a MP2P LDP LSP 623 from Leafs LSRs to a given root node, with a P2MP LSP from this 624 root to Leaf LSRs. For instance with Multicast L3 VPN 625 applications, it would be possible to build a shared tree by 626 combining (see [I-D.ietf-l3vpn-2547bis-mcast]): 628 * a MP2P unicast LDP LSP, from each PE of the group to a 629 particular root PE acting as tree root, 631 * with a P2MP LDP LSP from this root PE to each PE of the group. 633 o Or this could rely on a specific LDP mechanism allowing to setup 634 multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). 636 The former approach (Combination of MP2P and P2MP LSPs at the 637 application level) is out of the scope of this document while the 638 latter (MP2MP LSPs) belong to the scope of this document. 639 Requirements for the set up of MP2MP LSPs are listed below. 641 6.1. Requirements for MP2MP LSPs 643 A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting 644 indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf 645 LSR is received by all other Leaf LSRs of the group. 647 Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. 648 An implementation that support P2MP LDP LSPs MAY also support MP2MP 649 LDP LSP. 651 The MP2MP LDP procedures MUST not impede the operations of P2MP LSP. 653 Requirements for P2MP LSPs, set forth in section 6, apply equally to 654 MP2MP LSPs. Particular attention should be given on the below 655 requirements: 657 o The solution MUST support recovery upon link and transit node 658 failure and there MUST NOT be any single point of failure 659 (provided network connectivity is redundant); 661 o The size of MP2MP state on a LSR, for one particular MP2MP LSP, 662 SHOULD only depend on the number of adjacent LSRs on the LSP; 664 o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that 665 may trigger exponential growth of traffic. Note that this 666 requirement is more challenging with MP2MP LSPs as a LSR can 667 receive traffic for a given LSP on multiple interfaces. 669 There are additional requirements specific to MP2MP LSPs: 671 o It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a 672 specific LSR called root LSR; 674 o It is RECOMMENDED to define several root LSRs (e.g. a primary and 675 a backup) to ensure redundancy upon root LSR failure; 677 o The receiver SHOULD not receive back a packet it has sent on the 678 MP2MP LSP; 680 o The solution SHOULD avoid that all traffic between any pair of 681 leaves is traversing a root LSR, and SHOULD as much as possible 682 minimize the distance between two leaves (similarly to PIM-Bidir 683 trees); 685 o It MUST be possible to check connectivity of a MP2MP LSP in both 686 directions. 688 7. Evaluation criteria 690 7.1. Performances 692 The solution will be evaluated with respect to the following 693 criteria: 695 (1) Time to add or remove a Leaf LSR; 697 (2) Time to repair a P2MP LSP in case of link or node failure; 699 (3) Scalability (state size, number of messages, message size). 701 Particularly the P2MP LDP mechanism SHOULD be designed with as key 702 objective to minimize the additional amount of state and additional 703 processing required in the network. 705 Also, the P2MP LDP mechanism SHOULD be designed so that convergence 706 times in case of link or node failure are minimized, in order to 707 limit traffic disruption. 709 7.2. Complexity and Risks 711 The proposed solution SHOULD not introduce complexity to the current 712 LDP operations to such a degree that it would affect the stability 713 and diminish the benefits of deploying such solution. 715 8. Security Considerations 717 This document does not introduce any new security issue beyond those 718 inherent to LDP, and a P2MP LDP solution will rely on the security 719 mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature). 721 An evaluation of the security features for MPLS networks may be found 722 in [RFC5920], and where issues or further work is identified by that 723 document, new security features or procedures for the MPLS protocols 724 will need to be developed. 726 9. IANA Considerations 728 This informational document makes no requests to IANA for action. 730 10. Acknowledgments 732 We would like to thank Christian Jacquenet (France Telecom), Hitoshi 733 Fukuda (NTT), Ina Minei (Juniper), Dean Cheng (Cisco), and Benjamin 734 Niven-Jenkins (BT), for their highly useful comments and suggestions. 736 We would also like to thank authors of [RFC4461] from which some text 737 of this document has been inspired. 739 11. References 741 11.1. Normative References 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, March 1997. 746 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 747 Label Switching Architecture", RFC 3031, January 2001. 749 [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful 750 Restart Mechanism for Label Distribution Protocol", 751 RFC 3478, February 2003. 753 [RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution 754 Protocol (LDP)", RFC 3479, February 2003. 756 [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions 757 of Managed Objects for the Multiprotocol Label Switching 758 (MPLS), Label Distribution Protocol (LDP)", RFC 3815, 759 June 2004. 761 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 762 Specification", RFC 5036, October 2007. 764 11.2. Informative References 766 [I-D.ietf-l2vpn-vpls-mcast] 767 Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, 768 "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work 769 in progress), October 2010. 771 [I-D.ietf-l3vpn-2547bis-mcast] 772 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 773 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 774 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work 775 in progress), January 2010. 777 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 778 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 779 Tunnels", RFC 3209, December 2001. 781 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 782 Private Network (VPN) Terminology", RFC 4026, March 2005. 784 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 785 Multipoint Traffic-Engineered MPLS Label Switched Paths 786 (LSPs)", RFC 4461, April 2006. 788 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 789 "Operations and Management (OAM) Requirements for Point- 790 to-Multipoint MPLS Networks", RFC 4687, September 2006. 792 [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 793 Provider-Provisioned Virtual Private Networks (PPVPNs)", 794 RFC 4834, April 2007. 796 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 797 "Extensions to Resource Reservation Protocol - Traffic 798 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 799 Switched Paths (LSPs)", RFC 4875, May 2007. 801 [RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, 802 "Requirements for Multicast Support in Virtual Private LAN 803 Services", RFC 5501, March 2009. 805 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 806 Networks", RFC 5920, July 2010. 808 Authors' Addresses 810 Jean-Louis (editor) 811 France Telecom - Orange 813 Email: jeanlouis.leroux@orange-ftgroup.com 815 Thomas Morin 816 France Telecom - Orange 818 Email: thomas.morin@orange-ftgroup.com 819 Vincent Parfait 820 France Telecom - Orange, Orange Business Services 822 Email: vincent.parfait@orange-ftgroup.com 824 Luyuan Fang 825 Cisco Systems, Inc. 827 Email: lufang@cisco.com 829 Lei Wang 830 Telenor 832 Email: lei.wang@telenor.com 834 Yuji Kamite 835 NTT Communications Corporation 837 Email: y.kamite@ntt.com 839 Shane Amante 840 Level 3 Communications, LLC 842 Email: shane@level3.net