idnits 2.17.1 draft-leroux-mpls-mp-ldp-reqs-03.txt: -(699): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 33. -- Found old boilerplate from RFC 3978, Section 5.5 on line 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 777. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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: Also, the P2MP LDP solution MUST interoperate seamlessly with current LDP mechanisms and inherit its capability sets from [LDP]. 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 '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 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 'SHOULD not' in this paragraph: The proposed solution SHOULD not require deploying a new routing protocol. -- 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 (February 2006) is 6644 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 660, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) Summary: 9 errors (**), 0 flaws (~~), 8 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 3 Internet Draft T. Morin 4 Category: Informational France Telecom 5 Expires: August 2006 6 Vincent Parfait 7 Equant 9 Luyuan Fang 10 AT&T 12 Lei Wang 13 Telenor 15 Yuji Kamite 16 NTT Communications 18 Shane Amante 19 Level 3 Communications 21 February 2006 23 Requirements for point-to-multipoint extensions to 24 the Label Distribution Protocol 26 draft-leroux-mpls-mp-ldp-reqs-03.txt 28 Status of this Memo 30 By submitting this Internet-Draft, each author represents that any 31 applicable patent or other IPR claims of which he or she is aware 32 have been or will be disclosed, and any of which he or she becomes 33 aware will be disclosed, in accordance with Section 6 of BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that other 37 groups may also distribute working documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet- Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Abstract 52 This document lists a set of functional requirements for Label 53 Distribution Protocol (LDP) extensions for setting up point-to- 54 multipoint (P2MP) Label Switched Paths (LSP), in order to deliver 55 point-to-multipoint applications over a Multi Protocol Label 56 Switching (MPLS) infrastructure. It is intended that solutions that 57 specify LDP procedures for setting up P2MP LSP satisfy these 58 requirements. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119. 66 Table of Contents 68 1. Terminology.................................................3 69 2. Introduction................................................4 70 3. Problem Statement and Requirements Overview.................5 71 3.1. Problem Statement...........................................5 72 3.2. Requirements overview.......................................5 73 4. Application scenario........................................6 74 5. Detailed Requirements.......................................7 75 5.1. P2MP LSPs...................................................7 76 5.2. P2MP LSP FEC................................................7 77 5.3. P2MP LDP routing............................................8 78 5.4. Setting up, tearing down and modifying P2MP LSPs............8 79 5.5. Label Advertisement.........................................8 80 5.6. Data Duplication............................................8 81 5.7. Avoiding loops..............................................9 82 5.8. P2MP LSP Re-routing.........................................9 83 5.8.1. Rerouting upon Network Failure..............................9 84 5.8.2. Rerouting on a Better Path..................................9 85 5.8.3. Rerouting upon Planned Maintenance..........................9 86 5.9. Support for LAN interfaces.................................10 87 5.10. Support for encapsulation in P2P and P2MP TE tunnels.......10 88 5.11. Label spaces...............................................10 89 5.12. IPv4/IPv6 support..........................................10 90 5.13. Multi-Area LSPs............................................11 91 5.14. OAM........................................................11 92 5.15. Graceful Restart and Fault Recovery........................11 93 5.16. Robustness.................................................11 94 5.17. Scalability................................................11 95 5.17.1. Orders of magnitude of the expected numbers of P2MP 96 LSPs in operational networks...............................12 97 5.18. Backward Compatibility.....................................12 98 6. Shared Trees...............................................12 99 6.1. MP2MP LSPs.................................................13 100 7. Evaluation criteria........................................13 101 7.1. Performances...............................................13 102 7.2. Complexity and Risks.......................................13 103 8. Security Considerations....................................13 104 9. Acknowledgments............................................14 105 10. References.................................................14 106 11. Authors' Addresses:........................................15 107 12. Intellectual Property Statement............................16 109 1. Terminology 111 LSR: Label Switching Router 113 LSP: MPLS Label Switched Path 115 Ingress LSR: Router acting as a sender of an LSP 117 Egress LSR: Router acting as a receiver of an LSP 119 P2P LSP: A LSP that has one unique Ingress LSR and one unique 120 Egress LSR 122 MP2P LSP: A LSP that has one or more Ingress LSRs and one unique 123 Egress LSR 125 P2MP LSP: A LSP that has one unique Ingress LSR and one or more 126 Egress LSRs 128 Leaf LSR: Egress LSR of a P2MP LSP 130 Transit LSR: A LSR of a P2MP LSP that has one or more downstream 131 LSRs 133 Branch LSR: A LSR of a P2MP LSP that has more than one downstream 134 LSR 136 Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or 137 more directly connected downstream LSRs 139 2. Introduction 141 Many operators have deployed LDP [LDP] for setting up point-to-point 142 (P2P) and multipoint-to-point (MP2P) LSPs, in order to offer point-to 143 -point services in MPLS backbones. 145 There are emerging requirements for supporting delivery of point-to- 146 multipoint applications in MPLS backbones, such as those defined in 147 [L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]. 149 This requires mechanisms for setting up point-to-multipoint LSPs 150 (P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, and 151 with MPLS traffic replication at some Branch LSRs. 153 RSVP-TE extensions for setting up Point-To-Multipoint Traffic 154 Engineered LSPs (P2MP TE LSPs), have been defined in [P2MP-TE-RSVP]. 155 They meet requirements expressed in [P2MP-TE-REQ]. This approach is 156 useful, in network environments where P2MP Traffic Engineering 157 capabilities are needed (Optimization, QoS, Fast recovery). 159 However for operators who want to support point-to-multipoint traffic 160 delivery on an MPLS backbone, without Traffic Engineering needs, and 161 have already deployed LDP for P2P traffic, an interesting and useful 162 approach would be to rely on LDP extensions in order to setup point- 163 to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS 164 applications and would ease the delivery of point-to-multipoint 165 applications in an MPLS backbone. 167 This document focuses on the LDP approach for setting up P2MP LSPs. 168 It lists a detailed set of requirements for P2MP extensions to LDP, 169 so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. 170 These requirements should be used as guidelines when specifying LDP 171 extensions. It is intended that solutions that specify LDP procedures 172 for P2MP LSP setup, satisfy these requirements. 174 Note that generic requirements for P2MP extensions to MPLS are out of 175 the scope of this document. Rather this document describes solution 176 specific requirements related to LDP extensions in order to set up 177 P2MP LSPs. 179 Note also that other mechanisms could be used for setting up P2MP 180 LSPs, such as for instance PIM extensions, but these are out of the 181 scope of this document. The objective is not to compare these 182 mechanisms but rather to focus on the requirements for an LDP 183 extension approach. 185 The document is structured as follows: 186 - Section 3 points out the problem statement. 187 - Section 4 illustrates an application scenario. 188 - Section 5 addresses detailed requirements. 189 - Section 6 finally discusses group communication. 191 3. Problem Statement and Requirements Overview 193 3.1. Problem Statement 195 Many operators have deployed LDP [LDP] for setting up P2P and MP2P 196 MPLS LSPs as PE-to-PE tunnels so as to carry point-to-point traffic 197 essentially in Layer 3 and Layer 2 VPN networks. 198 There are emerging requirements for supporting multicast traffic 199 delivery within these VPN infrastructures ([L3VPN-MCAST-REQ] and 200 [L2VPN-MCAST-REQ]). 201 For various reasons, including consistency with P2P applications, and 202 taking full advantages of MPLS network infrastructure, it would be 203 highly desirable to use MPLS LSPs for the delivery of multicast 204 traffic. 205 This could be implemented by setting up a group of P2P or MP2P LSPs, 206 but such an approach may be sub-optimal since it would result in data 207 replication at the ingress LSR, and bandwidth inefficiency (duplicate 208 data traffic within the network). 209 Hence new mechanisms are required that would allow traffic from an 210 Ingress LSR to be efficiently delivered to a number of Egress LSRs in 211 an MPLS backbone, avoiding duplicate copies of a packet on a given 212 link. 214 Such efficient traffic delivery requires setting up P2MP LSPs. A P2MP 215 LSPs is an LSP starting at an Ingress LSR, and ending on a set of one 216 or more Egress LSRs. Traffic sent by the Ingress LSR is replicated on 217 one or more Branch LSRs down to Egress LSRs. 219 RSVP-TE extensions for setting up P2MP TE LSPs, which meet 220 requirements expressed in [P2MP-TE-REQ], have been defined in [P2MP- 221 TE-RSVP]. This approach is useful, in network environments where 222 Traffic Engineering capabilities are required. 223 However, for operators that deployed LDP for setting up PE-to-PE 224 unicast MPLS LSPs, and without the need of traffic engineering, an 225 interesting approach would be using LDP extensions for setting up 226 P2MP LSPs. 228 The following gives a set of guidelines that a specification of LDP 229 extensions for setting up P2MP LSPs should follow. 231 3.2. Requirements overview 233 The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs 234 with one Ingress LSR and one or more egress LSRs, with traffic 235 replication at some Branch LSRs. 237 The P2MP LDP mechanism MUST allow the arbitrary addition or removal 238 of leaves associated with a P2MP LSP. 240 The P2MP LDP mechanism MUST interoperate seamlessly with existing P2P 241 and MP2P LDP mechanisms. 243 It is of paramount importance that the P2MP LDP mechanism MUST NOT 244 impede the operation of existing P2P/MP2P LSPs. 246 Note that the P2MP LDP mechanism MAY also allow setting up 247 multipoint-to-multipoint (MP2MP) LSPs connecting a group of Leaf LSRs 248 acting indifferently as Ingress LSR or Egress LSR. This may allow 249 reducing the amount of LDP state to be maintained by a LSR. Detailed 250 requirements for MP2MP LSPs are left for further study. 252 4. Application scenario 254 Figure 1 below illustrates an LDP enabled MPLS provider network, used 255 to carry both unicast and multicast traffic of VPN customers 256 following for instance the architecture defined in [2547-MCAST] for 257 BGP/MPLS VPNs, or the one defined in [VPLS-MCAST]. 259 MP2P LDP LSPs are setup between PE routers to carry unicast VPN 260 traffic. 262 A set of P2MP LDP LSPs are setup between PE routers acting as Ingress 263 LSRs and PE routers acting as Egress LSRs, so as to support multicast 264 VPN traffic delivery within the MPLS backbone. 266 For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and 267 Egress LSRs PE2, PE3, and PE4. It is used to transport multicast 268 traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it 269 replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are 270 non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3 271 and PE4 respectively. 273 PE1 274 *| *** P2MP LDP LSP 275 *| **** 276 P1-----PE2 277 */ \* 278 */ \* 279 *****/ \* **** 280 PE3----P2 P3----PE4 281 | | 282 | | 283 | | 284 PE5 PE6 286 Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4. 288 If later there are new receivers attached to PE5 and PE6, then PE5 289 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and 290 replicate traffic received from P1, to PE3 and PE5, and to PE4 and 291 PE6 respectively (see figure 2 below). 293 PE1 294 *| *** P2MP LDP LSP 295 *| **** 296 P1-----PE2 297 */ \* 298 */ \* 299 *****/ \* *** 300 PE3----P2 P3----PE4 301 *| |* 302 *| |* 303 *| |* 304 PE5 PE6 306 Figure 2: Attachment of PE5 and PE6. 308 5. Detailed Requirements 310 5.1. P2MP LSPs 312 The P2MP LDP mechanism MUST support setting up P2MP LSPs. 313 Data plane aspects related to P2MP LSPs are those already defined in 314 [P2MP-TE-REQ]. That is, a P2MP LSP has one Ingress LSR and one or 315 more Egress LSRs. Traffic sent by the Ingress LSR is received by all 316 Egress LSRs. The specific aspects related to P2MP LSPs is the action 317 required at a Branch LSR, where data replication occurs. 318 Incoming labelled data is appropriately replicated to several 319 outgoing interfaces which may use different labels. Only one copy of 320 a packet MUST be sent on a given link of a P2MP LSP. 322 A P2MP LSP MUST be identified by a constant and unique identifier 323 within the whole LDP domain, whatever the number of leaves, which 324 may vary dynamically. 325 This identifier will be used so as to add/remove leaves to/from the 326 P2MP tree. 328 5.2. P2MP LSP FEC 330 As with P2P MPLS technology [LDP], traffic MUST be classified into a 331 FEC in this P2MP extension. All packets which belong to a particular 332 P2MP FEC and which travel from a particular node MUST use the same 333 P2MP LSP. 335 As such, a solution MUST specify a FEC that is suitable for P2MP 336 forwarding. Such P2MP FEC MUST be distinguished clearly from the 337 exiting P2P FEC. 339 5.3. P2MP LDP routing 341 As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support 342 hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the 343 information maintained in LSR Routing Information Bases (RIB). 345 It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path 346 to the Ingress LSR so as to setup an MPLS shortest path tree. 348 5.4. Setting up, tearing down and modifying P2MP LSPs 350 The P2MP LDP mechanism MUST support the establishment, maintenance 351 and teardown of P2MP LSPs in a scalable manner. This MUST include 352 both the existence of a large amount of P2MP LSPs within a single 353 network and a large amount of leaf LSRs for a single P2MP LSP. 355 In order to scale well with a large number of leaves it is 356 RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For 357 that purpose, leaves will have to be aware of the P2MP LSP 358 identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely 359 on the applications that will use P2MP LSPs, and are out of the scope 360 of this document. 362 The P2MP LDP mechanism MUST allow the dynamic addition and removal of 363 leaves to and from a P2MP LSP. It is RECOMMENDED that these 364 operations be leaf-initiated. 365 It is RECOMMENDED that these operations do not cause any additional 366 processing except on the path from the added/removed Leaf LSR to 367 the Branch LSR. 369 5.5. Label Advertisement 371 The P2MP LDP mechanism SHOULD support downstream unsolicited label 372 advertisement mode. This is well suited to a leaf-initiated approach 373 and is consistent with P2P/MP2P LDP operations. 375 5.6. Data Duplication 377 Data duplication refers to the receipt of multiple copies of a packet 378 by any leaf. Although this may be a marginal situation, it may also 379 be detrimental for certain applications. Hence, data duplication 380 SHOULD be avoided as much as possible, and limited to (hopefully 381 rare) transitory conditions. 383 Note, in particular, that data duplication might occur if P2MP LSP 384 rerouting is being performed (See also section 5.8). 386 5.7. Avoiding loops 388 The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops 389 even during transient events. 391 Furthermore, the P2MP LDP mechanism MUST avoid routing loops that may 392 trigger unexpected non-localized exponential growth of traffic. Note 393 that any loop-avoidance mechanism MUST respect scalability 394 requirements. 396 5.8. P2MP LSP Re-routing 398 The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in 399 the following cases: 400 - Network failure (link or node) 401 - A better path exists (e.g. new link, metric change) 402 - Planned maintenance 404 Given that P2MP LDP routing must rely on the RIB, the achievement of 405 the following requirements also implies the underlying routing 406 protocols (IGP, etc.). 408 5.8.1. Rerouting upon Network Failure 410 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 411 of link or node failure(s). The rerouting time SHOULD be as much as 412 possible minimized so as to reduce traffic disruption. 414 A mechanism MUST be defined to prevent constant P2MP LSP teardown and 415 rebuild which may be caused by the instability of a specific 416 link/node in the network. 418 5.8.2. Rerouting on a Better Path 420 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 421 a better path is created in the network, for instance as a result of 422 a metric change, or the addition of links or nodes. 423 Traffic disruption SHOULD be as much as possible minimized during 424 such rerouting. It SHOULD be feasible to avoid packet loss during 425 such rerouting. 426 Unnecessary data duplication during such rerouting SHOULD also be as 427 much as possible minimized. 429 Note that there is likely to be a tension between packet loss 430 minimization and packet duplication minimization objectives. 432 5.8.3. Rerouting upon Planned Maintenance 434 The P2MP LDP mechanism MUST support planned maintenance operations. 435 It MUST be possible to reroute a P2MP LSP before a link/node is 436 deactivated for maintenance purposes. Traffic disruption SHOULD be as 437 much as possible minimized during such rerouting. It SHOULD be 438 feasible to avoid packet loss during such rerouting. 439 Unnecessary traffic duplication during such rerouting SHOULD also be 440 as much as possible minimized. 442 Note that there is likely to be a tension between packet loss 443 minimization and packet duplication minimization objectives. 445 5.9. Support for LAN interfaces 447 The P2MP LDP mechanism MUST provide a way for a Branch LSR to send a 448 single copy of the data onto an Ethernet LAN interface and reach 449 multiple adjacent downstream nodes. This requires that the same label 450 be negotiated will all downstream LSRs for the LSP. 452 When there are several candidate upstream LSRs on a LAN interface, 453 the P2MP LDP mechanism MUST provide a way for all downstream LSRs of 454 a given P2MP LSP to select the same upstream LSR, so as to avoid 455 traffic replication. 456 In addition, the P2MP LDP mechanism SHOULD allow for an efficient 457 balancing of a set of P2MP LSPs among a set of candidate upstream 458 LSRs on a LAN interface. 460 5.10. Support for encapsulation in P2P and P2MP TE tunnels 462 The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and 463 P2MP TE tunnels. 464 The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP 465 LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a 466 single copy of the data onto the tunnel and reach all downstream LSRs 467 on the P2MP LSP, which are also Egress LSRs of the tunnel. As with 468 LAN interfaces, this requires that the same LDP label be negotiated 469 with all downstream LSRs for the P2MP LDP LSP. 471 5.11. Label spaces 473 Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or 474 dedicated label spaces. 476 Note that dedicated label spaces will require the establishment of 477 separate P2MP LDP sessions. 479 5.12. IPv4/IPv6 support 481 The P2MP LDP mechanism MUST be equally applicable to IPv4 and IPv6 482 traffic. Likewise, it SHOULD be possible to convey both kinds of 483 traffic in a given P2MP LSP facility. 485 Also the P2MP LDP mechanism MUST support the establishment of LDP 486 sessions over both IPv4 and IPv6 control planes. 488 5.13. Multi-Area LSPs 490 The P2MP LDP mechanism MUST support the establishment of multi-area 491 P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP 492 area as the Ingress LSR. This SHOULD be possible without requiring 493 the advertisement of Ingress LSRs' addresses across IGP areas. 495 5.14. OAM 497 LDP management tools ([LDP-MIB], etc.) MUST be enhanced to support 498 P2MP LDP extensions. This may yield a new MIB module, which may 499 possibly be inherited from the LDP MIB. 501 In order to facilitate correct management, P2MP LDP LSPs MUST have 502 unique identifiers, otherwise it is impossible to determine which LSP 503 is being managed. 505 Built-in diagnostic tools MUST be defined to check the connectivity, 506 trace the path and ensure fast detection of data plane failures on 507 P2MP LDP LSPs. 509 Further and precise requirements and mechanisms for P2MP MPLS OAM 510 purpose are out of the scope of this document and are addressed in 511 [P2MP-OAM-REQ]. 513 5.15. Graceful Restart and Fault Recovery 515 LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT] 516 mechanisms SHOULD be enhanced to support P2MP LDP LSPs. 518 5.16. Robustness 520 A solution SHOULD avoid whatever single points of failures or propose 521 some technical solutions for a failover mechanism. 523 5.17. Scalability 525 Scalability is a key requirement for the P2MP LDP mechanism. 526 It MUST be designed to scale well with an increase in the number of 527 any of the following: 528 - number of Leaf LSRs per P2MP LSP 529 - number of Downstream LSRs per Branch LSR 530 - number of P2MP LSPs per LSR 532 In order to scale well with an increase in the number of leaves, it 533 is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one 534 particular LSP, depend only on the number of adjacent LSRs on the 535 LSP. 537 5.17.1. Orders of magnitude of the expected numbers of P2MP LSPs in 538 operational networks 540 Typical orders of magnitude that we expect should be supported are: 541 - tens of thousands of P2MP trees spread out across core network 542 routers 543 - hundreds, or a few thousands, of leaves per tree 545 See also section 4.2 of [L3VPN-MCAST-REQ]. 547 5.18. Backward Compatibility 549 In order to allow for a smooth migration, the P2MP LDP mechanism 550 SHOULD offer as much backward compatibility as possible. In 551 particular, the solution SHOULD allow the setup of a P2MP LSP along 552 non Branch Transit LSRs that do not support P2MP LDP extensions. 554 Also, the P2MP LDP solution MUST interoperate seamlessly with current 555 LDP mechanisms and inherit its capability sets from [LDP]. The P2MP 556 LDP solution MUST not impede the operation of P2P/MP2P LSPs. A P2MP 557 LDP solution MUST be designed in such a way that it allows P2P/MP2P 558 and P2MP LSPs to be signalled on the same interface. 560 6. Shared Trees 562 For traffic delivery between a group of N Leaf LSRs which are acting 563 indifferently as Ingress or Egress LSRs, it may be useful to 564 setup a shared tree connecting all these LSRs, instead of having N 565 P2MP LSPs. This would reduce the amount of control and forwarding 566 state that has to be maintained on a given LSR. 568 There are actually two main options for supporting such shared trees: 570 - This could rely on the applications protocols that use LDP 571 LSPs. A shared tree could consist of the combination of a 572 MP2P LDP LSP from Leafs LSRs to a given root node, with a P2MP 573 LSP from this root to all Leaf LSRs. 574 For instance with Multicast L3 VPN applications, it would be 575 possible to build a shared tree by combining: 576 - a MP2P unicast LDP LSP, from each PE of the group to a 577 particular root PE acting as tree root, 578 - with a P2MP LDP LSP from the root PE to all PEs of the 579 Group (see also [2547-MCAST]). 581 - Or this could rely on a specific LDP mechanism allowing to 582 setup multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). 584 The former approach (Combination of MP2P and P2MP LSPs at the 585 application level) is out of the scope of this document while the 586 latter (MP2MP LSPs) belong to the scope of this document. 587 Requirements for the set up of MP2MP LSPs are listed below. 589 6.1. MP2MP LSPs 591 *Editorial note: There is currently no clear analysis of the gain of 592 the MP2MP MPLS approach (with the potential impact on LDP), versus 593 using application-level shared trees. This is why the requirement for 594 MP2MP LSPs is currently optional* 596 The P2MP LDP mechanism MAY allow setting up MP2MP LSP. A MP2MP LSP is 597 a LSP connecting a group of Leaf LSRs acting indifferently as Ingress 598 or Egress LSRs. Traffic sent by any Leaf LSRs is received by all 599 other Leaf LSRs of the group. A sender LSR does not receive back the 600 traffic sent. 602 All detailed requirements for P2MP LSPs listed in section 5, apply 603 equally to MP2MP LSPs. Particularly it is RECOMMENDED that the size 604 of a MP2MP state on a LSR, for one particular MP2MP LSP, depend only 605 on the number of adjacent LSRs on the LSP, and not on the number of 606 Leaf LSRs. 608 Additional detailed requirements specific to MP2MP LSPs are left for 609 further study. 611 7. Evaluation criteria 613 7.1. Performances 615 The solution will be evaluated with respect to the following 616 criteria: 618 (1) Time to add or remove a Leaf LSR; 619 (2) Time to repair a P2MP LSP in case of link or node 620 failure; 621 (3) Scalability (state size, number of messages, message size). 623 Particularly, the P2MP LDP mechanism SHOULD be designed so that 624 convergence times in case of link or node failure are minimized, in 625 order to limit traffic disruption. 627 7.2. Complexity and Risks 629 The proposed solution SHOULD not introduce complexity to the current 630 LDP operations to such a degree that it would affect the stability 631 and diminish the benefits of deploying such P2MP LDP solution. 633 The proposed solution SHOULD not require deploying a new routing 634 protocol. 636 8. Security Considerations 638 This document does not introduce any new security issue beyond those 639 inherent to LDP, and a P2MP LDP solution may rely on the security 640 mechanisms defined in [LDP] (e.g. TCP MD5 Signature). 642 9. Acknowledgments 644 We would like to thank Christian Jacquenet (France Telecom), 645 Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper) and Dean 646 Cheng (Cisco Systems) for their highly useful comments and 647 suggestions. 649 We would also like to thank authors of [P2MP-TE-REQ] from which some 650 text of this document has been inspired. 652 10. References 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 658 3667, February 2004. 660 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 661 Technology", RFC 3979, March 2005. 663 [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, 664 "LDP Specification", RFC 3036, January 2001 666 [L3VPN-MCAST-REQ] T. Morin, Ed., "Requirements for Multicast in L3 667 Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts, work 668 in progress. 670 [L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast 671 Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls- 672 mcast-reqts, work in progress 674 [P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to- 675 Multipoint capability extension to MPLS", draft-ietf-mpls-p2mp-sig- 676 requirement, work in progress. 678 [P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.., 679 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf- 680 mpls-rsvp-te-p2mp, work in progress. 682 [LDP-MIB] J. Cuchiarra et al. "Definitions of Managed Objects for the 683 Multiprotocol Label Switching (MPLS), Label Distribution Protocol 684 (LDP)", RFC3815, June 2004. 686 [LDP-GR] M. Leelanivas, Y. Rekhter, R. Aggarwal, " Graceful Restart 687 Mechanism for Label Distribution Protocol" RFC3478, February 2003. 689 [LDP-FT] A. Farrel, " Fault Tolerance for the Label Distribution 690 Protocol (LDP)", RFC3479, February 2003. 692 [2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP 693 IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress. 695 [P2MP-OAM-REQ] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM 696 Requirements for Point-To-Multipoint MPLS Networks", draft-ietf-mpls- 697 p2mp-oam-reqs, work in progress. 699 [VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, �VPLS Multicast� draft- 700 ietf-l2vpn-vpls-mcast, work in progress. 702 11. Authors' Addresses: 704 Jean-Louis Le Roux 705 France Telecom 706 2, avenue Pierre-Marzin 707 22307 Lannion Cedex 708 FRANCE 709 Email: jeanlouis.leroux@francetelecom.com 711 Thomas Morin 712 France Telecom 713 2, avenue Pierre-Marzin 714 22307 Lannion Cedex 715 FRANCE 716 Email: thomas.morin@francetelecom.com 718 Vincent Parfait 719 EQUANT 720 1041 Route des Dolines 721 Sophia Antipolis 722 06560 Valbonne 723 FRANCE 724 Email: vincent.parfait@equant.com 726 Luyuan Fang 727 AT&T 728 200 Laurel Avenue 729 Middletown, NJ 07748 730 USA 731 Email: luyuanfang@att.com 733 Lei Wang 734 Telenor 735 Snaroyveien 30 736 Fornebu 1331 737 NORWAY 738 Email: lei.wang@telenor.com 740 Yuji Kamite 741 NTT Communications Corporation 742 Tokyo Opera City Tower 743 3-20-2 Nishi Shinjuku, Shinjuku-ku, 744 Tokyo 163-1421, 745 JAPAN 746 Email: y.kamite@ntt.com 748 Shane Amante 749 Level 3 Communications, LLC 750 1025 Eldorado Blvd 751 Broomfield, CO 80021 752 USA 753 Email: shane@level3.net 755 12. Intellectual Property Statement 757 The IETF takes no position regarding the validity or scope of any 758 Intellectual Property Rights or other rights that might be claimed to 759 pertain to the implementation or use of the technology described in 760 this document or the extent to which any license under such rights 761 might or might not be available; nor does it represent that it has 762 made any independent effort to identify any such rights. Information 763 on the procedures with respect to rights in RFC documents can be 764 found in BCP 78 and BCP 79. 766 Copies of IPR disclosures made to the IETF Secretariat and any 767 assurances of licenses to be made available, or the result of an 768 attempt made to obtain a general license or permission for the use of 769 such proprietary rights by implementers or users of this 770 specification can be obtained from the IETF on-line IPR repository at 771 http://www.ietf.org/ipr. 773 The IETF invites any interested party to bring to its attention any 774 copyrights, patents or patent applications, or other proprietary 775 rights that may cover technology that may be required to implement 776 this standard. Please address the information to the IETF at 777 ietf-ipr@ietf.org. 779 Disclaimer of Validity 781 This document and the information contained herein are provided on an 782 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 783 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 784 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 785 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 786 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 787 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 789 Copyright Statement 791 Copyright (C) The Internet Society (2006). This document is subject 792 to the rights, licenses and restrictions contained in BCP 78, and 793 except as set forth therein, the authors retain all their rights.