idnits 2.17.1 draft-morin-l3vpn-mvpn-fast-failover-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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: When signaling state for a P2MP TE LSP is removed (e.g. if the ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE LSP changes state from up to down as determined by procedures in [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 (March 9, 2009) is 5526 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-06 == Outdated reference: A later version (-02) exists of draft-karan-mofrr-00 Summary: 0 errors (**), 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: September 10, 2009 R. Aggarwal 6 Juniper Networks 7 W. Henderickx 8 P. Muley 9 Alcatel-Lucent 10 March 9, 2009 12 Multicast VPN fast upstream failover 13 draft-morin-l3vpn-mvpn-fast-failover-01 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 September 10, 2009. 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 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Abstract 52 This document defines multicast VPN extensions and procedures that 53 allow fast failover for upstream failures, by allowing downstream PEs 54 to take into account the status of Provider-Tunnels (P-tunnels) when 55 selecting the upstream PE for a VPN multicast flow, and extending BGP 56 mVPN routing so that a C-multicast route can be advertised toward a 57 standby upstream PE. 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. UMH Selection based on tunnel status . . . . . . . . . . . . . 3 70 3.1. Determining the status of a tunnel . . . . . . . . . . . . 4 71 3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5 72 3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5 73 3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . . 5 74 3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . . 6 75 3.1.5. P2MP LSP OAM . . . . . . . . . . . . . . . . . . . . . 6 76 3.1.6. (S,G) counter information . . . . . . . . . . . . . . 6 77 4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 7 78 4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . . 7 79 4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . . 8 80 4.3. Reachability determination . . . . . . . . . . . . . . . . 9 81 5. Hot leaf standby . . . . . . . . . . . . . . . . . . . . . . . 9 82 6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 In the context of multicast in BGP/MPLS VPNs, it is desirable to 94 provide mechanisms allowing fast recovery of connectivity on 95 different types of failures. This document addresses failures of 96 elements in the provider network that are upstream of PEs connected 97 to VPN sites with receivers. 99 The sections 3 and 4 describe two independent mechanisms, allowing 100 different levels of resiliency, and providing different failure 101 coverage: 103 o Section 3 describes local procedures allowing an egress PE (a PE 104 connected to a receiver site) to take into account the status of 105 P-Tunnels to determine the Upstream Multicast Hop (UMH) for a 106 given (C-S, C-G). 108 o Section 4 describes protocol extensions that can speed up failover 109 by not requiring any multicast VPN routing message exchange at 110 recovery time. 112 Moreover, section 5 describes a "hot leaf standby" mechanism, that 113 uses a combination of these two mechanisms. This approach has 114 similarities with the solution described in [I-D.karan-mofrr] to 115 improve failover times when PIM routing is used in a network given 116 some topology and metric constraints. 118 2. Terminology 120 The terminology used in this document is the terminology defined in 121 [I-D.ietf-l3vpn-2547bis-mcast] and 122 [I-D.ietf-l3vpn-2547bis-mcast-bgp]. 124 3. UMH Selection based on tunnel status 126 Current multicast VPN specifications [I-D.ietf-l3vpn-2547bis-mcast], 127 section 5.1, describe the procedures used by a multicast VPN 128 downstream PE to determine what the upstream multicast hop (UMH) is 129 for a said (C-S,C-G). 131 The procedure described here is an OPTIONAL procedure that consist in 132 having a downstream PE take into account the status of P-tunnels 133 rooted at each possible upstream PEs, for including or not including 134 each said PE in the list of candidate UMHs for a said (C-S,C-G) 135 state. The result is that, if a P-tunnel is "down" (see 136 Section 3.1), the PE that is the root of the P-Tunnel won't be 137 considered for UMH selection, which will result in the downstream PE 138 to failover to the upstream PE which is next in the list of 139 candidates. 141 More precisely, UMH determination for a said (C-S,C-G) will consider 142 the UMH candidates in the following order: 144 o first, the UMH candidates that either (a) advertise a PMSI bound 145 to a tunnel that is "up", or (b) do not advertise any I- or S- 146 PMSI applicable to the said (C-S,C-G) but have associated a VRF 147 Route Import BGP route to the unicast VPN route for S (this is 148 necessary to avoid considering invalid some UMH PEs that use a a 149 policy where no I-PMSI is advertized for a said VRF and where only 150 S-PMSI are used, the S-PMSI advertisement being possibly done only 151 after the upstream PE receives a C-multicast route for (C-S, 152 C-G)/(C-*, C-G) to be carried over the advertised S-PMSI) 154 o second, the UMH candidates that advertise a PMSI bound to a tunnel 155 that is "down" -- these will thus be used as a last resort to 156 ensure a graceful fallback to the basic mVPN UMH selection 157 procedures in the hypothetical case where a false negative would 158 occur when determining the status of all tunnels 160 For a said downstream PE and a said VRF, the P-tunnel corresponding 161 to a said upstream PE for a said (C-S,C-G) state is the S-PMSI tunnel 162 advertized by that upstream PE for this (C-S,C-G) and imported into 163 that VRF, or if there isn't any such S-PMSI, the I-PMSI tunnel 164 advertized by that PE and imported into that VRF. 166 3.1. Determining the status of a tunnel 168 Different factors can be considered to determine the "status" of a 169 P-tunnel and are described in the following sub-sections. The 170 procedure proposed here also allows that all downstream PEs don't 171 apply the same rules to define what the status of a P-tunnel is 172 (please see Section 6), and some of them will produce a result that 173 may be different for different downstream PEs. Thus what is called 174 the "status" of a P-tunnel in this section, is not a characteristic 175 of the tunnel in itself, but is the status of the tunnel, *as seen 176 from a particular downstream PE*. 178 Depending on the criteria used to determine the status of a P-tunnel, 179 there may be an interaction with other resiliency mechanism used for 180 the P-tunnel itself, and the UMH update may happen immediately or may 181 need to be delayed. Each particular case is covered in each separate 182 sub-section below. 184 3.1.1. mVPN tunnel root tracking 186 A condition to consider that the status of a P-tunnel is up is that 187 the root of the tunnel, as determined in the PMSI tunnel attribute, 188 is reachable through unicast routing tables. In this case the 189 downstream PE can immediately update its UMH when the reachability 190 condition changes. 192 This is similar to BGP next-hop tracking for VPN routes, except that 193 the address considered is not the BGP next-hop address, but the root 194 address in the PMSI tunnel attribute. 196 If BGP next-hop tracking is done for VPN routes, and the root address 197 of a said tunnel happens to be the same as the next-hop address in 198 the BGP autodiscovery route advertising the tunnel, then this 199 mechanisms may be omitted for this tunnel, as it will not bring any 200 specific benefit. 202 3.1.2. PE-P Upstream link status 204 A condition to consider a tunnel status as up can be that the last- 205 hop link of the P-tunnel is up. 207 In that case, if the PE can determine that there is no fast 208 restoration mechanism (such as MPLS FRR [RFC4090]) in place for the 209 P-tunnel, it can update the UMH immediately. Else, it should wait 210 before updating the UMH, to let the P-tunnel restoration mechanims 211 happen. A configurable timer MUST be provided for this purpose, and 212 it is recommended to provide a reasonable default value for this 213 timer. 215 3.1.3. P2MP RSVP-TE tunnels 217 For P-Tunnels of type P2MP MPLS-TE, the status of the P-Tunnel is 218 considered up if one or more of the P2MP RSVP-TE LSPs, identified by 219 the P-Tunnel Attribute, are in up state. The determination of 220 whether a P2MP RSVP-TE LSP is in up state requires Path and Resv 221 state for the LSP and is based on procedures in [RFC4875]. In this 222 case the downstream PE can immediately update its UMH when the 223 reachability condition changes. 225 When signaling state for a P2MP TE LSP is removed (e.g. if the 226 ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE 227 LSP changes state from up to down as determined by procedures in 228 [RFC4875], the status of the corresponding P-Tunnel SHOULD be re- 229 evaluated. If the P-Tunnel transitions from up to down state, the 230 upstream PE, that is the ingress of the P-Tunnel, SHOULD not be 231 considered a valid UMH. 233 3.1.4. Leaf-initiated P-tunnels 235 A PE can be removed from the UMH candidate list for a said (S,G) if 236 the P-tunnel for this S,G (I or S , depending) is leaf triggered 237 (PIM, mLDP), but for some reason internal to the protocol the 238 upstream one-hop branch of the tunnel from P to PE cannot be built. 239 In this case the downstream PE can immediately update its UMH when 240 the reachability condition changes. 242 3.1.5. P2MP LSP OAM 244 When a P2MP connectivity verification mechanism such as 245 [I-D.katz-ward-bfd-multipoint] used in conjunction with bootstraping 246 mechanisms described in [I-D.ietf-mpls-mcast-cv] has been setup for a 247 tunnel, the result of the connectivity verification can be used to 248 define the status of the tree. 250 If a MultipointHead session has been established on a P2MP MPLS LSP 251 so that BFD packets are periodically sent from the root toward 252 leaves, a condition to consider the status of corresponding tunnel as 253 up is that the BFD SessionState is Up. 255 When such a procedure is used, in context where fast restoration 256 mechanisms are used for the P-tunnels, downstream PEs should be 257 configured to wait before updating the UMH, to let the P-tunnel 258 restoration mechanims happen. A configurable timer MUST be provided 259 for this purpose, and it is recommended to provide a reasonable 260 default value for this timer. 262 3.1.6. (S,G) counter information 264 In cases, where the downstream node can be configured so that the 265 maximum inter-packet time is known for all the multicast flows mapped 266 on a P-tunnel, the local per-(C-S,C-G) traffic counter information 267 for traffic received on this P-tunnel can be used to determine the 268 status of the P-tunnel. 270 When such a procedure is used, in context where fast restoration 271 mechanisms are used for the P-tunnels, downstream PEs should be 272 configured to wait before updating the UMH, to let the P-tunnel 273 restoration mechanims happen. A configurable timer MUST be provided 274 for this purpose, and it is recommended to provide a reasonable 275 default value for this timer. 277 This method can be applicable for instance when a (S,G) flow is 278 mapped on an S-PMSI. 280 In cases where this mechanism is used in conjunction with Hot leaf 281 standby, then no prior knowledge of the rate of the multicast streams 282 is required ; downstream PEs can compare reception on the two 283 P-tunnels to determine when one of them is down. 285 4. Standby C-multicast route 287 The procedures described below are limited to the case where the site 288 that contains C-S is connected to exactly two PEs. The procedures 289 require all the PEs of that mVPN to follow the single forwarder PE 290 selection, as specified in [I-D.ietf-l3vpn-2547bis-mcast]. The 291 procedures assume that if a site of a given mVPN that contains C-S is 292 dual-homed to two PEs, then all then other sites of that mVPN would 293 have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) routes to C-S, 294 each with its own RD. 296 As long as C-S is reachable via both PEs, a said downstream PE will 297 select one of the PEs connected to C-S as its Upstream PE with 298 respect to C-S. We will refer to the other PE connected to C-S as 299 the "Standby Upstream PE". Note that if the connectivity to C-S 300 through the Primary Upstream PE becomes unavailable, then the PE will 301 select the Standby Upstream PE as its Upstream PE with respect to 302 C-S. 304 For readability, in the following sub-sections, the procedures are 305 described for BGP C-multicast Source Tree Join routes, but they apply 306 equally to BGP C-multicast Shared Tree Join routes failover for the 307 case where the customer RP is dual-homed (substitute "C-RP" to 308 "C-S"). 310 4.1. Downstream PE behavior 312 When a (downstream) PE connected to some site of an mVPN needs to 313 send a C-multicast route (C-S, C-G), then following the procedures 314 specified in Section "Originating C-multicast routes by a PE" of 315 [I-D.ietf-l3vpn-2547bis-mcast-bgp] the PE sends the C-multicast route 316 with RT that identifies the Upstream PE selected by the PE 317 originating the route. As long as C-S is reachable via the Primary 318 Upstream PE, the Upstream PE is the Primary Upstream PE. If C-S is 319 reachable only via the Standby Upstream PE, then the Upstream PE is 320 the Standby Upstream PE. 322 If C-S is reachable via both the Primary and the Standby Upstream PE, 323 then in addition to sending the C-multicast route with an RT that 324 identifies the Primary Upstream PE, the PE also originates and sends 325 a C-multicast route with an RT that identifies the Standby Upstream 326 PE. This route, that has the semantic of being a 'standby' 327 C-multicast route, is further called a "Standby BGP C-multicast 328 route", and is constructed as follows: 330 o the NLRI is constructed as the original C-multicast route, except 331 that the RD is the same as if the C-multicast route was built 332 using the standby PE as the UMH (it will carry the RD associated 333 to the unicast VPN route advertised by the standby PE for S) 335 o MUST carry the "Standby PE" BGP Community (this is a new BGP 336 Community, see Section 7) 338 The normal and the standby C-multicast routes must have their Local 339 Preference attribute adjusted so that, if two C-multicast routes with 340 same NLRI are received by a BGP peer, one carrying the "Standby PE" 341 attribute and the other one *not* carrying the "Standby PE" 342 community, then preference is given to the one *not* carrying the 343 "Standby PE" attribute. Such a situation can happen when, for 344 instance due to transient unicast routing inconistencies, two 345 different downstream PEs consider different upstream PEs to be the 346 primary one ; in that case, without any precaution taken, both 347 upstream PEs would process a standby C-multicast route and possibly 348 stop forwarding at the same time. For this purpose a Standby BGP 349 C-multicast route MUST have the LOCAL_PREF attribute set to zero. 351 If at some later point the local PE determines that C-S is no longer 352 reachable through the Primary Upstream PE, the Standby Upstream PE 353 becomes the Upstream PE, and the local PE re-sends the C-multicast 354 route with RT that identifies the Standby Upstream PE, except that 355 now the route does not carry the Standby PE BGP Community (which 356 results in replacing the old route with a new route, with the only 357 difference between these routes being the presence/absence of the 358 Standby PE BGP Community). 360 4.2. Upstream PE behavior 362 When a PE receives a C-multicast route for a particular (C-S, C-G), 363 and the RT carried in the route results in importing the route into a 364 particular VRF on the PE, if the route carries the Standby PE BGP 365 Community, then the PE performs as follows: 367 when the PE determines that C-S is not reachable through some 368 other PE, the PE SHOULD install VRF PIM state corresponding to 369 this Standby BGP C-multicast route (the result will be that a PIM 370 Join message will be sent to the CE towards C-S, and that the PE 371 will receive (C-S,C-G) traffic), and the PE SHOULD forward (C-S, 372 C-G) traffic received by the PE to other PEs through a P-tunnel 373 rooted at the PE. 375 Furthermore, irrespective of whether C-S carried in that route is 376 reachable through some other PE: 378 a) based on local policy, as soon as the PE receives this Standby BGP 379 C-multicast route, the PE MAY install VRF PIM state corresponding 380 to this BGP Source Tree Join route (the result will be that Join 381 messages will be sent to the CE toward C-S, and that the PE will 382 receive (C-S,C-G) traffic) 384 b) based on local policy, as soon as the PE receives this Standby BGP 385 C-multicast route, the PE MAY forward (C-S, C-G) traffic to other 386 PEs through a P-tunnel independently of the reachability of C-S 387 through some other PE. [note that this implies also doing (a)] 389 Doing neither (a), nor (b) for a said (C-S,C-G) is called "cold root 390 standby". 392 Doing (a) but not (b) for a said (C-S,C-G) is called "warm root 393 standby". 395 Doing (b) (which implies also doing (a)) for a said (C-S,C-G) is 396 called "hot root standby". 398 4.3. Reachability determination 400 The standby PE can use the following information to determine that 401 C-S can or cannot be reached through the primary PE: 403 o presence/absence of a unicast VPN route toward C-S 405 o supposing that the standby PE is an egress of the tunnel rooted at 406 the Primary PE, the standby PE can determine the reachability of 407 C-S through the Primary PE based on the status of this tunnel, 408 determined thanks to the same criteria as the ones described in 409 Section 3.1 (without using the UMH selection procedures of 410 Section 3) 412 o other mechanisms MAY be used 414 5. Hot leaf standby 416 The mechanisms defined in the two previous section can be used 417 together as follows. 419 The principle is that, for a said VRF (or possibly only for a said 420 C-S,C-G): 422 o downstream PEs advertise a Standby BGP C-multicast route (based on 423 Section 4) 425 o upstream PEs use the "hot standby" optional behavior and thus will 426 forward traffic for a said multicast state as soon as they have 427 whether a (primary) BGP C-multicast route or a Standby BGP 428 C-multicast route for that state (or both) 430 o downstream PEs accept traffic from the primary or standby tunnel, 431 based on the status of the tunnel (based on Section 3) 433 Other combinations of the mechanisms proposed in Section 4) and 434 Section 3 are for further study. 436 6. Duplicate packets 438 Multicast VPN specifications [I-D.ietf-l3vpn-2547bis-mcast] impose 439 that a PE only forwards to CEs the packets coming from the expected 440 usptream PE (Section 9.1). 442 We highlight the reader's attention to the fact that the respect of 443 this part of multicast VPN specifications is especially important 444 when two distinct upstream PEs are succeptible to forward the same 445 traffic on P-tunnels at the same time in steady state. This will be 446 the case when "hot root standby" mode is used (Section 4), and which 447 can also be the case if procedures of Section 3 are used and (a) the 448 rules determining the status of a tree are not the same on two 449 distinct downstream PEs or (b) the rule determining the status of a 450 tree depend on conditions local to a PE (e.g. the PE-P upstream link 451 being up). 453 7. IANA Considerations 455 Allocation is expected from IANA for the BGP "Standby PE" community. 456 (TBC) 458 [Note to RFC Editor: this section may be removed on publication as an 459 RFC.] 461 8. Security Considerations 462 9. Acknowledgements 464 The authors want to thank Ray Qiu for its review and useful feedback. 466 10. References 468 10.1. Normative References 470 [I-D.ietf-l3vpn-2547bis-mcast] 471 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 472 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 473 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-08 (work 474 in progress), March 2009. 476 [I-D.ietf-l3vpn-2547bis-mcast-bgp] 477 Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 478 Encodings and Procedures for Multicast in MPLS/BGP IP 479 VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-06 (work in 480 progress), March 2009. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 486 "Extensions to Resource Reservation Protocol - Traffic 487 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 488 Switched Paths (LSPs)", RFC 4875, May 2007. 490 10.2. Informative References 492 [I-D.ietf-mpls-mcast-cv] 493 Swallow, G., "Connectivity Verification for Multicast 494 Label Switched Paths", draft-ietf-mpls-mcast-cv-00 (work 495 in progress), April 2007. 497 [I-D.karan-mofrr] 498 Karan, A., Filsfils, C., and D. Farinacci, "Multicast only 499 Fast Re-Route", draft-karan-mofrr-00 (work in progress), 500 March 2009. 502 [I-D.katz-ward-bfd-multipoint] 503 Katz, D. and D. Ward, "BFD for Multipoint Networks", 504 draft-katz-ward-bfd-multipoint-02 (work in progress), 505 February 2009. 507 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 508 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 509 May 2005. 511 Authors' Addresses 513 Thomas Morin 514 France Telecom - Orange Labs 515 2, avenue Pierre Marzin 516 Lannion 22307 517 France 519 Email: thomas.morin@orange-ftgroup.com 521 Yakov Rekhter 522 Juniper Networks 523 1194 North Mathilda Ave. 524 Sunnyvale, CA 94089 525 U.S.A. 527 Email: yakov@juniper.net 529 Rahul Aggarwal 530 Juniper Networks 531 1194 North Mathilda Ave. 532 Sunnyvale, CA 94089 533 U.S.A. 535 Email: rahul@juniper.net 537 Wim Henderickx 538 Alcatel-Lucent 539 Copernicuslaan 50 540 Antwerp 2018 541 Belgium 543 Email: wim.henderickx@alcatel-lucent.com 544 Praveen Muley 545 Alcatel-Lucent 546 701 East Middlefield Rd 547 Mountain View, CA 94043 548 U.S.A. 550 Email: praveen.muley@alcatel-lucent.com