idnits 2.17.1 draft-bashandy-mpls-ldp-bgp-frr-00.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 114 has weird spacing: '...P/m. An ingr...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC5561' on line 326 == Unused Reference: '11' is defined on line 524, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 527, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 530, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 533, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-bashandy-bgp-edge-node-frr-02 == Outdated reference: A later version (-05) exists of draft-ietf-idr-best-external-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Bashandy 2 Internet Draft K. Raza 3 Intended status: Standards Track Cisco Systems 4 Expires: September 2012 March 5, 2012 6 LDP Extension for FRR Edge Node Protection in BGP-Free LDP Core 7 draft-bashandy-mpls-ldp-bgp-frr-00.txt 9 Abstract 11 Consider a BGP free core scenario with LDP running in the core. 12 Suppose the edge BGP speakers PE1 and PE2 know about a prefix P/m 13 via the external routers CE1 and CE2. If the edge LSR PE1 crashes 14 or becomes totally disconnected from the core, it is desirable for a 15 core LSR "P", that is carrying traffic to the failed edge LSR PE1, 16 to immediately restore traffic by re-routing packets destined to the 17 prefix P/m from the LSP terminating on PE1 to be forwarded over the 18 LSP terminating on PE2, until BGP reconverges. If the packets 19 originally flowing to the failed edge LSR PE1 are BGP labeled, then 20 the repairing core LSR P must swap the label (corresponding to 21 prefix P/m) advertised by the failed edge LSR PE1 with the label 22 advertised for the same prefix by the edge LSR PE2 before re-routing 23 the packets through an LSP terminating on PE2. To implement BGP edge 24 node protection in a BGP-free LDP core, this document proposes an 25 extension to LDP. This extension allows an LDP speaker running on a 26 Edge LSR Node (e.g. PE1) to inform the LDP speakers running on core 27 LSRs about the "Repair" edge LSR (e.g. PE2), as well as Repair LSR's 28 label for prefix P/m, if any. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 This document may contain material from IETF Documents or IETF 36 Contributions published or made publicly available before November 37 10, 2008. The person(s) controlling the copyright in some of this 38 material may not have granted the IETF Trust the right to allow 39 modifications of such material outside the IETF Standards Process. 40 Without obtaining an adequate license from the person(s) 41 controlling the copyright in such materials, this document may not 42 be modified outside the IETF Standards Process, and derivative 43 works of it may not be created outside the IETF Standards Process, 44 except to format it for publication as an RFC or to translate it 45 into languages other than English. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF), its areas, and its working groups. Note that 49 other groups may also distribute working documents as Internet- 50 Drafts. 52 Internet-Drafts are draft documents valid for a maximum of six 53 months and may be updated, replaced, or obsoleted by other 54 documents at any time. It is inappropriate to use Internet-Drafts 55 as reference material or to cite them other than as "work in 56 progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html 64 This Internet-Draft will expire on September 5, 2012. 66 Copyright Notice 68 Copyright (c) 2012 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with 76 respect to this document. Code Components extracted from this 77 document must include Simplified BSD License text as described in 78 Section 4.e of the Trust Legal Provisions and are provided without 79 warranty as described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction...................................................3 84 1.1. Conventions used in this document.........................4 85 1.2. Terminology...............................................4 86 1.3. Problem definition........................................5 87 2. The Proposed LDP Extension.....................................5 88 2.1. The LDP "BGP Repair Path status" Code.....................5 89 2.2. The LDP "BGP Repair Path Status" TLV......................6 90 2.3. LDP Capability Negotiation................................8 91 2.4. BGP Repair Status in a LDP Notification message...........8 92 3. BGP Repair Path Signaling Procedures...........................9 93 3.1. Signaling a BGP Repair Path...............................9 94 3.2. Updating a BGP Repair Path...............................10 95 3.3. Withdrawing a BGP Repair Path............................10 97 4. Security Considerations.......................................10 98 5. IANA Considerations...........................................11 99 6. Conclusions...................................................11 100 7. References....................................................11 101 7.1. Normative References.....................................11 102 7.2. Informative References...................................11 103 8. Acknowledgments...............................................12 105 1. Introduction 107 In a BGP free core, where traffic is tunneled between edge 108 routers/LSRs, (MP)BGP [2][3] speakers advertise reachability 109 information about prefixes to edge routers only. For labeled 110 address families, namely AFI/SAFI 1/4, 2/4, 1/128, and 2/128, an 111 edge LSR assigns local labels to prefixes and associates the local 112 label with each advertised prefix such as L3VPN [9], 6PE [10], and 113 Softwire [8]. Suppose that a given edge LSR is chosen as the best 114 next-hop for a prefix P/m. An ingress LSR receives a packet 115 destined for the prefix P/m from an external router, and sends the 116 packet to that egress LSR through an LSP terminating on the egress 117 LSR. If the prefix P/m is a BGP labeled prefix, the ingress LSR 118 pushes the BGP label advertised by the egress LSR before sending 119 the packet into the LDP LSP terminating on the egress LSR. Upon 120 receiving the packet from the core, the egress LSR takes the 121 appropriate forwarding decision based on the content of the packet 122 and/or the label(s) pushed on the packet. 124 In modern networks with redundancy in place, it is not uncommon to 125 have a prefix reachable via multiple edge routers. One example is 126 the best external path [7]. Another more common and widely deployed 127 scenario is L3VPN [9] with multi-homed VPN sites. As an example, 128 consider the L3VPN topology depicted in Figure 1. 130 PE1 131 \ 132 \ 133 \ 134 \ 135 CE1....... VPN prefix 136 / (10.0.0.0/8) 137 / 138 / 139 / 140 iPE ----- LDP core P----PE0 141 \ 142 \ 143 \ 144 \ 145 CE2....... VPN prefix 146 / (20.0.0.0/8) 147 / 148 / 149 / 150 PE2 152 Figure 1 VPN prefix reachable via multiple PEs 154 As illustrated in Figure 1, the edge router PE0 is the primary NH 155 for both 10.0.0.0/8 and 20.0.0.0/8. At the same time, both 156 10.0.0.0/8 and 20.0.0.0/8 are reachable through the other edge 157 routers PE1 and PE2, respectively. 159 1.1. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 163 this document are to be interpreted as described in RFC-2119 [1]. 165 In this document, these words will appear with that interpretation 166 only when in ALL CAPS. Lower case uses of these words are not to be 167 interpreted as carrying RFC-2119 significance. 169 1.2. Terminology 171 o LSR : Label Switched Router (In the context of this document, 172 this refers to a router doing label switching on LDP and/or BGP 173 labels) 175 o LSP: Label Switched Path 176 o Primary LSP: It is the LSP from the ingress PE to the primary 177 egress PE. This is the LDP implementation of the primary tunnel 178 defined in [6]. 180 o Repair LSP: It is the LSP from the repairing P router to the 181 repair egress PE. This is the LDP implementation of the repair 182 tunnel defined in [6]. 184 For the rest of the terms, refer to [6]. 186 1.3. Problem definition 188 The general problem for the example shown in Section 1. is specified 189 in [6]. The objective of this document is to specify an LDP [4] 190 extension to let the primary egress PE inform repairing core 191 router(s) about the repair path in an LDP core for both labeled and 192 unlabeled protected prefixes. In other words, this is an LDP-based 193 implementation of step 3 in [6]. Other problems, such as determining 194 the repair PE, detecting the protected PE (node/connectivity) 195 failure, and interactions between LDP and BGP on protected edge PE 196 LSR, are beyond the scope of this document. 198 2. The Proposed LDP Extension 200 As specified in [4] section 3.5.1, an LDP speaker can use LDP 201 Notification message to send its status or advisory information 202 towards a peer. An LDP Notification message consists of a Status TLV 203 and optional parameters, whereas "Status" TLV holds the status code 204 being signaled. For an egress PE LSR to convey repair path info (for 205 a BGP next-hop) to core LSRs, we propose to convey this information 206 via a LDP Notification message that carries a new status code in "LDP 207 Status" TLV, a new "BGP Repair Path Status" TLV and FEC TLV 208 (corresponding to BGP next-hop) as optional parameters. This 209 information is to be advertised to a peer only if the peer has 210 signaled the support for "Unrecognized Notification" capability a 211 specified in [5]. 213 The proposed extensions are described more in details in following 214 sub-sections. 216 2.1. The LDP "BGP Repair Path status" Code 218 A new LDP status code, namely "BGP Repair Path status" is defined 219 that is to be set in the "Status Code" field of the "Status TLV" as 220 defined in [4] section 3.4.6. 222 2.2. The LDP "BGP Repair Path Status" TLV 224 A new LDP TLV, namely "BGP Repair Path Status TLV", is defined to be 225 used in an LDP Notification message under optional parameters section 226 only if the Notification message status code is set to "BGP Repair 227 Path status". 229 This TLV is an implementation of the repair path defined in [6] and 230 is used to convey the information about the Repair edge LSR and its 231 associated BGP label, if any, for traffic destination prefix P/m. 232 This information is conveyed in the context of the protected primary 233 BGP nexthop [6], whose information is carried in the FEC TLV. This 234 document allows only one repair path per BGP nexthop. 236 The encoding of the "BGP Repair Path Status TLV" is as follows: 238 0 1 2 3 239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |U|F| Repair Path TLV Type(TBD) | Length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |A|L|P| Reserved | Address Family | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Repair PE Address (variable size) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Underlying Repair label (optional) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 2 Format of BGP Repair Path Status TLV 251 The fields are as follows 253 U/F: 255 Must be set to 1/0 respectively so that this TLV can be 256 ignored if not known or not supported. 258 Repair Path TLV Type: 260 IANA assigned TLV value 262 A bit 264 Indicates if Repair Path information is to be "added" or 265 "removed". MUST be set to 1 to signal addition of the 266 information, and set to signal addition of the information, 267 and set to 269 L Bit: 271 Indicates whether optional "Underlying Repair Label" [6] field 272 is present or not. Must be set to 1 if the TLV also 273 contains/encodes "Underlying Repair Label", else must be set 274 to 0. This bit MUST be set to 0 when A bit is set to 0. 276 P Bit: 278 If set, then the label in the "Underlying Repair label" sub 279 field MUST be pushed instead of swapped. The "P" bit has the 280 same semantics of the "Push" flag in [6]. If the "L" bit is 281 zero then the "P" bit MUST be set to zero. 283 Reserved: 285 MUST be zero on transmit and ignored in receipt 287 Address Family 289 Identical to the "Address Family" field used in encoding the 290 Prefix FEC element value specified in Section 3.4.1 in [4]. May 291 be different of the address family of the prefix in the FEC 293 Repair PE Address 295 The length of this field is dependent on the Address Family 296 field. This is either the 4 octet IPv4 address or 16 octet 297 IPv6 address of a host address belonging to repair PE. The 298 encoding of the Repair PE Address is identical to the encoding 299 of the value of the IPv4 or IPv6 Transport Address TLV 300 specified in Section 3.5.2 in [4]. This field encodes the 301 "Repair Next-hop" defined in [6]. 303 Underlying Repair Label (optional) 305 If included in the TLV, it is a single label defined in 306 accordance to Generic Label TLV specified in Section 3.4.2.1 in 307 [4]. This field encodes the "Underlying Repair Label" defined 308 in [6]. 310 Length 312 The length (in octets) of the TLV following the "Length" field. 313 For example, the length MUST be 8 with IPv4 Repair PE address 314 or 20 with IPv6 Repair PE address when L bit is set to 0, and 315 MUST be 12 and 24 octets otherwise for IPV4 and IPv6 address 316 families, respectively. 318 2.3. LDP Capability Negotiation 320 This BGP Repair Path information is to be computed by an edge PE LSR 321 under a user configuration control. Once computed, this information 322 can be unsolicitedly sent to core P LSRs for edge PE node protection, 323 and it is up to the receiving P LSR to store and use this information 324 to protect the edge PE LSR. 326 Given above procedures, no new LDP capability [RFC5561] negotiation 327 is needed between PE and P LSRs to support this feature extensions. 328 However, to ensure backward compatibility and deterministic behavior, 329 it is required that this information be sent to only those P LSRs 330 that support "Unrecognized Notification" capability as specified in 331 [5]. This will ensure that these new status and TLV does not cause 332 any issue at a receiving P LSR if not known or not supported, and be 333 discarded in accordance with "Unrecognized Notification" procedures. 335 2.4. BGP Repair Status in a LDP Notification message 337 The general format of an LDP Notification message that carries 338 information regarding BGP repair path is as follows: 340 0 1 2 3 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 |0| Notification (0x0001) | Message Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Message ID | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Status TLV | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | BGP Repair Path Status TLV | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | FEC TLV | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 3 : LDP Notification message with BGP Repair Status 355 The "Status TLV" status code is set to "BGP Repair Path status" to 356 indicate that the message is used to convey BGP Repair Path 357 information. When this status code is set, a Notification message 358 MUST contain both "BGP Repair Status TLV" and a "FEC TLV" in the 359 message. 361 Since this notification does not refer to any particular message, the 362 "Message ID" and "Message Type" fields in the "Status TLV" MUST be 363 set to 0. 365 The "BGP Repair Path Status TLV" is encoded as described earlier. 367 The FEC TLV MUST contain a single "Prefix FEC Element" that encodes 368 the BGP nexthop information as host prefix. This field encodes the 369 "Primary Next-hop" defined in [6]. 371 3. BGP Repair Path Signaling Procedures 373 To describe the signaling procedures clearly, let's first assume 374 that: 376 o Protected edge LSR is PE1, Repair edge LSR is PE2 and repairing 377 core LSR is P1 LSR router, and P2 is also a core LSR that does not 378 support BGP Repair Path functionality. 380 o IPv4 Host addresses for PE1 and PE2 are A1 and A2 respectively. 382 o Protected BGP IPv4 prefix is P/m. 384 o BGP label assigned by PE2 for P/m is L2. 386 o P1 and P2 LSR support LDP "Unrecognized Notification" Capability. 388 3.1. Signaling a BGP Repair Path 390 An operator enables this feature on PE1 using a configuration knob. 391 The PE1 computes Repair PE information (PE2 address A2, and PE2 BGP 392 label L2) for a given BGP prefix P/m. PE1 encodes the LDP 393 Notification to advertise the Repair path information to all those 394 core LSR peers (including P1/P2 LSRs) who have advertised 395 "Unrecognized Notification" Capability TLV for given LDP session. 397 The PE1 LSR encodes the following TLVs: 399 o "Status" TLV: status code is set to "BGP Repair Path status" 400 and "Message Type" and Message ID fields set to 0. 402 o "BGP Repair Path Status" TLV: This TLV is encoded with A-bit 403 set to 1, L-bit set to 1, P-bit set to 0, Address Family set 404 to 1 (IPv4), "Repair PE Address" field populated with A2, and 405 "Repair PE's Label" field set to L2. 407 o "FEC" TLV: This TLV is encoded with a single "Prefix FEC 408 Element" whose Address Family is set to 1 (IPv4) to indicate 409 IPV4 prefix, and prefix P/m encoded accordingly. 411 After encoding these TLVs, PE1 LSR bundles them in an LDP 412 Notification message, as shown in Figure 3, and sends them to its 413 upstream core peer P1 and P2 LSRs. 415 On receipt of this information, P1 stores this information and uses 416 this to fast reroute the BGP destined traffic to PE2 upon PE2 417 node/connectivity failure detection. P2, on the other hand, does not 418 recognize this new status in the LDP Notification message and hence 419 discards it silently. 421 In order to be able to protect primary BGP nexthops, it is required 422 that the repairing P LSR (P1) must have a LSP terminating on Repair 423 PE host prefix (as indicated by "Repair PE Address" field in the 424 received "BGP Repair Path Status" TLV). 426 3.2. Updating a BGP Repair Path 428 The repair path information is identified by 430 o the "primary next-hop" encoded in the "FEC TLV" shown in 431 Figure 3 and, 433 o the "Repair Next-hop" encoded in the "Repair PE Address" shown 434 in Figure 2. 436 Once a repair path has been signaled to P core LSR, it can be updated 437 by simply sending another LDP Notification message using the 438 procedures described in the previous section. 440 Upon receipt of a new repair path information, the LDP receiver (P1 441 LSR) MUST discard any previously learnt Repair information from the 442 sending PE1 LSR, and update it with the most recently received. 444 3.3. Withdrawing a BGP Repair Path 446 Once a repair path has been signaled to P core LSR, it can be 447 withdrawn by simply sending another LDP Notification message using 448 the procedures described in the previous section with following 449 changes: 451 o Set A-bit, L-bit, and P-bit in "BGP Repair Path Status" TLV to 452 0 454 o No "Underlying Repair Label" field included 456 Upon receipt of a withdrawal of a repair path, the LDP receiver (P1 457 LSR) MUST discard any previously learnt Repair information from the 458 sending PE1 LSR for a given BGP prefix. 460 4. Security Considerations 462 No additional security risk is introduced by using the mechanisms 463 proposed in this document 465 5. IANA Considerations 467 This document introduces the following new protocol elements that 468 require code point assignment by IANA: 470 o "BGP Repair Path status" status code from "LDP Status Code Name 471 Space" registry (requested code point: 0x00000050) 473 o "BGP Repair Path Status TLV" from "LDP TLV Type Name Space" 474 registry (requested code point: 0x050F) 476 6. Conclusions 478 This document proposes a an LDP extension that allows an egress PE 479 to advertise a repair path consisting of a repair egress PE and an 480 underlying label to repairing core router. Advertising this 481 information to core routers allows core routers to provide FRR 482 protection against primary egress PE node failure while keeping the 483 core BGP-free. 485 7. References 487 7.1. Normative References 489 [1] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, March 1997. 492 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 493 4 (BGP-4), RFC 4271, January 2006 495 [3] Bates, T., Chandra, R., Katz, D., and Rekhter Y., 496 "Multiprotocol Extensions for BGP", RFC 4760, January 2007 498 [4] Anderson, L., Minei, I., and Thomas, B., "LDP 499 Specifications", RFC 5036, October 2007 501 [5] R. Asati, P. Mohapatra, E. Chen, B. Thomas, " Signaling LDP 502 Label Advertisement Completion", RFC5919, August 2010 504 7.2. Informative References 506 [6] Bashandy, A., Pithawala, B., and Patel, K., "Scalable BGP FRR 507 Protection against Edge Node Failure", draft-bashandy-bgp- 508 edge-node-frr-02.txt, January 2012 510 [7] Marques,P., Fernando, R., Chen, E, Mohapatra, P., 511 "Advertisement of the best external route in BGP", draft- 512 ietf-idr-best-external-02.txt, April 2004. 514 [8] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 515 Framework", RFC 5565, June 2009. 517 [9] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 518 Networks (VPNs)", RFC 4364, February 2006. 520 [10] De Clercq, J. , Ooms, D., Prevost, S., Le Faucheur, F., 521 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 522 Edge Routers (6PE)", RFC 4798, February 2007 524 [11] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 525 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 527 [12] Shand, S., and Bryant, S., "IP Fast Reroute", RFC5714, 528 January 2010 530 [13] Shand, M. and S. Bryant, "A Framework for Loop-Free 531 Convergence", RFC 5715, January 2010. 533 [14] Rosen, E., Biswanathan, A., and Callon, A. "Multiprotocol 534 Label Switching Architecture", RFC3031, January 2001 536 8. Acknowledgments 538 Special thanks to Keyur Patel and Alton Lo for the valuable help. 540 This document was prepared using 2-Word-v2.0.template.dot. 542 Authors' Addresses 544 Ahmed Bashandy 545 Cisco Systems 546 170 West Tasman Dr, San Jose, CA 95134 547 Email: bashandy@cisco.com 549 Kamran Raza 550 Cisco Systems, 551 2000 Innovation Dr., Kanata, ON K2K 3E8, Canada 552 EMail: skraza@cisco.com