idnits 2.17.1 draft-ietf-mpls-mp-ldp-reqs-01.txt: -(717): 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 35. -- Found old boilerplate from RFC 3978, Section 5.5 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 808. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == 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: Also, the P2MP LDP solution MUST co-exist 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 '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 P2MP LDP 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 (July 2006) is 6467 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 688, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) Summary: 6 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: January 2007 T. Morin 6 France Telecom 8 Vincent Parfait 9 Equant 11 Luyuan Fang 12 AT&T 14 Lei Wang 15 Telenor 17 Yuji Kamite 18 NTT Communications 20 Shane Amante 21 Level 3 Communications 23 July 2006 25 Requirements for point-to-multipoint extensions to 26 the Label Distribution Protocol 28 draft-ietf-mpls-mp-ldp-reqs-01.txt 30 Status of this Memo 32 By submitting this Internet-Draft, each author represents that any 33 applicable patent or other IPR claims of which he or she is aware 34 have been or will be disclosed, and any of which he or she becomes 35 aware will be disclosed, in accordance with Section 6 of BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that other 39 groups may also distribute working documents as Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet- Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Abstract 54 This document lists a set of functional requirements for Label 55 Distribution Protocol (LDP) extensions for setting up point-to- 56 multipoint (P2MP) Label Switched Paths (LSP), in order to deliver 57 point-to-multipoint applications over a Multi Protocol Label 58 Switching (MPLS) infrastructure. It is intended that solutions that 59 specify LDP procedures for setting up P2MP LSP satisfy these 60 requirements. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC-2119. 68 Table of Contents 70 1. Terminology.................................................3 71 2. Introduction................................................4 72 3. Problem Statement and Requirements Overview.................5 73 3.1. Problem Statement...........................................5 74 3.2. Requirements overview.......................................5 75 4. Application scenario........................................6 76 5. Detailed Requirements.......................................7 77 5.1. P2MP LSPs...................................................7 78 5.2. P2MP LSP FEC................................................7 79 5.3. P2MP LDP routing............................................8 80 5.4. Setting up, tearing down and modifying P2MP LSPs............8 81 5.5. Label Advertisement.........................................8 82 5.6. Data Duplication............................................8 83 5.7. Avoiding loops..............................................9 84 5.8. P2MP LSP Re-routing.........................................9 85 5.8.1. Rerouting upon Network Failure..............................9 86 5.8.2. Rerouting on a Better Path..................................9 87 5.8.3. Rerouting upon Planned Maintenance.........................10 88 5.9. Support for LAN interfaces.................................10 89 5.10. Support for encapsulation in P2P and P2MP TE tunnels.......10 90 5.11. Label spaces...............................................10 91 5.12. IPv4/IPv6 support..........................................11 92 5.13. Multi-Area LSPs............................................11 93 5.14. OAM........................................................11 94 5.15. Graceful Restart and Fault Recovery........................11 95 5.16. Robustness.................................................11 96 5.17. Scalability................................................11 97 5.17.1. Orders of magnitude of the expected numbers of P2MP 98 LSPs in operational networks.............................12 99 5.18. Backward Compatibility.....................................12 100 6. Shared Trees...............................................12 101 6.1. Requirements for MP2MP LSPs................................13 102 7. Evaluation criteria........................................14 103 7.1. Performances...............................................14 104 7.2. Complexity and Risks.......................................14 105 8. Security Considerations....................................14 106 9. Acknowledgments............................................14 107 10. References.................................................14 108 10.1. Normative references.......................................14 109 10.2. Informative references.....................................15 110 11. Editor Address.............................................15 111 12. Contributors Addresses.....................................16 112 13. Intellectual Property Statement............................17 114 1. Terminology 116 LSR: Label Switching Router 118 LSP: MPLS Label Switched Path 120 Ingress LSR: Router acting as a sender of an LSP 122 Egress LSR: Router acting as a receiver of an LSP 124 P2P LSP: A LSP that has one unique Ingress LSR and one unique 125 Egress LSR 127 MP2P LSP: A LSP that has one or more Ingress LSRs and one unique 128 Egress LSR 130 P2MP LSP: A LSP that has one unique Ingress LSR and one or more 131 Egress LSRs 133 MP2MP LSP: A LSP that as one or more Leaf LSRs acting 134 indifferently as Ingress or Egress LSR 136 Leaf LSR: Egress LSR of a P2MP LSP or Ingress/Egress LSR of a 137 MP2MP LSP 139 Transit LSR: A LSR of a P2MP LSP that has one or more downstream 140 LSRs 142 Branch LSR: A LSR of a P2MP LSP that has more than one downstream 143 LSR 145 Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or 146 more directly connected downstream LSRs 148 2. Introduction 150 Many operators have deployed LDP [LDP] for setting up point-to-point 151 (P2P) and multipoint-to-point (MP2P) LSPs, in order to offer point-to 152 -point services in MPLS backbones. 154 There are emerging requirements for supporting delivery of point-to- 155 multipoint applications in MPLS backbones, such as those defined in 156 [L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]. 158 This requires mechanisms for setting up point-to-multipoint LSPs 159 (P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, and 160 with MPLS traffic replication at some Branch LSRs. 162 RSVP-TE extensions for setting up Point-To-Multipoint Traffic 163 Engineered LSPs (P2MP TE LSPs), have been defined in [P2MP-TE-RSVP]. 164 They meet requirements expressed in [P2MP-TE-REQ]. This approach is 165 useful, in network environments where P2MP Traffic Engineering 166 capabilities are needed (Optimization, QoS, Fast recovery). 168 However for operators who want to support point-to-multipoint traffic 169 delivery on an MPLS backbone, without Traffic Engineering needs, and 170 have already deployed LDP for P2P traffic, an interesting and useful 171 approach would be to rely on LDP extensions in order to setup point- 172 to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS 173 applications and would ease the delivery of point-to-multipoint 174 services in an MPLS backbone. 176 This document focuses on the LDP approach for setting up P2MP LSPs. 177 It lists a detailed set of requirements for P2MP extensions to LDP, 178 so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. 179 These requirements should be used as guidelines when specifying LDP 180 extensions. It is intended that solutions that specify LDP procedures 181 for P2MP LSP setup, satisfy these requirements. 183 Note that generic requirements for P2MP extensions to MPLS are out of 184 the scope of this document. Rather this document describes solution 185 specific requirements related to LDP extensions in order to set up 186 P2MP LSPs. 188 Note also that other mechanisms could be used for setting up P2MP 189 LSPs, such as for instance PIM extensions, but these are out of the 190 scope of this document. The objective is not to compare these 191 mechanisms but rather to focus on the requirements for an LDP 192 extension approach. 194 The document is structured as follows: 195 - Section 3 points out the problem statement; 196 - Section 4 illustrates an application scenario; 197 - Section 5 addresses detailed requirements for P2MP LSPs; 198 - Section 6 finally discusses group communication, and 199 requirements for MP2MP LSPs. 201 3. Problem Statement and Requirements Overview 203 3.1. Problem Statement 205 Many operators have deployed LDP [LDP] for setting up P2P and MP2P 206 MPLS LSPs as PE-to-PE tunnels so as to carry point-to-point traffic 207 essentially in Layer 3 and Layer 2 VPN networks. There are emerging 208 requirements for supporting multicast traffic delivery within these 209 VPN infrastructures ([L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]). For 210 various reasons, including consistency with P2P applications, and 211 taking full advantages of MPLS network infrastructure, it would be 212 highly desirable to use MPLS LSPs for the delivery of multicast 213 traffic. This could be implemented by setting up a group of P2P or 214 MP2P LSPs, but such an approach may be sub-optimal since it would 215 result in data replication at the ingress LSR, and bandwidth 216 inefficiency (duplicate data traffic within the network). Hence new 217 mechanisms are required that would allow traffic from an Ingress LSR 218 to be efficiently delivered to a number of Egress LSRs in an MPLS 219 backbone, avoiding duplicate copies of a packet on a given link. 221 Such efficient traffic delivery requires setting up P2MP LSPs. A P2MP 222 LSP is an LSP starting at an Ingress LSR, and ending on a set of one 223 or more Egress LSRs. Traffic sent by the Ingress LSR is replicated on 224 one or more Branch LSRs down to Egress LSRs. 226 RSVP-TE extensions for setting up P2MP TE LSPs, which meet 227 requirements expressed in [P2MP-TE-REQ], have been defined in [P2MP- 228 TE-RSVP]. This approach is useful, in network environments where 229 Traffic Engineering capabilities are required. However, for operators 230 that deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and 231 without the need for traffic engineering, an interesting approach 232 would be using LDP extensions for setting up P2MP LSPs. 234 The following gives a set of guidelines that a specification of LDP 235 extensions for setting up P2MP LSPs should follow. 237 3.2. Requirements overview 239 The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs 240 with one Ingress LSR and one or more Egress LSRs, with traffic 241 replication at some Branch LSRs. 243 The P2MP LDP mechanism MUST allow the addition or removal of leaves 244 associated with a P2MP LSP. 246 The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and 247 inherit its capability sets from [LDP]. It is of paramount importance 248 that the P2MP LDP mechanism MUST NOT impede the operation of existing 249 P2P/MP2P LSPs. 251 The P2MP LDP mechanism MAY also allow setting up multipoint-to- 252 multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting 253 indifferently as Ingress LSR or Egress LSR. This may allow a 254 reduction in the amount of LDP state that needs to be maintained by a 255 LSR. 257 4. Application scenario 259 Figure 1 below illustrates an LDP enabled MPLS provider network, used 260 to carry both unicast and multicast traffic of VPN customers 261 following for instance the architecture defined in [2547-MCAST] for 262 BGP/MPLS VPNs, or the one defined in [VPLS-MCAST]. 264 A set of MP2P LDP LSPs are setup between PE routers to carry unicast 265 VPN traffic within the MPLS backbone. 267 A set of P2MP LDP LSPs are setup between PE routers acting as Ingress 268 LSRs and PE routers acting as Egress LSRs, so as to support multicast 269 VPN traffic delivery within the MPLS backbone. 271 For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and 272 Egress LSRs PE2, PE3, and PE4. It is used to transport multicast 273 traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it 274 replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are 275 non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3 276 and PE4 respectively. 278 PE1 279 *| *** P2MP LDP LSP 280 *| **** 281 P1-----PE2 282 */ \* 283 */ \* 284 *****/ \* **** 285 PE3----P2 P3----PE4 286 | | 287 | | 288 | | 289 PE5 PE6 291 Figure 1: P2MP LSP from PE1 to PE2, PE3, PE4. 293 If later there are new receivers attached to PE5 and PE6, then PE5 294 and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and 295 replicate traffic received from P1, to PE3 and PE5, and to PE4 and 296 PE6 respectively (see figure 2 below). 298 PE1 299 *| *** P2MP LDP LSP 300 *| **** 301 P1-----PE2 302 */ \* 303 */ \* 304 *****/ \* *** 305 PE3----P2 P3----PE4 306 *| |* 307 *| |* 308 *| |* 309 PE5 PE6 311 Figure 2: Attachment of PE5 and PE6. 313 5. Detailed Requirements 315 5.1. P2MP LSPs 317 The P2MP LDP mechanism MUST support setting up P2MP LSPs. 318 Data plane aspects related to P2MP LSPs are those already defined in 319 [P2MP-TE-REQ]. That is, a P2MP LSP has one Ingress LSR and one or 320 more Egress LSRs. Traffic sent by the Ingress LSR is received by all 321 Egress LSRs. The specific aspects related to P2MP LSPs is the action 322 required at a Branch LSR, where data replication occurs. 323 Incoming labelled data is appropriately replicated to several 324 outgoing interfaces which may use different labels. Only one copy of 325 a packet MUST be sent on a given link of a P2MP LSP. 327 A P2MP LSP MUST be identified by a constant and unique identifier 328 within the whole LDP domain, whatever the number of leaves, which 329 may vary dynamically. 330 This identifier will be used so as to add/remove leaves to/from the 331 P2MP tree. 333 5.2. P2MP LSP FEC 335 As with P2P MPLS technology [LDP], traffic MUST be classified into a 336 FEC in this P2MP extension. All packets which belong to a particular 337 P2MP FEC and which travel from a particular node MUST use the same 338 P2MP LSP. 340 As such, a solution MUST specify a FEC that is suitable for P2MP 341 forwarding. Such P2MP FEC MUST be distinguished clearly from the 342 existing P2P FEC. 344 5.3. P2MP LDP routing 346 As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support 347 hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the 348 information maintained in LSR Routing Information Bases (RIB). 350 It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path 351 to the Ingress LSR so as to setup an MPLS shortest path tree. 353 5.4. Setting up, tearing down and modifying P2MP LSPs 355 The P2MP LDP mechanism MUST support the establishment, maintenance 356 and teardown of P2MP LSPs in a scalable manner. This MUST include 357 both the existence of a large amount of P2MP LSPs within a single 358 network and a large amount of leaf LSRs for a single P2MP LSP. 360 In order to scale well with a large number of leaves it is 361 RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For 362 that purpose, leaves will have to be aware of the P2MP LSP 363 identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely 364 on the applications that will use P2MP LSPs, and are out of the scope 365 of this document. 367 The P2MP LDP mechanism MUST allow the dynamic addition and removal of 368 leaves to and from a P2MP LSP, without any restriction (provided 369 there is network connectivity). It is RECOMMENDED that these 370 operations be leaf-initiated. 371 These operations MUST not impact the data transfer (packet loss, 372 duplication, delay) towards other leaves. It is RECOMMENDED that 373 these operations do not cause any additional processing except on the 374 path from the added/removed Leaf LSR to the Branch LSR. 376 5.5. Label Advertisement 378 The P2MP LDP mechanism SHOULD support downstream unsolicited label 379 advertisement mode. This is well suited to a leaf-initiated approach 380 and is consistent with P2P/MP2P LDP operations. 382 5.6. Data Duplication 384 Data duplication refers to the receipt of multiple copies of a packet 385 by any leaf. Although this may be a marginal situation, it may also 386 be detrimental for certain applications. Hence, data duplication 387 SHOULD be avoided as much as possible, and limited to (hopefully 388 rare) transitory conditions. 390 Note, in particular, that data duplication might occur if P2MP LSP 391 rerouting is being performed (See also section 5.8). 393 5.7. Avoiding loops 395 The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops 396 even during transient events. 398 Furthermore, the P2MP LDP mechanism MUST avoid routing loops that may 399 trigger unexpected non-localized exponential growth of traffic. Note 400 that any loop-avoidance mechanism MUST respect scalability 401 requirements. 403 5.8. P2MP LSP Re-routing 405 The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in 406 the following cases: 407 - Network failure (link or node); 408 - A better path exists (e.g. new link, metric change); 409 - Planned maintenance. 411 Given that P2MP LDP routing should rely on the RIB, the achievement 412 of the following requirements also implies the underlying routing 413 protocols (IGP, etc.). 415 5.8.1. Rerouting upon Network Failure 417 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 418 of link or node failure(s). The rerouting time SHOULD be minimized as 419 much as possible so as to reduce traffic disruption. 421 A mechanism MUST be defined to prevent constant P2MP LSP teardown and 422 rebuild which may be caused by the instability of a specific 423 link/node in the network. 425 5.8.2. Rerouting on a Better Path 427 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 428 a better path is created in the network, for instance as a result of 429 a metric change, a link repair, or the addition of links or nodes. 430 Traffic disruption and data duplication SHOULD be minimized as much 431 as possible during such rerouting. 432 There is actually a tension between packet loss minimization and 433 packet duplication minimization objectives. 434 It SHOULD be feasible to avoid either data duplication or packet loss 435 during such rerouting. 436 A solution MAY provide the operator with means to choose between 437 favoring avoiding packet loss at the expense of potential packet 438 duplication, and favoring avoiding duplication against packet loss. 440 5.8.3. Rerouting upon Planned Maintenance 442 The P2MP LDP mechanism MUST support planned maintenance operations. 443 It MUST be possible to reroute a P2MP LSP before a link/node is 444 deactivated for maintenance purposes. 445 Traffic disruption and data duplication SHOULD be minimized as much 446 as possible during such planned maintenance. 447 There is actually a tension between packet loss minimization and 448 packet duplication minimization objectives. 449 It SHOULD be feasible to avoid either data duplication or packet loss 450 during such rerouting. 451 A solution MAY provide the operator with means to choose between 452 favoring avoiding packet loss at the expense of packet duplication, 453 and favoring avoiding duplication against packet loss. 455 5.9. Support for LAN interfaces 457 The P2MP LDP mechanism MUST provide a way for a Branch LSR to send a 458 single copy of the data onto an Ethernet LAN interface and reach 459 multiple adjacent downstream nodes. This requires that the same label 460 be negotiated with all downstream LSRs for the LSP. 462 When there are several candidate upstream LSRs on a LAN interface, 463 the P2MP LDP mechanism MUST provide a way for all downstream LSRs of 464 a given P2MP LSP to select the same upstream LSR, so as to avoid 465 traffic replication. 466 In addition, the P2MP LDP mechanism SHOULD allow for an efficient 467 balancing of a set of P2MP LSPs among a set of candidate upstream 468 LSRs on a LAN interface. 470 5.10. Support for encapsulation in P2P and P2MP TE tunnels 472 The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and 473 P2MP TE tunnels. 474 The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP 475 LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a 476 single copy of the data onto the tunnel and reach all downstream LSRs 477 on the P2MP LSP, which are also Egress LSRs of the tunnel. As with 478 LAN interfaces, this requires that the same LDP label be negotiated 479 with all downstream LSRs for the P2MP LDP LSP. 481 5.11. Label spaces 483 Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or 484 dedicated label spaces. 486 Note that dedicated label spaces will require the establishment of 487 separate P2P and P2MP LDP sessions. 489 5.12. IPv4/IPv6 support 491 The P2MP LDP mechanism MUST be equally applicable to IPv4 and IPv6 492 traffic. Likewise, it SHOULD be possible to convey both kinds of 493 traffic in a given P2MP LSP facility. 495 Also the P2MP LDP mechanism MUST support the establishment of LDP 496 sessions over both IPv4 and IPv6 control planes. 498 5.13. Multi-Area LSPs 500 The P2MP LDP mechanism MUST support the establishment of multi-area 501 P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP 502 area as the Ingress LSR. This SHOULD be possible without requiring 503 the advertisement of Ingress LSRs' addresses across IGP areas. 505 5.14. OAM 507 LDP management tools ([LDP-MIB], etc.) MUST be enhanced to support 508 P2MP LDP extensions. This may yield a new MIB module, which may 509 possibly be inherited from the LDP MIB. 511 In order to facilitate correct management, P2MP LDP LSPs MUST have 512 unique identifiers, otherwise it is impossible to determine which LSP 513 is being managed. 515 Built-in diagnostic tools MUST be defined to check the connectivity, 516 trace the path and ensure fast detection of data plane failures on 517 P2MP LDP LSPs. 519 Further and precise requirements and mechanisms for P2MP MPLS OAM 520 purpose are out of the scope of this document and are addressed in 521 [P2MP-OAM-REQ]. 523 5.15. Graceful Restart and Fault Recovery 525 LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT] 526 mechanisms SHOULD be enhanced to support P2MP LDP LSPs. 528 5.16. Robustness 530 A solution MUST avoid single points of failures provided there is 531 enough network connectivity. 533 5.17. Scalability 535 Scalability is a key requirement for the P2MP LDP mechanism. 536 It MUST be designed to scale well with an increase in the number of 537 any of the following: 538 - number of Leaf LSRs per P2MP LSP; 539 - number of Downstream LSRs per Branch LSR; 540 - number of P2MP LSPs per LSR. 542 In order to scale well with an increase in the number of leaves, it 543 is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one 544 particular LSP, depend only on the number of adjacent LSRs on the 545 LSP. 547 5.17.1. Orders of magnitude of the expected numbers of P2MP LSPs in 548 operational networks 550 Typical orders of magnitude that we expect should be supported are: 551 - tens of thousands of P2MP trees spread out across core network 552 routers; 553 - hundreds, or a few thousands, of leaves per tree; 555 See also section 4.2 of [L3VPN-MCAST-REQ]. 557 5.18. Backward Compatibility 559 In order to allow for a smooth migration, the P2MP LDP mechanism 560 SHOULD offer as much backward compatibility as possible. In 561 particular, the solution SHOULD allow the setup of a P2MP LSP along 562 non-Branch Transit LSRs that do not support P2MP LDP extensions. 564 Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms 565 and inherit its capability sets from [LDP]. The P2MP LDP solution 566 MUST not impede the operation of P2P/MP2P LSPs. A P2MP LDP solution 567 MUST be designed in such a way that it allows P2P/MP2P and P2MP LSPs 568 to be signalled on the same interface. 570 6. Shared Trees 572 For traffic delivery between a group of N Leaf LSRs which are acting 573 indifferently as Ingress or Egress LSRs, it may be useful to 574 setup a shared tree connecting all these LSRs, instead of having N 575 P2MP LSPs. This would reduce the amount of control and forwarding 576 state that has to be maintained on a given LSR. 578 There are actually two main options for supporting such shared trees: 580 - This could rely on the applications protocols that use LDP 581 LSPs. A shared tree could consist of the combination of a 582 MP2P LDP LSP from Leafs LSRs to a given root node, with a P2MP 583 LSP from this root to all Leaf LSRs. For instance with 584 Multicast L3 VPN applications, it would be possible to build a 585 shared tree by combining: 586 - a MP2P unicast LDP LSP, from each PE of the group to a 587 particular root PE acting as tree root, 588 - with a P2MP LDP LSP from this root PE to each PEs of the 589 Group. 591 - Or this could rely on a specific LDP mechanism allowing to 592 setup multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). 594 The former approach (Combination of MP2P and P2MP LSPs at the 595 application level) is out of the scope of this document while the 596 latter (MP2MP LSPs) belong to the scope of this document. 597 Requirements for the set up of MP2MP LSPs are listed below. 599 6.1. Requirements for MP2MP LSPs 601 A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting 602 indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf 603 LSRs is received by all other Leaf LSRs of the group. 605 Procedures for setting up MP2MP LSPs SHOULD be specified. 606 An implementation that support P2MP LDP LSPs MAY also support MP2MP 607 LDP LSP. 609 The MP2MP LDP procedures MUST not impede the operations of P2MP LSP. 611 Requirements for P2MP LSPs set forth in section 5 apply equally to 612 MP2MP LSPs. Particular attention should be given on the below 613 requirements: 615 - The solution MUST support recovery upon link and transit node 616 failure and there MUST be no single point of failure (provided 617 network connectivity is redundant). Note that transit node 618 failure recovery is likely to be more complex to handle with MP2MP 619 LSPs than with P2MP LSPs; 620 - The size of MP2MP state on a LSR, for one particular MP2MP LSP, 621 SHOULD only depend on the number of adjacent LSRs on the LSP; 622 - Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that 623 may trigger exponential growth of traffic. Note that this 624 requirement is more challenging with MP2MP LSPs as a LSR can 625 receive traffic for a given LSP on multiple interfaces. 627 There are additional requirements specific to MP2MP LSPs: 629 - It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a 630 specific LSR called root LSR; 631 - It is RECOMMENDED to define several root LSRs (e.g. a primary and 632 a backup) to ensure redundancy upon root LSR failure; 633 - The receiver SHOULD not receive back a packet it has sent on the 634 MP2MP LSP; 635 - The solution SHOULD avoid that all traffic between any pair of 636 leaves is traversing a root LSR, and SHOULD as much as possible 637 minimize the distance between two leaves (similarly to PIM-Bidir 638 trees); 639 - It MUST be possible to check connectivity of a MP2MP LSP in both 640 directions. 642 7. Evaluation criteria 644 7.1. Performances 646 The solution will be evaluated with respect to the following 647 criteria: 649 (1) Time to add or remove a Leaf LSR; 650 (2) Time to repair a P2MP LSP in case of link or node 651 failure; 652 (3) Scalability (state size, number of messages, message size). 654 Particularly the P2MP LDP mechanism SHOULD be designed with as key 655 objective to minimize the additional amount of state and additional 656 processing required in the network when deploying P2MP LDP. 658 Also, the P2MP LDP mechanism SHOULD be designed so that convergence 659 times in case of link or node failure are minimized, in order to 660 limit traffic disruption. 662 7.2. Complexity and Risks 664 The proposed solution SHOULD not introduce complexity to the current 665 LDP operations to such a degree that it would affect the stability 666 and diminish the benefits of deploying such P2MP LDP solution. 668 8. Security Considerations 670 This document does not introduce any new security issue beyond those 671 inherent to LDP, and a P2MP LDP solution may rely on the security 672 mechanisms defined in [LDP] (e.g. TCP MD5 Signature). 674 9. Acknowledgments 676 We would like to thank Christian Jacquenet (France Telecom), 677 Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper), Dean 678 Cheng (Cisco Systems), and Benjamin Niven-Jenkins (British Telecom), 679 for their highly useful comments and suggestions. 681 We would also like to thank authors of [P2MP-TE-REQ] from which some 682 text of this document has been inspired. 684 10. References 686 10.1. Normative references 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, March 1997. 691 [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, 692 "LDP Specification", RFC 3036, January 2001 694 [LDP-MIB] J. Cuchiarra et al. "Definitions of Managed Objects for the 695 Multiprotocol Label Switching (MPLS), Label Distribution Protocol 696 (LDP)", RFC3815, June 2004. 698 [LDP-GR] M. Leelanivas, Y. Rekhter, R. Aggarwal, " Graceful Restart 699 Mechanism for Label Distribution Protocol" RFC3478, February 2003. 701 [LDP-FT] A. Farrel, " Fault Tolerance for the Label Distribution 702 Protocol (LDP)", RFC3479, February 2003. 704 10.2. Informative references 706 [L3VPN-MCAST-REQ] T. Morin, Ed., "Requirements for Multicast in L3 707 Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts, work 708 in progress. 710 [L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast 711 Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls- 712 mcast-reqts, work in progress. 714 [2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP 715 IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress. 717 [VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, �VPLS Multicast� draft- 718 ietf-l2vpn-vpls-mcast, work in progress. 720 [P2MP-OAM-REQ] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM 721 Requirements for Point-To-Multipoint MPLS Networks", draft-ietf-mpls- 722 p2mp-oam-reqs, work in progress. 724 [P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to- 725 Multipoint capability extension to MPLS", RFC4461, April 2006. 727 [P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.., 728 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf- 729 mpls-rsvp-te-p2mp, work in progress. 731 11. Editor Address 733 Jean-Louis Le Roux 734 France Telecom 735 2, avenue Pierre-Marzin 736 22307 Lannion Cedex 737 FRANCE 738 Email: jeanlouis.leroux@orange-ft.com 740 12. Contributors Addresses 742 Thomas Morin 743 France Telecom 744 2, avenue Pierre-Marzin 745 22307 Lannion Cedex 746 FRANCE 747 Email: thomas.morin@orange-ft.com 749 Vincent Parfait 750 EQUANT 751 1041 Route des Dolines 752 Sophia Antipolis 753 06560 Valbonne 754 FRANCE 755 Email: vincent.parfait@orange-ft.com 757 Luyuan Fang 758 AT&T 759 200 Laurel Avenue 760 Middletown, NJ 07748 761 USA 762 Email: luyuanfang@att.com 764 Lei Wang 765 Telenor 766 Snaroyveien 30 767 Fornebu 1331 768 NORWAY 769 Email: lei.wang@telenor.com 771 Yuji Kamite 772 NTT Communications Corporation 773 Tokyo Opera City Tower 774 3-20-2 Nishi Shinjuku, Shinjuku-ku, 775 Tokyo 163-1421, 776 JAPAN 777 Email: y.kamite@ntt.com 779 Shane Amante 780 Level 3 Communications, LLC 781 1025 Eldorado Blvd 782 Broomfield, CO 80021 783 USA 784 Email: shane@level3.net 786 13. Intellectual Property Statement 788 The IETF takes no position regarding the validity or scope of any 789 Intellectual Property Rights or other rights that might be claimed to 790 pertain to the implementation or use of the technology described in 791 this document or the extent to which any license under such rights 792 might or might not be available; nor does it represent that it has 793 made any independent effort to identify any such rights. Information 794 on the procedures with respect to rights in RFC documents can be 795 found in BCP 78 and BCP 79. 797 Copies of IPR disclosures made to the IETF Secretariat and any 798 assurances of licenses to be made available, or the result of an 799 attempt made to obtain a general license or permission for the use of 800 such proprietary rights by implementers or users of this 801 specification can be obtained from the IETF on-line IPR repository at 802 http://www.ietf.org/ipr. 804 The IETF invites any interested party to bring to its attention any 805 copyrights, patents or patent applications, or other proprietary 806 rights that may cover technology that may be required to implement 807 this standard. Please address the information to the IETF at 808 ietf-ipr@ietf.org. 810 Disclaimer of Validity 812 This document and the information contained herein are provided on an 813 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 814 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 815 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 816 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 817 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 818 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 820 Copyright Statement 822 Copyright (C) The Internet Society (2006). This document is subject 823 to the rights, licenses and restrictions contained in BCP 78, and 824 except as set forth therein, the authors retain all their rights.