idnits 2.17.1 draft-morin-l3vpn-mvpn-fast-failover-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: [RFC4875], the status of the corresponding P-Tunnel SHOULD be re-evaluated. If the P-Tunnel transitions from up to down state, the upstream PE, that is the ingress of the P-Tunnel, SHOULD not be considered a valid UMH. -- 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 8, 2009) is 5406 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-08 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-07 == Outdated reference: A later version (-02) exists of draft-karan-mofrr-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Morin 3 Internet-Draft France Telecom - Orange Labs 4 Intended status: Experimental Y. Rekhter 5 Expires: January 9, 2010 R. Aggarwal 6 Juniper Networks 7 W. Henderickx 8 P. Muley 9 Alcatel-Lucent 10 July 8, 2009 12 Multicast VPN fast upstream failover 13 draft-morin-l3vpn-mvpn-fast-failover-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 9, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document defines multicast VPN extensions and procedures that 52 allow fast failover for upstream failures, by allowing downstream PEs 53 to take into account the status of Provider-Tunnels (P-tunnels) when 54 selecting the upstream PE for a VPN multicast flow, and extending BGP 55 mVPN routing so that a C-multicast route can be advertised toward a 56 standby upstream PE. 58 Requirements Language 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. UMH Selection based on tunnel status . . . . . . . . . . . . . 3 69 3.1. Determining the status of a tunnel . . . . . . . . . . . . 4 70 3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5 71 3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5 72 3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . . 5 73 3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . . 6 74 3.1.5. P2MP LSP OAM . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.6. (S,G) counter information . . . . . . . . . . . . . . 6 76 4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 7 77 4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . . 7 78 4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . . 8 79 4.3. Reachability determination . . . . . . . . . . . . . . . . 9 80 5. Hot leaf standby . . . . . . . . . . . . . . . . . . . . . . . 9 81 6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 10 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 In the context of multicast in BGP/MPLS VPNs, it is desirable to 93 provide mechanisms allowing fast recovery of connectivity on 94 different types of failures. This document addresses failures of 95 elements in the provider network that are upstream of PEs connected 96 to VPN sites with receivers. 98 The sections 3 and 4 describe two independent mechanisms, allowing 99 different levels of resiliency, and providing different failure 100 coverage: 102 o Section 3 describes local procedures allowing an egress PE (a PE 103 connected to a receiver site) to take into account the status of 104 P-Tunnels to determine the Upstream Multicast Hop (UMH) for a 105 given (C-S, C-G). 107 o Section 4 describes protocol extensions that can speed up failover 108 by not requiring any multicast VPN routing message exchange at 109 recovery time. 111 Moreover, section 5 describes a "hot leaf standby" mechanism, that 112 uses a combination of these two mechanisms. This approach has 113 similarities with the solution described in [I-D.karan-mofrr] to 114 improve failover times when PIM routing is used in a network given 115 some topology and metric constraints. 117 2. Terminology 119 The terminology used in this document is the terminology defined in 120 [I-D.ietf-l3vpn-2547bis-mcast] and 121 [I-D.ietf-l3vpn-2547bis-mcast-bgp]. 123 3. UMH Selection based on tunnel status 125 Current multicast VPN specifications [I-D.ietf-l3vpn-2547bis-mcast], 126 section 5.1, describe the procedures used by a multicast VPN 127 downstream PE to determine what the upstream multicast hop (UMH) is 128 for a said (C-S,C-G). 130 The procedure described here is an OPTIONAL procedure that consist in 131 having a downstream PE take into account the status of P-tunnels 132 rooted at each possible upstream PEs, for including or not including 133 each said PE in the list of candidate UMHs for a said (C-S,C-G) 134 state. The result is that, if a P-tunnel is "down" (see 135 Section 3.1), the PE that is the root of the P-Tunnel will not be 136 considered for UMH selection, which will result in the downstream PE 137 to failover to the upstream PE which is next in the list of 138 candidates. 140 More precisely, UMH determination for a said (C-S,C-G) will consider 141 the UMH candidates in the following order: 143 o first, the UMH candidates that either (a) advertise a PMSI bound 144 to a tunnel that is "up", or (b) do not advertise any I- or S- 145 PMSI applicable to the said (C-S,C-G) but have associated a VRF 146 Route Import BGP attribute to the unicast VPN route for S (this is 147 necessary to avoid considering invalid some UMH PEs that use a a 148 policy where no I-PMSI is advertized for a said VRF and where only 149 S-PMSI are used, the S-PMSI advertisement being possibly done only 150 after the upstream PE receives a C-multicast route for (C-S, 151 C-G)/(C-*, C-G) to be carried over the advertised S-PMSI) 153 o second, the UMH candidates that advertise a PMSI bound to a tunnel 154 that is "down" -- these will thus be used as a last resort to 155 ensure a graceful fallback to the basic mVPN UMH selection 156 procedures in the hypothetical case where a false negative would 157 occur when determining the status of all tunnels 159 For a said downstream PE and a said VRF, the P-tunnel corresponding 160 to a said upstream PE for a said (C-S,C-G) state is the S-PMSI tunnel 161 advertized by that upstream PE for this (C-S,C-G) and imported into 162 that VRF, or if there isn't any such S-PMSI, the I-PMSI tunnel 163 advertized by that PE and imported into that VRF. 165 Note that this documents assumes that if a site of a given mVPN that 166 contains C-S is dual-homed to two PEs, then all the other sites of 167 that mVPN would have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) 168 routes to C-S, each with its own RD. 170 3.1. Determining the status of a tunnel 172 Different factors can be considered to determine the "status" of a 173 P-tunnel and are described in the following sub-sections. The 174 procedure proposed here also allows that all downstream PEs don't 175 apply the same rules to define what the status of a P-tunnel is 176 (please see Section 6), and some of them will produce a result that 177 may be different for different downstream PEs. Thus what is called 178 the "status" of a P-tunnel in this section, is not a characteristic 179 of the tunnel in itself, but is the status of the tunnel, *as seen 180 from a particular downstream PE*. 182 Depending on the criteria used to determine the status of a P-tunnel, 183 there may be an interaction with other resiliency mechanism used for 184 the P-tunnel itself, and the UMH update may happen immediately or may 185 need to be delayed. Each particular case is covered in each separate 186 sub-section below. 188 3.1.1. mVPN tunnel root tracking 190 A condition to consider that the status of a P-tunnel is up is that 191 the root of the tunnel, as determined in the PMSI tunnel attribute, 192 is reachable through unicast routing tables. In this case the 193 downstream PE can immediately update its UMH when the reachability 194 condition changes. 196 This is similar to BGP next-hop tracking for VPN routes, except that 197 the address considered is not the BGP next-hop address, but the root 198 address in the PMSI tunnel attribute. 200 If BGP next-hop tracking is done for VPN routes, and the root address 201 of a said tunnel happens to be the same as the next-hop address in 202 the BGP autodiscovery route advertising the tunnel, then this 203 mechanisms may be omitted for this tunnel, as it will not bring any 204 specific benefit. 206 3.1.2. PE-P Upstream link status 208 A condition to consider a tunnel status as up can be that the last- 209 hop link of the P-tunnel is up. 211 In that case, if the PE can determine that there is no fast 212 restoration mechanism (such as MPLS FRR [RFC4090]) in place for the 213 P-tunnel, it can update the UMH immediately. Else, it should wait 214 before updating the UMH, to let the P-tunnel restoration mechanims 215 happen. A configurable timer MUST be provided for this purpose, and 216 it is recommended to provide a reasonable default value for this 217 timer. 219 3.1.3. P2MP RSVP-TE tunnels 221 For P-Tunnels of type P2MP MPLS-TE, the status of the P-Tunnel is 222 considered up if one or more of the P2MP RSVP-TE LSPs, identified by 223 the P-Tunnel Attribute, are in up state. The determination of 224 whether a P2MP RSVP-TE LSP is in up state requires Path and Resv 225 state for the LSP and is based on procedures in [RFC4875]. In this 226 case the downstream PE can immediately update its UMH when the 227 reachability condition changes. 229 When signaling state for a P2MP TE LSP is removed (e.g. if the 230 ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE 231 LSP changes state from up to down as determined by procedures in 233 [RFC4875], the status of the corresponding P-Tunnel SHOULD be re- 234 evaluated. If the P-Tunnel transitions from up to down state, the 235 upstream PE, that is the ingress of the P-Tunnel, SHOULD not be 236 considered a valid UMH. 238 3.1.4. Leaf-initiated P-tunnels 240 A PE can be removed from the UMH candidate list for a said (S,G) if 241 the P-tunnel for this S,G (I or S , depending) is leaf triggered 242 (PIM, mLDP), but for some reason internal to the protocol the 243 upstream one-hop branch of the tunnel from P to PE cannot be built. 244 In this case the downstream PE can immediately update its UMH when 245 the reachability condition changes. 247 3.1.5. P2MP LSP OAM 249 When a P2MP connectivity verification mechanism such as 250 [I-D.katz-ward-bfd-multipoint] used in conjunction with bootstraping 251 mechanisms described in [I-D.ietf-mpls-mcast-cv] has been setup for a 252 tunnel, the result of the connectivity verification can be used to 253 define the status of the tree. 255 If a MultipointHead session has been established on a P2MP MPLS LSP 256 so that BFD packets are periodically sent from the root toward 257 leaves, a condition to consider the status of corresponding tunnel as 258 up is that the BFD SessionState is Up. 260 When such a procedure is used, in context where fast restoration 261 mechanisms are used for the P-tunnels, downstream PEs should be 262 configured to wait before updating the UMH, to let the P-tunnel 263 restoration mechanims happen. A configurable timer MUST be provided 264 for this purpose, and it is recommended to provide a reasonable 265 default value for this timer. 267 3.1.6. (S,G) counter information 269 In cases, where the downstream node can be configured so that the 270 maximum inter-packet time is known for all the multicast flows mapped 271 on a P-tunnel, the local per-(C-S,C-G) traffic counter information 272 for traffic received on this P-tunnel can be used to determine the 273 status of the P-tunnel. 275 When such a procedure is used, in context where fast restoration 276 mechanisms are used for the P-tunnels, downstream PEs should be 277 configured to wait before updating the UMH, to let the P-tunnel 278 restoration mechanims happen. A configurable timer MUST be provided 279 for this purpose, and it is recommended to provide a reasonable 280 default value for this timer. 282 This method can be applicable for instance when a (S,G) flow is 283 mapped on an S-PMSI. 285 In cases where this mechanism is used in conjunction with Hot leaf 286 standby, then no prior knowledge of the rate of the multicast streams 287 is required ; downstream PEs can compare reception on the two 288 P-tunnels to determine when one of them is down. 290 4. Standby C-multicast route 292 The procedures described below are limited to the case where the site 293 that contains C-S is connected to exactly two PEs. The procedures 294 require all the PEs of that mVPN to follow the single forwarder PE 295 selection, as specified in [I-D.ietf-l3vpn-2547bis-mcast]. The 296 procedures assume that if a site of a given mVPN that contains C-S is 297 dual-homed to two PEs, then all the other sites of that mVPN would 298 have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) routes to C-S, 299 each with its own RD. 301 As long as C-S is reachable via both PEs, a said downstream PE will 302 select one of the PEs connected to C-S as its Upstream PE with 303 respect to C-S. We will refer to the other PE connected to C-S as 304 the "Standby Upstream PE". Note that if the connectivity to C-S 305 through the Primary Upstream PE becomes unavailable, then the PE will 306 select the Standby Upstream PE as its Upstream PE with respect to 307 C-S. 309 For readability, in the following sub-sections, the procedures are 310 described for BGP C-multicast Source Tree Join routes, but they apply 311 equally to BGP C-multicast Shared Tree Join routes failover for the 312 case where the customer RP is dual-homed (substitute "C-RP" to 313 "C-S"). 315 4.1. Downstream PE behavior 317 When a (downstream) PE connected to some site of an mVPN needs to 318 send a C-multicast route (C-S, C-G), then following the procedures 319 specified in Section "Originating C-multicast routes by a PE" of 320 [I-D.ietf-l3vpn-2547bis-mcast-bgp] the PE sends the C-multicast route 321 with RT that identifies the Upstream PE selected by the PE 322 originating the route. As long as C-S is reachable via the Primary 323 Upstream PE, the Upstream PE is the Primary Upstream PE. If C-S is 324 reachable only via the Standby Upstream PE, then the Upstream PE is 325 the Standby Upstream PE. 327 If C-S is reachable via both the Primary and the Standby Upstream PE, 328 then in addition to sending the C-multicast route with an RT that 329 identifies the Primary Upstream PE, the PE also originates and sends 330 a C-multicast route with an RT that identifies the Standby Upstream 331 PE. This route, that has the semantic of being a 'standby' 332 C-multicast route, is further called a "Standby BGP C-multicast 333 route", and is constructed as follows: 335 o the NLRI is constructed as the original C-multicast route, except 336 that the RD is the same as if the C-multicast route was built 337 using the standby PE as the UMH (it will carry the RD associated 338 to the unicast VPN route advertised by the standby PE for S) 340 o MUST carry the "Standby PE" BGP Community (this is a new BGP 341 Community, see Section 7) 343 The normal and the standby C-multicast routes must have their Local 344 Preference attribute adjusted so that, if two C-multicast routes with 345 same NLRI are received by a BGP peer, one carrying the "Standby PE" 346 attribute and the other one *not* carrying the "Standby PE" 347 community, then preference is given to the one *not* carrying the 348 "Standby PE" attribute. Such a situation can happen when, for 349 instance due to transient unicast routing inconistencies, two 350 different downstream PEs consider different upstream PEs to be the 351 primary one ; in that case, without any precaution taken, both 352 upstream PEs would process a standby C-multicast route and possibly 353 stop forwarding at the same time. For this purpose a Standby BGP 354 C-multicast route MUST have the LOCAL_PREF attribute set to zero. 356 If at some later point the local PE determines that C-S is no longer 357 reachable through the Primary Upstream PE, the Standby Upstream PE 358 becomes the Upstream PE, and the local PE re-sends the C-multicast 359 route with RT that identifies the Standby Upstream PE, except that 360 now the route does not carry the Standby PE BGP Community (which 361 results in replacing the old route with a new route, with the only 362 difference between these routes being the presence/absence of the 363 Standby PE BGP Community). 365 4.2. Upstream PE behavior 367 When a PE receives a C-multicast route for a particular (C-S, C-G), 368 and the RT carried in the route results in importing the route into a 369 particular VRF on the PE, if the route carries the Standby PE BGP 370 Community, then the PE performs as follows: 372 when the PE determines that C-S is not reachable through some 373 other PE, the PE SHOULD install VRF PIM state corresponding to 374 this Standby BGP C-multicast route (the result will be that a PIM 375 Join message will be sent to the CE towards C-S, and that the PE 376 will receive (C-S,C-G) traffic), and the PE SHOULD forward (C-S, 377 C-G) traffic received by the PE to other PEs through a P-tunnel 378 rooted at the PE. 380 Furthermore, irrespective of whether C-S carried in that route is 381 reachable through some other PE: 383 a) based on local policy, as soon as the PE receives this Standby BGP 384 C-multicast route, the PE MAY install VRF PIM state corresponding 385 to this BGP Source Tree Join route (the result will be that Join 386 messages will be sent to the CE toward C-S, and that the PE will 387 receive (C-S,C-G) traffic) 389 b) based on local policy, as soon as the PE receives this Standby BGP 390 C-multicast route, the PE MAY forward (C-S, C-G) traffic to other 391 PEs through a P-tunnel independently of the reachability of C-S 392 through some other PE. [note that this implies also doing (a)] 394 Doing neither (a), nor (b) for a said (C-S,C-G) is called "cold root 395 standby". 397 Doing (a) but not (b) for a said (C-S,C-G) is called "warm root 398 standby". 400 Doing (b) (which implies also doing (a)) for a said (C-S,C-G) is 401 called "hot root standby". 403 4.3. Reachability determination 405 The standby PE can use the following information to determine that 406 C-S can or cannot be reached through the primary PE: 408 o presence/absence of a unicast VPN route toward C-S 410 o supposing that the standby PE is an egress of the tunnel rooted at 411 the Primary PE, the standby PE can determine the reachability of 412 C-S through the Primary PE based on the status of this tunnel, 413 determined thanks to the same criteria as the ones described in 414 Section 3.1 (without using the UMH selection procedures of 415 Section 3) 417 o other mechanisms MAY be used 419 5. Hot leaf standby 421 The mechanisms defined in the two previous section can be used 422 together as follows. 424 The principle is that, for a said VRF (or possibly only for a said 425 C-S,C-G): 427 o downstream PEs advertise a Standby BGP C-multicast route (based on 428 Section 4) 430 o upstream PEs use the "hot standby" optional behavior and thus will 431 forward traffic for a said multicast state as soon as they have 432 whether a (primary) BGP C-multicast route or a Standby BGP 433 C-multicast route for that state (or both) 435 o downstream PEs accept traffic from the primary or standby tunnel, 436 based on the status of the tunnel (based on Section 3) 438 Note that the same level of protection would be achievable with a 439 simple C-multicast Source Tree Join route advertised to both the 440 primary and secondary upstream PEs (carrying as Route Target extended 441 communities, the values of the VRF Route Import attribute of each VPN 442 route from each upstream PEs). The advantage of using the hot leaf 443 standby semantic is that by making these downstream PEs always 444 advertise a Standby C-multicast route to the secondary upstream PE, 445 it allows to choose the protection level through a change of 446 configuration on the secondary upstream PE, without requiring any 447 reconfiguration of all the downstream PEs. 449 Other combinations of the mechanisms proposed in Section 4 and 450 Section 3 are for further study. 452 6. Duplicate packets 454 Multicast VPN specifications [I-D.ietf-l3vpn-2547bis-mcast] impose 455 that a PE only forwards to CEs the packets coming from the expected 456 usptream PE (Section 9.1). 458 We highlight the reader's attention to the fact that the respect of 459 this part of multicast VPN specifications is especially important 460 when two distinct upstream PEs are succeptible to forward the same 461 traffic on P-tunnels at the same time in steady state. This will be 462 the case when "hot root standby" mode is used (Section 4), and which 463 can also be the case if procedures of Section 3 are used and (a) the 464 rules determining the status of a tree are not the same on two 465 distinct downstream PEs or (b) the rule determining the status of a 466 tree depend on conditions local to a PE (e.g. the PE-P upstream link 467 being up). 469 7. IANA Considerations 471 Allocation is expected from IANA for the BGP "Standby PE" community. 472 (TBC) 474 [Note to RFC Editor: this section may be removed on publication as an 475 RFC.] 477 8. Security Considerations 479 9. Acknowledgements 481 The authors want to thank Ray Qiu for its review and useful feedback. 483 10. References 485 10.1. Normative References 487 [I-D.ietf-l3vpn-2547bis-mcast] 488 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 489 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 490 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-08 (work 491 in progress), March 2009. 493 [I-D.ietf-l3vpn-2547bis-mcast-bgp] 494 Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 495 Encodings and Procedures for Multicast in MPLS/BGP IP 496 VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-07 (work in 497 progress), April 2009. 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 503 "Extensions to Resource Reservation Protocol - Traffic 504 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 505 Switched Paths (LSPs)", RFC 4875, May 2007. 507 10.2. Informative References 509 [I-D.ietf-mpls-mcast-cv] 510 Swallow, G., "Connectivity Verification for Multicast 511 Label Switched Paths", draft-ietf-mpls-mcast-cv-00 (work 512 in progress), April 2007. 514 [I-D.karan-mofrr] 515 Karan, A., Filsfils, C., and D. Farinacci, "Multicast only 516 Fast Re-Route", draft-karan-mofrr-00 (work in progress), 517 March 2009. 519 [I-D.katz-ward-bfd-multipoint] 520 Katz, D. and D. Ward, "BFD for Multipoint Networks", 521 draft-katz-ward-bfd-multipoint-02 (work in progress), 522 February 2009. 524 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 525 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 526 May 2005. 528 Authors' Addresses 530 Thomas Morin 531 France Telecom - Orange Labs 532 2, avenue Pierre Marzin 533 Lannion 22307 534 France 536 Email: thomas.morin@orange-ftgroup.com 538 Yakov Rekhter 539 Juniper Networks 540 1194 North Mathilda Ave. 541 Sunnyvale, CA 94089 542 U.S.A. 544 Email: yakov@juniper.net 546 Rahul Aggarwal 547 Juniper Networks 548 1194 North Mathilda Ave. 549 Sunnyvale, CA 94089 550 U.S.A. 552 Email: rahul@juniper.net 553 Wim Henderickx 554 Alcatel-Lucent 555 Copernicuslaan 50 556 Antwerp 2018 557 Belgium 559 Email: wim.henderickx@alcatel-lucent.com 561 Praveen Muley 562 Alcatel-Lucent 563 701 East Middlefield Rd 564 Mountain View, CA 94043 565 U.S.A. 567 Email: praveen.muley@alcatel-lucent.com