idnits 2.17.1 draft-bashandy-isis-bgp-edge-node-frr-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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This document does NOT require that the address family of the primary and repair next-hop be identical. However an implementation MAY require that the "Primary Next-Hop" and "Repair Next-hop" fields belong to the same address family. Thus a core P router MAY ignore the "IPv4/IPv6 Repair Egress Path" TLVs if the "AF-different" bit is set. Similarly, a primary egress PE MAY NOT advertise the "IPv4/IPv6 Repair Egress Path" TLVs with the field "AF-Different" set. == 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 (August 31, 2012) is 4246 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-03) exists of draft-bashandy-bgp-edge-node-frr-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Bashandy 2 Internet Draft Cisco Systems 3 Intended status: Standards Track 4 Expires: February 2013 August 31, 2012 6 IS-IS Extension for BGP FRR Protection against Edge Node Failure 7 draft-bashandy-isis-bgp-edge-node-frr-01.txt 9 Abstract 11 Consider a BGP free core scenario where traffic is tunneled between 12 edge routers. Suppose the edge BGP speakers PE1, PE2,..., PEn know 13 about a prefix P/m via the external routers CE1, CE2,..., CEm. If 14 the edge router PEi crashes or becomes totally disconnected from the 15 core, it desirable for a core router "P" that is carrying traffic to 16 the failed edge router PEi to immediately restore traffic by re- 17 routing packets originally tunneled to PEi and destined to the prefix 18 P/m to one of the other edge routers that advertised P/m, say PEj, 19 until BGP re-converges. If the packets originally flowing to the 20 failed edge router PEi are labeled, then the repairing core router P 21 router may need to swap, push, or pop the label advertised by the 22 failed edge router PEi with another label before re-routing the 23 packet through an LSP terminating PEj so that PEj can correctly 24 forward the packet. The document proposes an extension to IS-IS 25 protocol to inform core routers about the repair edge router PEj and, 26 for labeled packets, the label that needs to be pushed/swapped before 27 sending the packet into the tunnel terminating on PEj 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 This document may contain material from IETF Documents or IETF 35 Contributions published or made publicly available before November 36 10, 2008. The person(s) controlling the copyright in some of this 37 material may not have granted the IETF Trust the right to allow 38 modifications of such material outside the IETF Standards Process. 39 Without obtaining an adequate license from the person(s) 40 controlling the copyright in such materials, this document may not 41 be modified outside the IETF Standards Process, and derivative 42 works of it may not be created outside the IETF Standards Process, 43 except to format it for publication as an RFC or to translate it 44 into languages other than English. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as Internet- 49 Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six 52 months and may be updated, replaced, or obsoleted by other 53 documents at any time. It is inappropriate to use Internet-Drafts 54 as reference material or to cite them other than as "work in 55 progress." 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/ietf/1id-abstracts.txt 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html 63 This Internet-Draft will expire on February 31, 2013. 65 Copyright Notice 67 Copyright (c) 2012 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with 75 respect to this document. Code Components extracted from this 76 document must include Simplified BSD License text as described in 77 Section 4.e of the Trust Legal Provisions and are provided without 78 warranty as described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction...................................................3 83 1.1. Conventions used in this document.........................4 84 1.2. Terminology...............................................4 85 1.3. Problem definition........................................5 86 2. The Proposed IS-IS Extension...................................5 87 3. Operation of the Repair Egress Path TLVs.......................5 88 3.1. Structure of the Repair Egress Path TLVs..................5 89 3.2. Semantics of the Repair Path TLV..........................7 90 4. Example........................................................8 91 5. Security Considerations........................................9 92 6. IANA Considerations............................................9 93 7. Conclusions....................................................9 94 8. References.....................................................9 95 8.1. Normative References......................................9 96 8.2. Informative References...................................10 97 9. Acknowledgments...............................................10 98 Appendix A. Modification History.................................11 99 A.1. Changes from 00..........................................11 101 1. Introduction 103 In a BGP free core, where traffic is tunneled between edge routers, 104 BGP speakers advertise reachability information about prefixes to 105 edge routers only. For labeled address families, namely AFI/SAFI 106 1/4, 2/4, 1/128, and 2/128, an edge router assigns local labels to 107 prefixes and associates the local label with each advertised prefix 108 such as L3VPN [10], 6PE [11], and Softwire [9]. Suppose that a 109 given edge router is chosen as the best next-hop for a prefix P/m. 110 An ingress router that receives a packet from an external router 111 and destined for the prefix P/m sends the packet through a tunnel 112 to that egress router. If the prefix P/m is a labeled prefix, the 113 ingress router pushes the label advertised by the egress router 114 before sending the packet into the tunnel terminating on the egress 115 router. Upon receiving the packet from the core, the egress router 116 takes the appropriate forwarding decision based on the content of 117 the packet and/or the label pushed on the packet. 119 In modern networks with redundancy in place, it is not uncommon to 120 have a prefix reachable via multiple edge routers. One example is 121 the best external path [8]. Another more common and widely deployed 122 scenario is L3VPN [10] with multi-homed VPN sites. As an example, 123 consider the L3VPN topology depicted in Figure 1. 125 PE1 .............+ 126 | 127 +--------+------------+ 128 | | 129 | VPN 1 Network | 130 | | 131 +---+-----------------+ 132 | 133 /----- CE1....... VPN prefix 134 / (10.0.0.0/8) 135 / 136 BGP-free core P--------PE0 137 \ 138 \ (20.0.0.0/8) 139 \------CE2....... VPN prefix 140 | 141 +---+-----------------+ 142 | | 143 | VPN 2 Network | 144 | | 145 +--------+------------+ 146 | 147 PE2 .............+ 149 Figure 1 VPN prefix reachable via multiple PEs 151 As illustrated in Figure 1, the edge router PE0 is the primary NH 152 for both 10.0.0.0/8 and 20.0.0.0/8. At the same time, both 153 10.0.0.0/8 and 20.0.0.0/8 are reachable through the other edge 154 routers PE1 and PE2, respectively. 156 1.1. Conventions used in this document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 160 this document are to be interpreted as described in RFC-2119 [1]. 162 In this document, these words will appear with that interpretation 163 only when in ALL CAPS. Lower case uses of these words are not to be 164 interpreted as carrying RFC-2119 significance. 166 1.2. Terminology 168 Refer to [7]. 170 1.3. Problem definition 172 The general problem for the example shown in Section 1. is 173 specified in [7]. The objective of this document is to specify an 174 IS-IS [2] [3][4][5] extension to let the primary egress PE inform 175 repairing core router(s) about the repair path [7] in a BGP-free 176 core for both labeled and unlabeled protected prefixes. Other 177 problems, such as determining the repair PE or the repair path or 178 failure detection, are beyond the scope of this document. 180 2. The Proposed IS-IS Extension 182 This document specifies two new TLVs, namely "IPv4 Repair Egress 183 Path" and "IPv6 Repair Egress Path". The new IPv4 and IPv6 Repair 184 Egress Path TLVs identify the primary egress next-hop and its 185 corresponding "Repair Egress Path" specified in [7] for IPv4 primary 186 next-hop [7] and IPv6 primary next-hop [7], respectively 188 The encoding of the proposed TLVs is as follows 190 TLV Type (Value TBD): 192 1 octet identifying the IPv4 or IPv6 Repair Egress Path TLV code 193 point. The code point value is assigned by IANA from the IANA "IS- 194 IS TLV Code point Registry". 196 The code point for "IPv4 Repair Egress Path" means the "Primary 197 next-hop" sub-field contains an IPv4 address. The code point for 198 "IPv6 Repair Egress Path" means "Primary next-hop" sub-field 199 contains an IPv6 address. 201 Length: 203 The length of the value field in multiples of 1 octet 205 Value (variable length): 207 The value specifies the IPv4 Repair Egress Path. Details in 208 Section 3. 210 3. Operation of the Repair Egress Path TLVs 212 3.1. Structure of the Repair Egress Path TLVs 214 The "Value" field of the proposed TLVs contains more than one "repair 215 tuple". Each "repair tuple" consists of the following sub-fields in 216 the following order 218 o L bit 219 If set, then the repair path contains the underlying repair 220 label 222 o P bit 224 If set, then the label in the "Underlying Repair label" sub- 225 field MUST be pushed instead of swapped. More details about 226 this field in Section 3.2. 228 o AF-different Bit (D bit for simplicity) 230 If set, the "Primary next-hop" sub-field contains an IPv4 231 address while the "Repair Next-hop" contains an IPv6 address or 232 vice versa. 234 o MT bit (M bit for simplicity) 236 If set, then the sub-fields " MTID-Num" and "MT-List" exist 238 o Reserved (Mandatory) 240 This is a 4 bits field that MUST be zero by transmitter(s) and 241 ignored by receiver(s) 243 o Primary next-hop (Mandatory) 245 This is either a 4 octet IPv4 address or 16 octet IPv6 address 246 representing the protected primary next-hop as defined in [7]. 248 o Repair next-hop (Mandatory) 250 This is the repair next-hop as defined in [7]. It has the same 251 syntax as "Primary next-hop" sub-field 253 o Underlying Repair label (optional) 255 If the L bit is set, then this field MUST contain the 256 underlying repair label as defined in [7]. The length of this 257 field is 3 octets. 259 o MTID-Num (Optional, 1 octet) 261 The number of elements in the sub-field "MT-List". If the "MT" 262 bit is set, then this field MUST exist and contain a value 263 greater than zero 265 o MT-List (optional, variable length) 266 The size of the field is multiple of 2 octets. It represents a 267 list of topology IDs. Each entry in the list represents a 268 topology ID and has the same format and semantics of the "R" 269 bits and the "MT ID" field in TLVs 235 and 237 defined in [6]. 270 The semantics of the "MT-List" are specified in Section 3.2. If 271 the "MT" bit is set, then this field MUST exist and contain at 272 least one entry. 274 The "value" field of the proposed "IPv4/IPv6 Repair Egress Path" TLV 275 MAY contain more than one "repair tuple", each consisting of the sub- 276 fields defined in this section. See Section 4. provides an example of 277 how the "value" field may look like. 279 3.2. Semantics of the Repair Path TLV 281 The Repair egress Path TLV is an implementation of the repair path 282 defined in [7]. This section explains the IS-IS specific use. 284 The "Primary next-hop" and "Repair next-hop" subfield in specified in 285 this document identifies the exit point of the primary and repair 286 tunnels [7], respectively. 288 The semantics of the "P" bit is identical to the semantics of the 289 "Push" flag in [7]. 291 The same values of "Primary next-hop" and "Repair next-hop" subfield 292 MUST NOT appear more than once in the "IPv4/IPv6 egress repair path" 293 TLVs in the same LSP 295 The "MT-LIST" represents a list of topology IDs to be used to 296 calculate the path taken by the repair tunnel. The semantics of the 297 "MT-LIST" sub-field is as follows. If the repairing router decides to 298 calculate a repair tunnel towards the "Repair next-hop", then the 299 path taken by the tunnel SHOULD be calculated according to one of the 300 topologies specified in the list "MT-LIST". If the path taken by the 301 repair tunnel does not satisfy the conditions specified in [7], then 302 the repairing not SHOULD NOT install this repair tunnel in the 303 forwarding plane. 305 The addresses specified in the "Primary next-hop" and "Repair next- 306 hop" sub-fields SHOULD be covered by (possibly different) 307 reachability TLVs. Furthermore, if the "MT-LIST" sub-field exists, 308 then the prefix covering the "Repair next-hop" SHOULD be advertised 309 in a TLV of type 235 or 237 and the "MT ID" sub-field value in the 310 235 or 237 TLV SHOULD be identical to one of the topology IDs in the 311 "MT-LIST" sub-field defined in this document. 313 This document does NOT require that the address family of the primary 314 and repair next-hop be identical. However an implementation MAY 315 require that the "Primary Next-Hop" and "Repair Next-hop" fields 316 belong to the same address family. Thus a core P router MAY ignore 317 the "IPv4/IPv6 Repair Egress Path" TLVs if the "AF-different" bit is 318 set. Similarly, a primary egress PE MAY NOT advertise the "IPv4/IPv6 319 Repair Egress Path" TLVs with the field "AF-Different" set. 321 For a protected Primary BGP next-hop allocated according to [7], the 322 TLVs defined in this document support no more than one repair egress 323 path per repair tuple. However a protected PE MAY advertise more than 324 one repair path for the same protected next-hop by advertising more 325 than one "repair tuple" for the same primary NH but with different 326 repair paths. If a repairing core router receives more than one 327 repair path for the same protected next-hop, the repairing core 328 router MAY choose one repair path. The method of choosing a repair 329 path is beyond the scope of this document. 331 4. Example 333 Figure 2 illustrates an example for the "value" field "IPv4 Repair 334 Egress Path". 336 Number of Octets 337 +--+--+--+--+--------------------+ 338 |0 |0 |0 |0 | Zero | 1 339 +--+--+--+--+--------------------+ 340 | 1.1.1.1 | 4 341 +--------------------------------+ 342 | 2.2.2.2 | 4 343 +--+--+--+--+--------------------+ 344 |1 |0 |0 |1 | Zero | 1 345 +--+--+--+--+--------------------+ 346 | 1.1.1.1 | 4 347 +--------------------------------+ 348 | 3.3.3.3 | 4 349 +--------------------------------+ 350 | 0x20b1 | 3 351 +--------------------------------+ 352 | 2 | 1 353 +--+--+--+--+--------------------+ 354 |0 |0 |0 |0 | 0x2b1 | 2 355 +--+--+--+--+--------------------+ 356 |0 |0 |0 |0 | 0x1ac | 2 357 +--+--+--+--+--------------------+ 359 Figure 2 Example of "Value" field for "IPv4 Repair Egress Path" TLV 361 Figure 2 illustrates the case where "IPv4 Repair Egress Path" has two 362 "repair tuples". The first one represents primary and repair path 363 without MT support and without any label. The second repair tuple is 364 the case where the repair path is labeled using the underlying repair 365 label 0x20b1 and the repair next-hop belongs to two topologies. 367 5. Security Considerations 369 No additional security risk is introduced by using the mechanisms 370 proposed in this document 372 6. IANA Considerations 374 This document introduces two new TLVs that require code point 375 assignment by: 377 o IPv4 Repair Egress Path TLV type to be assigned from the IANA "IS- 378 IS TLV Codepoints Registry". 380 o IPv6 Repair Egress Path TLV type to be assigned from the IANA "IS- 381 IS TLV Codepoints Registry". 383 7. Conclusions 385 This document proposes an IS-IS extension that allows an egress PE 386 to advertise a repair path consisting of another repair egress PE 387 and possibly an underlying label to repairing core routers. 388 Advertising this information to core routers allows core routers to 389 provide FRR protection against primary egress PE node failure or 390 complete disconnect from the core while keeping the core BGP-free. 392 8. References 394 8.1. Normative References 396 [1] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [2] International Organization for Standardization, "Intermediate 400 system to Intermediate system intra-domain routing 401 information exchange protocol for use in conjunction with the 402 protocol for providing the connectionless-mode Network 403 Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 404 2002. 406 [3] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual 407 environments", RFC 1195, December 1990. 409 [4] Li, T., and Smit, H., "IS-IS Extensions for for Traffic 410 Engineering", RFC5305, October 2008 412 [5] Hopps, C. "Routing IPv6 with IS-IS", RFC5308, October 2008 414 [6] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 415 Topology (MT) Routing in IS-IS", RFC 5120, February 2008. 417 8.2. Informative References 419 [7] Bashandy, A., Pithawala, B., Patel, P., "Scalable BGP FRR 420 Protection against Edge Node Failure", draft-bashandy-bgp- 421 edge-node-frr-02.txt, January 2012 423 [8] Marques,P., Fernando, R., Chen, E, Mohapatra, P., Gredler, 424 H., "Advertisement of the best external route in BGP", draft- 425 ietf-idr-best-external-05.txt, January 2012. 427 [9] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 428 Framework", RFC 5565, June 2009. 430 [10] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 431 Networks (VPNs)", RFC 4364, February 2006. 433 [11] De Clercq, J. , Ooms, D., Prevost, S., Le Faucheur, F., 434 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 435 Edge Routers (6PE)", RFC 4798, February 2007 437 9. Acknowledgments 439 Special thanks to Les Ginsberg, Keyur Patel, and Anton Smirnov for 440 the valuable help. 442 This document was prepared using 2-Word-v2.0.template.dot. 444 Authors' Addresses 446 Ahmed Bashandy 447 Cisco Systems 448 170 West Tasman Dr, San Jose, CA 95134 449 Email: bashandy@cisco.com 451 Appendix A. Modification History 453 A.1. Changes from 00 455 Some editorial Changes