idnits 2.17.1 draft-ietf-isis-route-preference-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 == 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 31, 2015) is 3285 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Litkowski 5 Expires: October 2, 2015 Orange Business Service 6 S. Previdi 7 Cisco Systems 8 March 31, 2015 10 IS-IS Route Preference for Extended IP and IPv6 Reachability 11 draft-ietf-isis-route-preference-01.txt 13 Abstract 15 Existing specifications as regards route preference are not explicit 16 when applied to IPv4/IPv6 Extended Reachability Type/Length/Value 17 (TLVs). There are also inconsistencies in the definition of how the 18 up/down bit applies to route preference when the prefix advertisement 19 appears in Level 2 Link State Protocol Data Units (LSPs). This 20 document addresses these issues. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 2, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Use of the up/down Bit in Level 2 LSPs . . . . . . . . . . . 3 76 3. Types of Routes in IS-IS Supported by Extended Reachability 77 TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3.1. Types of Routes Supported by TLVs 135 and 235 . . . . . . 4 79 3.2. Types of Routes Supported by TLVs 236 and 237 . . . . . . 5 80 3.3. Order of Preference for all types of routes supported by 81 TLVs 135 and 235 . . . . . . . . . . . . . . . . . . . . 7 82 3.4. Order of Preference for all types of routes supported by 83 TLVs 236 and 237 . . . . . . . . . . . . . . . . . . . . 7 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 89 7.2. Informational References . . . . . . . . . . . . . . . . 8 90 Appendix A. Example Interoperability Issue . . . . . . . . . . . 8 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 93 1. Introduction 95 [RFC5302] defines the route preferences rules as they apply to TLVs 96 128 and 130. [RFC5305] introduced the IP Extended Reachability TLV 97 135 but did not explicitly adapt the route preference rules defined 98 in [RFC5302] for the new TLV. [RFC5308] defines the IPv6 99 Reachability TLV 236 and does include an explicit statement as 100 regards route preference - but the statement introduces use of the 101 up/down bit in advertisements which appear in Level 2 LSPs which is 102 inconsistent with statements made in [RFC5302] and [RFC5305]. This 103 document defines explicit route preference rules for TLV 135, revises 104 the route preferences rules for TLV 236, and clarifies the usage of 105 the up/down bit when it appears in TLVs in Level 2 LSPs. This 106 document is viewed as a clarification (NOT correction) of [RFC5302] 107 and [RFC5305] and a correction of the route preference rules defined 108 in [RFC5308] to be consistent with the rules for IPv4. It also makes 109 explicit that the same rules apply for the Multi-Topology(MT) 110 equivalent TLVs 235 and 237. 112 2. Use of the up/down Bit in Level 2 LSPs 114 The up/down bit was introduced in support of leaking prefixes 115 downwards in the IS-IS level hierarchy. Routes which are leaked 116 downwards have the bit set to 1. Such prefixes MUST NOT be leaked 117 upwards in the hierarchy. So long as we confine ourselves to a 118 single IS-IS instance and the current number of supported levels 119 (two) it is impossible to have a prefix advertised in a Level 2 LSP 120 and have the up/down bit set to 1. However, because [RFC5302] 121 anticipated a future extension to IS-IS which might support 122 additional levels it allowed for the possibility that the up/down bit 123 might be set in a Level-2 LSP and in support of easier migration in 124 the event such an extension was introduced Section 3.3 stated: 126 "...it is RECOMMENDED that implementations ignore the up/down bit in 127 L2 LSPs, and accept the prefixes in L2 LSPs regardless of whether the 128 up/down bit is set." 130 [RFC5305] addressed an additional case wherein an implementation 131 included support for multiple virtual routers running IS-IS in 132 different areas. In such a case it is possible to redistribute 133 prefixes between two IS-IS instances in the same manner that prefixes 134 are redistributed from other protocols into IS-IS. This introduced 135 the possibility that a prefix could be redistributed from Level 1 to 136 Level 1 (as well as between Level 2 and Level 2) and in the event the 137 redistributed route was leaked from Level 1 to Level 2 two different 138 routers in different areas would be advertising the same prefix into 139 the Level 2 sub-domain. To prevent this [RFC5305] specified in 140 Section 4.1: 142 "If a prefix is advertised from one area to another at the same 143 level, then the up/down bit SHALL be set to 1." 145 However, the statement in [RFC5302] that the up/down bit is ignored 146 in Level 2 LSPs is not altered by [RFC5305]. 148 The conclusion then is that there is no "L2 inter-area route" - and 149 indeed no such route type is defined by [RFC5302]. However, 150 [RFC5308] ignored this fact and introduced such a route type in 151 Section 5 when it specified a preference for " Level 2 down prefix". 152 This is an error which this document corrects. As changing the use 153 of the up/down bit in TLVs 236 and 237 may introduce interoperability 154 issues implementors may wish to support transition mechanisms from 155 the [RFC5308] behavior to the behavior specified in this document. 157 3. Types of Routes in IS-IS Supported by Extended Reachability TLVs 159 [RFC5302] is the authoritative reference for the types of routes 160 supported by TLVs 128 and 130. However, a number of attributes 161 supported by those TLVs are NOT supported by TLVs 135, 235, 236, 237. 162 Distinction between internal/external metrics is not supported. In 163 the case of IPv4 TLVs (135 and 235) the distinction between internal 164 and external route types is not supported. However the Prefix 165 Attribute Flags sub-TLV defined in [PFXATTR] reintroduces the 166 distinction between internal and external route types. The 167 definitions below include references to the relevant attribute bits 168 from [PFXATTR]. 170 3.1. Types of Routes Supported by TLVs 135 and 235 172 This section defines the types of route supported for IPv4 when using 173 TLV 135 [RFC5305] and/or TLV 235 [RFC5120]. The text follows as 174 closely as possible the original text from [RFC5302]. 176 L1 intra-area routes: These are advertised in L1 LSPs, in TLV 135 or 177 TLV 235. The up/down bit is set to 0. These IP prefixes are 178 directly connected to the advertising router. If the Prefix 179 Attribute Flags sub-TLV is included both the X-Flag and the R-Flag 180 are set to 0. 182 L1 external routes: These are advertised in L1 LSPs, in TLV 135 or 183 TLV 235. The up/down bit is set to 0. These IP prefixes are learned 184 from other protocols and are usually not directly connected to the 185 advertising router. If the Prefix Attribute Flags sub-TLV is 186 included the X-Flag is set to 1 and the R-Flag is set to 0. 188 L2 intra-area routes: These are advertised in L2 LSPs, in TLV 135 or 189 TLV 235. The up/down bit is set to 0. These IP prefixes are 190 directly connected to the advertising router. If the Prefix 191 Attribute Flags sub-TLV is included both the X-Flag and the R-Flag 192 are set to 0. 194 L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 135 195 or TLV 235. The up/down bit is set to 0. These IP prefixes are 196 learned via L1 routing and were derived during the L1 Shortest Path 197 First (SPF) computation from prefixes advertised in L1 LSPs in TLV 198 135 or TLV 235. If the Prefix Attribute Flags sub-TLV is included 199 the R-Flag is set to 1. 201 L2->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 135 202 or TLV 235. The up/down bit is set to 1 but is ignored and treated 203 as if it were set to 0. These IP prefixes are learned from another 204 IS-IS instance usually operating in another area. If the Prefix 205 Attribute Flags sub-TLV is included the X-Flag is set to 1 and the 206 R-Flag is set to 0. 208 L2 external routes: These are advertised in L2 LSPs, in TLV 135 or 209 TLV 235. The up/down bit is set to 0. These IP prefixes are learned 210 from other protocols and are usually not directly connected to the 211 advertising router. If the Prefix Attribute Flags sub-TLV is 212 included the X-Flag is set to 1 and the R-Flag is set to 0. 214 L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 135 215 or TLV 235. The up/down bit is set to 1. These IP prefixes are 216 learned via L2 routing and were derived during the L2 SPF computation 217 from prefixes advertised in TLV 135 or TLV 235. If the Prefix 218 Attribute Flags sub-TLV is included the R-Flag is set to 1. 220 L1->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 135 221 or TLV 235. The up/down bit is set to 1. These IP prefixes are 222 learned from another IS-IS instance usually operating in another 223 area. If the Prefix Attribute Flags sub-TLV is included the X-Flag 224 is set to 1 and the R-Flag is set to 0. 226 3.2. Types of Routes Supported by TLVs 236 and 237 228 This section defines the types of route supported for IPv6 when using 229 TLV 236 [RFC5308] and/or TLV 237 [RFC5120]. 231 L1 intra-area routes: These are advertised in L1 LSPs, in TLV 236 or 232 TLV 237. The up/down bit is set to 0. The external bit is set to 0. 233 These IPv6 prefixes are directly connected to the advertising router. 234 If the Prefix Attribute Flags sub-TLV is included the R-Flag is set 235 to 0. 237 L1 external routes: These are advertised in L1 LSPs, in TLV 236 or 238 TLV 237. The up/down bit is set to 0. The external bit is set to 1. 239 These IPv6 prefixes are learned from other protocols and are usually 240 not directly connected to the advertising router. If the Prefix 241 Attribute Flags sub-TLV is included the R-Flag is set to 0. 243 L2 intra-area routes: These are advertised in L2 LSPs, in TLV 236 or 244 TLV 237. The up/down bit is set to 0. The external bit is set to 0. 245 These IPv6 prefixes are directly connected to the advertising router. 246 If the Prefix Attribute Flags sub-TLV is included the R-Flag is set 247 to 0. 249 L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 236 250 or TLV 237. The up/down bit is set to 0. The external bit is set to 251 0. These IPv6 prefixes are learned via L1 routing and were derived 252 during the L1 Shortest Path First (SPF) computation from prefixes 253 advertised in L1 LSPs in TLV 236 or TLV 237. If the Prefix Attribute 254 Flags sub-TLV is included the R-Flag is set to 1. 256 L2 external routes: These are advertised in L2 LSPs, in TLV 236 or 257 TLV 237. The up/down bit is set to 0. the external bit is set to 1. 258 These IPv6 prefixes are learned from other protocols and are usually 259 not directly connected to the advertising router. If the Prefix 260 Attribute Flags sub-TLV is included the R-Flag is set to 0. 262 L1->L2 external routes: These are advertised in L2 LSPs, in TLV 236 263 or TLV 237. The up/down bit is set to 0. The external bit is set to 264 1. These IPv6 prefixes are learned via L1 routing and were derived 265 during the L1 Shortest Path First (SPF) computation from L1 external 266 routes advertised in L1 LSPs in TLV 236 or TLV 237. If the Prefix 267 Attribute Flags sub-TLV is included the R-Flag is set to 1. 269 L2->L2 inter-area routes. These are advertised in L2 LSPs, in TLV 270 236 or TLV 237. The up/down bit is set to 1 but is ignored and 271 treated as if it were set to 0. The external bit is set to 1. These 272 IP prefixes are learned from another IS-IS instance usually operating 273 in another area. If the Prefix Attribute Flags sub-TLV is included 274 the R-Flag is set to 0. 276 L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 236 277 or TLV 237. The up/down bit is set to 1. The external bit is set to 278 0. These IPv6 prefixes are learned via L2 routing and were derived 279 during the L2 SPF computation from prefixes advertised in TLV 236 or 280 TLV 237. If the Prefix Attribute Flags sub-TLV is included the 281 R-Flag is set to 1. 283 L2->L1 external routes: These are advertised in L1 LSPs, in TLV 236 284 or TLV 237. The up/down bit is set to 1. The external bit is set to 285 1. These IPv6 prefixes are learned via L2 routing and were derived 286 during the L2 SPF computation from prefixes advertised in TLV 236 or 287 TLV 237. If the Prefix Attribute Flags sub-TLV is included the 288 R-Flag is set to 1. 290 L1->L1 inter-area routes. These are advertised in L1 LSPs, in TLV 291 236 or TLV 237. The up/down bit is set to 1. The external bit is 292 set to 1. These IP prefixes are learned from another IS-IS instance 293 usually operating in another area. If the Prefix Attribute Flags 294 sub-TLV is included the R-Flag is set to 0. 296 3.3. Order of Preference for all types of routes supported by TLVs 135 297 and 235 299 This document defines the following route preferences for IPv4 routes 300 advertised in TLVs 135 or 235. Note that all types of routes listed 301 for a given preference are treated equally. 303 1. L1 intra-area routes; L1 external routes 305 2. L2 intra-area routes; L2 external routes; L1->L2 inter-area 306 routes; L2-L2 inter-area routes 308 3. L2->L1 inter-area routes; L1->L1 inter-area routes 310 3.4. Order of Preference for all types of routes supported by TLVs 236 311 and 237 313 This document defines the following route preferences for IPv6 routes 314 advertised in TLVs 236 or 237. Note that all types of routes listed 315 for a given preference are treated equally. 317 1. L1 intra-area routes; L1 external routes 319 2. L2 intra-area routes; L2 external routes; L1->L2 inter-area 320 routes; L1-L2 external routes;L2-L2 inter-area routes 322 3. L2->L1 inter-area routes; L2->L1 external routes;L1->L1 inter- 323 area routes 325 4. IANA Considerations 327 No IANA actions required. 329 5. Security Considerations 331 None. 333 6. Acknowledgements 335 The authors wish to thank Ahmed Bashandy for his insightful review. 337 7. References 339 7.1. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 345 Topology (MT) Routing in Intermediate System to 346 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 348 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 349 Distribution with Two-Level IS-IS", RFC 5302, October 350 2008. 352 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 353 Engineering", RFC 5305, October 2008. 355 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 356 2008. 358 7.2. Informational References 360 [PFXATTR] "IS-IS Prefix Attributes, draft-ginsberg-isis-prefix- 361 attributes-01(work in progress)", March 2015. 363 Appendix A. Example Interoperability Issue 365 This documents a real world interoperability issue which occurs 366 because implementations from different vendors have interpreted the 367 use of the up/down bit in Level 2 LSPs inconsistently. 369 L2 L2 L2 L2|L2 L2 370 10/8 - R0 ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8 371 | 372 Figure 1 374 Considering Figure 1, both R0 and R4 are advertising the prefix 10/8. 375 Two ISIS Level 2 instances are running on R3 to separate the network 376 into two areas. R3 is performing route-leaking and advertises 377 prefixes from R4 to the other Level 2 process. The network is using 378 extended metrics (TLV135 defined in [RFC5305]). R0 is advertising 379 10/8 with metric 2000 and R3 advertises 10/8 with metric 100. All 380 links have a metric of 1. When advertising 10/8 in its Level 2 LSP, 381 R3 sets the down bit as specified in [RFC5305]. 383 R1, R2 and R3 are from three different vendors (R1->Vendor1, 384 R2->Vendor2, R3->Vendor3). During interoperability testing, routing 385 loops are observed in this scenario. 387 o R2 has two possible paths to reach 10/8, Level 2 route with metric 388 2002, up/down bit is 0 (from R0) and Level 2 route with metric 389 101, up/down bit is 1 (from R3). R2 selects R1 as nexthop to 10/8 390 because it prefers the route which does NOT have up/down bit set. 392 o R3 has two possible paths to reach 10/8, Level 2 route with metric 393 2003, up/down bit is 0 (from R0) and Level 2 route with metric 394 101, up/down bit is 0 (from R4). R3 selects R4 as nexthop due to 395 lowest metric. 397 o R1 has two possible paths to reach 10/8, Level 2 route with metric 398 2001, up/down bit is 0 (from R0) and Level 2 metric 102, up/down 399 bit is 1 (from R3). R1 selects R2 as nexthop due to lowest 400 metric. 402 When R1 or R2 try to send traffic to 10/8, packets are looping due to 403 inconsistent routing decision between R1 and R2. 405 Authors' Addresses 407 Les Ginsberg 408 Cisco Systems 409 510 McCarthy Blvd. 410 Milpitas, CA 95035 411 USA 413 Email: ginsberg@cisco.com 415 Stephane Litkowski 416 Orange Business Service 418 Email: stephane.litkowski@orange.com 419 Stefano Previdi 420 Cisco Systems 421 Via Del Serafico 200 422 Rome 0144 423 Italy 425 Email: sprevidi@cisco.com