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