idnits 2.17.1 draft-leroux-mpls-mp-ldp-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 33. -- Found old boilerplate from RFC 3978, Section 5.5 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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 Internet-Drafts being working documents. ** 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 are 2 instances 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 'SHOULD not' in this paragraph: In order to scale well with a large number of leaves it is RECOMMENDED to follow a leaf-initiated MP LSP setup approach. For that purpose, leaves will have to be aware of the P2MP LSP identifier. The way a Leaf LSR discovers P2MP LSPs identifiers SHOULD not be part of P2MP LDP extensions. Instead this SHOULD be part of the applications that will use P2MP LSPs, and it is out of the scope of this document. == 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. -- 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 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MPLS-UPSTREAM' is mentioned on line 312, but not defined == Missing Reference: 'RFC3036' is mentioned on line 319, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'UPSTREAM-LABEL' is mentioned on line 415, but not defined == Unused Reference: 'RFC2119' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'MPLS-UPSTREAM-LABEL' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'LDP-MIB' is defined on line 595, 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) == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-ppvpn-mcast-reqts-01 == Outdated reference: A later version (-01) exists of draft-kamite-l2vpn-vpls-mcast-reqts-00 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-p2mp-sig-requirement-03 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-02 == Outdated reference: A later version (-01) exists of draft-raggarwa-mpls-upstream-label-00 == Outdated reference: A later version (-01) exists of draft-yasukawa-mpls-p2mp-oam-reqs-00 Summary: 12 errors (**), 0 flaws (~~), 19 warnings (==), 7 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: January 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 July 2005 23 Requirements for point-to-multipoint extensions to 24 the Label Distribution Protocol 26 draft-leroux-mpls-mp-ldp-reqs-01.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 This document is an Internet-Draft and is in full conformance with 36 all provisions of Section 10 of RFC2026. Internet-Drafts are working 37 documents of the Internet Engineering Task Force (IETF), its areas, 38 and its working groups. Note that other groups may also distribute 39 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.......................................6 75 4. Application scenarios.......................................6 76 5. Detailed Requirements.......................................6 77 5.1. P2MP LSPs...................................................6 78 5.2. P2MP LSP FEC................................................6 79 5.3. Setting up, tearing down and modifying P2MP LSPs............7 80 5.4. Label Advertisement.........................................7 81 5.5. Data Duplication............................................8 82 5.6. Avoiding loops..............................................8 83 5.7. P2MP LSP routing............................................8 84 5.8. P2MP LSP Re-routing.........................................8 85 5.8.1. Rerouting on a Better Path..................................8 86 5.8.2. Rerouting upon Network Failure..............................9 87 5.8.3. Rerouting upon Planned Maintenance..........................9 88 5.9. Support for LAN interfaces..................................9 89 5.10. Support for encapsulation in P2P and P2MP TE tunnels........9 90 5.11. Label spaces................................................9 91 5.12. IPv4/IPv6 support..........................................10 92 5.13. Multi-Area LSPs............................................10 93 5.14. OAM........................................................10 94 5.15. Graceful Restart and Fault Recovery........................10 95 5.16. Robustness.................................................10 96 5.17. Scalability................................................11 97 5.17.1. Orders of magnitude of the expected numbers of P2MP 98 LSPs and leaves per LSP in operational networks..........11 99 5.18. Backward Compatibility.....................................11 100 6. Shared Trees...............................................11 101 7. Evaluation criteria........................................12 102 7.1. Performances...............................................12 103 7.2. Complexity and Risks.......................................12 104 8. Security Considerations....................................12 105 9. Acknowledgments............................................12 106 10. References.................................................12 107 11. Authors' Addresses:........................................14 108 12. Intellectual Property Statement............................15 110 1. Terminology 112 LSR: Label Switching Router 114 LSP: MPLS Label Switched Path 116 Ingress LSR: Router acting as a sender of an LSP 118 Egress LSR: Router acting as a receiver of an LSP 120 P2P LSP: A LSP that has one unique Ingress LSR and one unique 121 Egress LSR 123 MP2P LSP: A LSP that has one or more Ingress LSRs and one unique 124 Egress LSR 126 P2MP LSP: A LSP that has one unique Ingress LSR and one or more 127 Egress LSRs 129 Leaf LSR: Egress LSR of a P2MP LSP 131 Transit LSR: A LSR of a P2MP LSP that has one or more downstream 132 LSRs 134 Branch LSR: A LSR of a P2MP LSP that has more than one downstream 135 LSRs 137 Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or 138 more directly connected downstream LSRs 140 2. Introduction 142 Many operators have deployed LDP [LDP] for setting up point-to-point 143 (P2P) and multipoint-to-point (MP2P) LSPs, in order to offer point-to 144 -point services in MPLS backbones. 146 There are emerging requirements for supporting delivery of point-to- 147 multipoint applications in MPLS backbones, such as those defined in 148 [L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]. 150 An interesting and useful approach for operators who want to support 151 point-to-multipoint traffic delivery on an MPLS backbone and have 152 already deployed LDP for P2P traffic would be to rely on LDP 153 extensions in order to setup point-to-multipoint (P2MP) LSPs. This 154 would bring consistency with P2P MPLS applications and would ease the 155 delivery of point-to-multipoint applications in an MPLS backbone. 157 This document lists a set of requirements for LDP extensions, for 158 setting up P2MP LSPs, so as to deliver P2MP traffic over a MPLS 159 infrastructure. 160 It is intended that solutions that specify LDP procedures for P2MP 161 LSP setup, satisfy these requirements. 163 Note that generic requirements for P2MP extensions to MPLS are out of 164 the scope of this document. Rather this document describes solution 165 specific requirements related to LDP extensions in order to set up 166 P2MP LSPs. 168 Other mechanisms could be used for setting up P2MP LSPs, such as for 169 instance PIM extensions, but these are out of the scope of this 170 document. The objective is not to compare these mechanisms but rather 171 to focus on the requirements for an LDP extension approach. 173 Section 3 points out the problem statement. Section 4 illustrates 174 application scenarios. Finally section 5 addresses detailed 175 requirements. 177 3. Problem Statement and Requirements Overview 179 3.1. Problem Statement 181 Many operators have deployed LDP [LDP] for setting up P2P and MP2P 182 MPLS LSPs as PE-to-PE tunnels so as to carry point-to-point traffic 183 essentially in Layer 3 and Layer 2 VPN networks. 184 There are emerging requirements for supporting multicast traffic 185 delivery within these VPN infrastructures ([L3VPN-MCAST-REQ] and 186 [L2VPN-MCAST-REQ]). 187 For various reasons, including consistency with P2P applications, and 188 taking full advantages of MPLS network infrastructure, it would be 189 highly desirable to use MPLS LSPs for the delivery of multicast 190 traffic. 191 This could be implemented by setting up a group of P2P or MP2P LSPs, 192 but such an approach may be sub-optimal since it would result in data 193 replication at the ingress LSR, and bandwidth inefficiency (duplicate 194 data traffic within the network). 195 Hence new mechanisms are required that would allow traffic from an 196 Ingress LSR to be efficiently delivered to a number of Egress LSRs in 197 an MPLS backbone, avoiding duplicate copies of a packet on a given 198 link. 200 Such efficient traffic delivery requires setting up P2MP LSPs. A P2MP 201 LSPs is an LSP starting at an Ingress LSR, and ending on a set of one 202 or more Egress LSRs. Traffic sent by the Ingress LSR is replicated on 203 one or more Branch LSRs down to Egress LSRs. 205 RSVP-TE extensions for setting up P2MP TE LSPs, which meet 206 requirements expressed in [P2MP-TE-REQ], have been defined in [P2MP- 207 TE-RSVP]. This approach is useful, in network environments where 208 Traffic Engineering capabilities are required. 209 However, for operators that deployed LDP for setting up PE-to-PE 210 unicast MPLS LSPs, and without the need of traffic engineering, an 211 interesting approach would be using LDP extensions for setting up 212 P2MP LSPs. 214 Note that there are other alternatives for setting up P2MP (e.g. PIM 215 extensions defined in [PIM-MPLS]), that could be useful in various 216 situations. These are out of the scope of this document. 218 This document focuses on the LDP approach for setting up P2MP LSPs. 219 The following gives a set of guidelines that a specification of LDP 220 extensions for setting up P2MP LSPs should follow. 222 3.2. Requirements overview 224 The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs 225 with one Ingress LSR and one or more egress LSRs, with traffic 226 replication at some Branch LSRs. 228 The P2MP LDP mechanism MUST allow the arbitrary addition or removal 229 of leaves associated with a P2MP LSP. 231 The P2MP LDP mechanism MUST interoperate seamlessly with existing P2P 232 and MP2P LDP mechanisms. 233 It is of paramount importance that the P2MP LDP mechanism MUST NOT 234 impede the operation of existing P2P/MP2P LSPs. 236 Note that the P2MP LDP mechanism MAY also allow setting up 237 multipoint-to-multipoint (MP2MP) LSPs connecting a group of Leaf LSRs 238 acting indifferently as Ingress LSR or Egress LSR. This may allow 239 reducing the amount of LDP state to be maintained by a LSR. Detailed 240 requirements for MP2MP LSPs are left for further study. 242 4. Application scenarios 244 To be completed in next revision 246 5. Detailed Requirements 248 5.1. P2MP LSPs 250 The P2MP LDP mechanism MUST support setting up P2MP LSPs. 252 A P2MP LSP has one Ingress LSR and one or more Egress LSRs. Traffic 253 sent by the Ingress LSR is received by all Egress LSRs. The specific 254 aspects related to P2MP LSP is the action required at 255 a Branch LSR, where data replication occurs. Incoming labelled data 256 is appropriately replicated to several outgoing interfaces which may 257 use different labels. Only one copy of a packet MUST be sent on a 258 given link of a P2MP LSP. 260 A P2MP LSP MUST be identified by a constant and unique identifier 261 within the whole LDP domain, whatever the number of leaves, which 262 may vary dynamically. 263 This identifier will be used so as to add/remove leaves to/from the 264 P2MP tree. 266 5.2. P2MP LSP FEC 268 As with P2P MPLS technology [LDP], traffic MUST be classified into a 269 FEC in this P2MP extension. All packets which belong to a particular 270 P2MP FEC and which travel from a particular node MUST use the same 271 P2MP LSP. 273 As such, a solution MUST specify a FEC that is suitable for P2MP 274 forwarding. Such P2MP FEC MUST be distinguished clearly from the 275 exiting P2P/MP2P FEC. 277 5.3. Setting up, tearing down and modifying P2MP LSPs 279 The P2MP LDP mechanism MUST support the establishment, maintenance 280 and teardown of P2MP LSPs in a scalable manner. This MUST include 281 both the existence of a large amount of P2MP LSPs within a single 282 network and a large amount of leaf LSRs for a single P2MP LSP. 284 In order to scale well with a large number of leaves it is 285 RECOMMENDED to follow a leaf-initiated MP LSP setup approach. For 286 that purpose, leaves will have to be aware of the P2MP LSP 287 identifier. The way a Leaf LSR discovers P2MP LSPs identifiers SHOULD 288 not be part of P2MP LDP extensions. Instead this SHOULD be part of 289 the applications that will use P2MP LSPs, and it is out of the scope 290 of this document. 292 The P2MP LDP mechanism MUST allow the dynamic addition and removal of 293 leaves to and from a P2MP LSP. It is RECOMMENDED that these 294 operations be leaf-initiated. 295 It is RECOMMENDED that these operations do not cause any additional 296 processing except on the path from the Branch LSR to the added or 297 removed Leaf LSR. 299 5.4. Label Advertisement 301 The P2MP LDP mechanism SHOULD support downstream unsolicited label 302 advertisement mode. This is well suited to a leaf-initiated approach 303 and is consistent with P2P/MP2P LDP operations. 305 In order to follow a leaf initiated LSP setup approach, the P2MP LDP 306 mechanism SHOULD support the Ordered label distribution control mode. 307 Note that the Independent control mode is not relevant in a P2MP 308 context, because the upstream LSRs cannot distribute labels 309 independently like P2P/MP2P LDP, they must wait for label 310 distribution from downstream LSRs. 312 Upstream label allocation ([MPLS-UPSTREAM]) may be particularly 313 useful to avoid packet replication on LAN interfaces of a P2MP LSP, 314 or when encapsulating the P2MP LSP into a P2MP TE tunnel. 316 Hence the P2MP LDP mechanism SHOULD also support upstream solicited 317 label advertisement mode, where the solicitation is made by the 318 downstream LSR, but the label is assigned by the upstream LSR. 319 Note that the existing base LDP specification [RFC3036] does not 320 specify upstream solicited label advertisement. Hence specific 321 extensions SHOULD be defined. 323 5.5. Data Duplication 325 Data duplication refers to the receipt of multiple copies of a packet 326 by any leaf. Although this may be a marginal situation, it may also 327 be detrimental for certain applications. Hence, data duplication 328 SHOULD be avoided as much as possible, and limited to (hopefully 329 rare) transitory conditions. 331 Note, in particular, that data duplication might occur if P2MP LSP 332 rerouting is being performed (See also section 5.6). 334 5.6. Avoiding loops 336 The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops 337 even during transient events. Furthermore, the P2MP LDP mechanism 338 MUST avoid routing loops that may trigger unexpected non-localized 339 exponential growth of traffic. Note that any loop-avoidance mechanism 340 MUST respect scalability requirements. 342 5.7. P2MP LSP routing 344 As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support 345 hop-by-hop LSP routing. P2MP LSP LDP-based routing SHOULD rely upon 346 the information maintained in LSR Routing Information Bases (RIB). 347 For instance, P2MP LSP routing could rely upon a shortest path to the 348 Ingress LSR. Note that unlike P2P/MP2P LDP routing, Equal Cost Multi 349 Path (ECMP) MUST be avoided with P2MP LDP routing. 351 5.8. P2MP LSP Re-routing 353 The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in 354 the following cases: 355 -A better path exists (e.g. new link, metric change) 356 -Network failure (link or node) 357 -Planned maintenance 359 5.8.1. Rerouting on a Better Path 361 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 362 a better path is created in the network, for instance as a result of 363 a metric change, or the addition of links or nodes. 364 Traffic disruption MUST be minimized during such rerouting. It is 365 RECOMMENDED that devices perform make-before-break for traffic on 366 P2MP LSP�s to minimize traffic disruption. 367 It SHOULD be feasible to avoid packet loss during such rerouting. 368 Unnecessary data duplication during such rerouting MUST also be 369 minimized. 371 5.8.2. Rerouting upon Network Failure 373 The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case 374 of link or node failure(s). The rerouting time SHOULD be minimized as 375 much as possible so as to reduce traffic disruption. 377 A mechanism MUST be defined to prevent constant P2MP LSP teardown and 378 rebuild which may be caused by the instability of a specific 379 link/node in the network. 381 5.8.3. Rerouting upon Planned Maintenance 383 The P2MP LDP mechanism MUST support planned maintenance operations. 384 It SHOULD be possible to reroute a P2MP LSP before a link/node is 385 deactivated for maintenance purposes. Traffic disruption MUST be 386 minimized during such rerouting. It SHOULD be feasible to avoid 387 packet loss during such rerouting. 388 Unnecessary traffic duplication during such rerouting MUST also be 389 minimized. 391 5.9. Support for LAN interfaces 393 The P2MP LDP mechanism MUST provide a way for a Branch LSR to send a 394 single copy of the data onto an Ethernet LAN interface and reach 395 multiple adjacent downstream nodes. This requires that the same label 396 be negotiated will all downstream LSRs for the LSP. In order to ease 397 such negotiation an upstream label allocation approach may be used. 399 5.10. Support for encapsulation in P2P and P2MP TE tunnels 401 The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and 402 P2MP TE tunnels. 403 The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP 404 LPS, which is also a Head End LSR of a P2MP TE tunnel, to send a 405 single copy of the data onto the tunnel and reach all downstream LSRs 406 on the P2MP LSP, which are also Egress LSRs of the tunnel. As with 407 LAN interfaces, this requires that the same LDP label be negotiated 408 with all downstream LSRs for the P2MP LDP LSP. In order to ease such 409 negotiation, an upstream label allocation approach may be used. 411 5.11. Label spaces 413 Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or 414 dedicated label spaces. 415 MPLS Context Specific Label Spaces ([UPSTREAM-LABEL]) and 416 particularly Upstream label spaces and Tunnel label spaces MAY be 417 required to support upstream label allocation so as to avoid packet 418 replication on LAN or P2MP TE Tunnel interfaces. 420 Note that dedicated label spaces will require the establishment of 421 separate P2MP LDP sessions. 423 5.12. IPv4/IPv6 support 425 The P2MP LDP mechanism MUST be equally applicable to IPv4 and IPv6 426 traffic. Likewise, it SHOULD be possible to convey both kinds of 427 traffic in a given P2MP LSP facility. 429 Also the P2MP LDP mechanism MUST support the establishment of LDP 430 sessions over both IPv4 and IPv6 control planes. 432 5.13. Multi-Area LSPs 434 The P2MP LDP mechanism MUST support the establishment of multi-area 435 P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP 436 area. This SHOULD be possible without requiring the advertisement of 437 Leaf LSRs' addresses across IGP areas. 439 5.14. OAM 441 LDP management tools ([LDP-MIB]�) MUST be enhanced to support P2MP 442 LDP extensions. This may yield a new MIB module, which may possibly 443 be inherited from the LDP MIB. 445 In order to facilitate correct management, P2MP LDP LSPs MUST have 446 unique identifiers, otherwise it is impossible to determine which LSP 447 is being managed. 448 OAM facilities will have special demands in P2MP MPLS environments 449 especially within the context of tracing the paths and determining 450 the connectivity of P2MP LSPs. Further and precise requirements and 451 mechanisms for OAM purpose are out of the scope of this document and 452 are addressed in [P2MP-OAM-REQ]. 454 5.15. Graceful Restart and Fault Recovery 456 LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT] 457 mechanisms SHOULD be enhanced to support P2MP LDP LSPs. 459 Particularly [LDP-GR] applies only to downstream unsolicited label 460 distribution. Hence new mechanisms are required to account for 461 upstream label assignment, particularly in multi segment LANs. 463 5.16. Robustness 465 A solution SHOULD avoid whatever single points of failures or propose 466 some technical solutions for a failover mechanism. 468 5.17. Scalability 470 Scalability is a key requirement for the P2MP LDP mechanism. 471 It MUST be designed to scale well with an increase in the number of 472 any of the following: 473 - number of Leaf LSRs per P2MP LSP 474 - number of Branch LSRs per P2MP LSP 475 - number of P2MP LSPs per LSR 477 In order to scale well with an increase in the number of leaves, it 478 is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one 479 particular LSP, depend only on the number of adjacent LSRs on the 480 LSP. 482 5.17.1. Orders of magnitude of the expected numbers of P2MP LSPs and 483 leaves per LSP in operational networks 485 To be completed in next revision 487 5.18. Backward Compatibility 489 In order to allow for a smooth migration, the P2MP LDP mechanism 490 SHOULD offer as much backward compatibility as possible. In 491 particular, the solution SHOULD allow the setup of a P2MP LSP along 492 non Branch Transit LSRs that do not support P2MP LDP extensions. 494 Also, the P2MP LDP solution MUST interoperate seamlessly with current 495 LDP mechanisms and inherit its capability sets from [LDP]. The P2MP 496 LDP solution MUST not impede the operation of P2P/MP2P LSPs. A P2MP 497 LDP solution MUST be designed in such a way that it allows P2P/MP2P 498 and P2MP LSPs to be signalled on the same interface. 500 6. Shared Trees 502 For traffic delivery between a group of N LSRs which are acting 503 indifferently as Ingress or Egress LSR, it may be useful to 504 setup a multipoint-to-multipoint (MP2MP) LSP connecting all these 505 LSRs, instead of having N P2MP LSPs. This would reduce the amount of 506 state that has to be maintained on a given LSR. 508 Hence the P2MP LDP mechanism MAY also allow setting up MP2MP LSPs. 509 Detailed requirements for MP2MP LSPs are left for further study 511 Note that the setup of such shared trees, with as objective to reduce 512 the amount of state, could also rely on the application protocols 513 that uses LDP LSPs, rather than on LDP itself. For instance with 514 Multicast L3 VPN applications, it would be possible to build a shared 515 tree that relies on a set of unicast LDP LSPs, from each PE of the 516 group to a particular PE, acting as tree root, and one P2MP LDP LSP 517 from the root to all PEs of the group (see [2547-MCAST]). 519 7. Evaluation criteria 521 7.1. Performances 523 The solution will be evaluated with respect to the following 524 criteria: 526 (1) Time (in msec) to add or remove a Leaf LSR; 527 (2) Time (in msec) to repair a P2MP LSP in case of link or node 528 failure; 529 (3) Scalability (state size, number of messages, message size). 531 Particularly, the P2MP LDP mechanism SHOULD be designed so that 532 convergence times in case of link or node failure are minimized, in 533 order to limit traffic disruption. 535 7.2. Complexity and Risks 537 The proposed solution SHOULD not introduce complexity to the current 538 LDP operations to such a degree that it would affect the stability 539 and diminish the benefits of deploying such P2MP LDP solution. 541 8. Security Considerations 543 This document does not introduce any new security issue beyond those 544 inherent to LDP, and a P2MP LDP solution may rely on the security 545 mechanisms defined in [LDP] (e.g. TCP MD-5). 547 9. Acknowledgments 549 We would like to thank Christian Jacquenet (France Telecom), 550 Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper) and Dean 551 Cheng (Cisco Systems) for their highly useful comments and 552 suggestions. 554 We would also like to thank authors of [P2MP-TE-REQ] from which some 555 text of this document has been inspired. 557 10. References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, March 1997. 562 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 563 3667, February 2004. 565 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 566 Technology", RFC 3979, March 2005. 568 [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, 569 "LDP Specification", RFC 3036, January 2001 571 [L3VPN-MCAST-REQ] T. Morin, Ed., "Requirements for Multicast in L3 572 Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts- 573 01.txt, work in progress. 575 [L2VPN-MCAST-REQ] Y. Kamite et al. " Requirements for Multicast 576 Support in Virtual Private LAN Services", draft-kamite-l2vpn-vpls- 577 mcast-reqts-00.txt, work in progress 579 [P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to- 580 Multipoint capability extension to MPLS", draft-ietf-mpls-p2mp-sig- 581 requirement-03.txt, work in progress. 583 [P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.., 584 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf- 585 mpls-rsvp-te-p2mp-02.txt, work in progress. 587 [PIM-MPLS] D. Farinacci, Y. Rekhter, E. Rosen, T. Qian, " Using PIM 588 to Distribute MPLS Labels for Multicast Routes", draft-farinacci- 589 mpls-multicast-03.txt. 591 [MPLS-UPSTREAM-LABEL] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS 592 Upstream Label Assignment and Context Specific Label Space", draft- 593 raggarwa-mpls-upstream-label-00.txt, work in progress. 595 [LDP-MIB] J. Cuchiarra et al. " Definitions of Managed Objects for 596 the Multiprotocol Label Switching (MPLS), Label Distribution Protocol 597 (LDP)", RFC3815, June 2004. 599 [LDP-GR] M. Leelanivas, Y. Rekhter, R. Aggarwal, " Graceful Restart 600 Mechanism for Label Distribution Protocol" RFC3478, February 2003. 602 [LDP-FT] A. Farrel, " Fault Tolerance for the Label Distribution 603 Protocol (LDP)", RFC3479, February 2003. 605 [2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP 606 IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress. 608 [P2MP-OAM-REQ] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM 609 Requirements for Point-To-Multipoint MPLS Networks", draft-yasukawa- 610 mpls-p2mp-oam-reqs-00.txt, work in progress. 612 11. Authors' Addresses: 614 Jean-Louis Le Roux 615 France Telecom 616 2, avenue Pierre-Marzin 617 22307 Lannion Cedex 618 FRANCE 619 Email: jeanlouis.leroux@francetelecom.com 621 Thomas Morin 622 France Telecom 623 2, avenue Pierre-Marzin 624 22307 Lannion Cedex 625 FRANCE 626 Email: thomas.morin@francetelecom.com 628 Vincent Parfait 629 EQUANT 630 1041 Route des Dolines 631 Sophia Antipolis 632 06560 Valbonne 633 FRANCE 634 Email: vincent.parfait@equant.com 636 Luyuan Fang 637 AT&T 638 200 Laurel Avenue 639 Middletown, NJ 07748 640 USA 641 Email: luyuanfang@att.com 643 Lei Wang 644 Telenor 645 Snaroyveien 30 646 Fornebu 1331 647 NORWAY 648 Email: lei.wang@telenor.com 650 Yuji Kamite 651 NTT Communications Corporation 652 Tokyo Opera City Tower 653 3-20-2 Nishi Shinjuku, Shinjuku-ku, 654 Tokyo 163-1421, 655 JAPAN 656 Email: y.kamite@ntt.com 658 Shane Amante 659 Level 3 Communications, LLC 660 1025 Eldorado Blvd 661 Broomfield, CO 80021 662 USA 663 Email: shane@level3.net 665 12. Intellectual Property Statement 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed to 669 pertain to the implementation or use of the technology described in 670 this document or the extent to which any license under such rights 671 might or might not be available; nor does it represent that it has 672 made any independent effort to identify any such rights. Information 673 on the procedures with respect to rights in RFC documents can be 674 found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use of 679 such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository at 681 http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at 687 ietf-ipr@ietf.org. 689 Disclaimer of Validity 691 This document and the information contained herein are provided on an 692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 693 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 694 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 695 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 696 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Copyright Statement 701 Copyright (C) The Internet Society (2005). This document is subject 702 to the rights, licenses and restrictions contained in BCP 78, and 703 except as set forth therein, the authors retain all their rights.