idnits 2.17.1 draft-ietf-isis-rfc2966bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1195, but the abstract doesn't seem to directly say this. It does mention RFC1195 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC1195, updated by this document, for RFC5378 checks: 1990-12-01) -- 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 (April 25, 2008) is 5816 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. 'ISO-10589' -- Obsolete informational reference (is this intentional?): RFC 2966 (Obsoleted by RFC 5302) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets T. Li 3 Internet-Draft Redback Networks, Inc. 4 Obsoletes: 2966 (if approved) H. Smit 5 Updates: 1195 (if approved) 6 Intended status: Standards Track T. Przygienda 7 Expires: October 27, 2008 Z2 Sagl 8 April 25, 2008 10 Domain-wide Prefix Distribution with Two-Level IS-IS 11 draft-ietf-isis-rfc2966bis-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 October 27, 2008. 38 Abstract 40 This document describes extensions to the Intermediate System to 41 Intermediate System (IS-IS) protocol to support optimal routing 42 within a two-level domain. The IS-IS protocol is specified in ISO 43 10589, with extensions for supporting IPv4 (Internet Protocol) 44 specified in RFC 1195. This document replaces RFC 2966. 46 This document extends the semantics presented in RFC 1195 so that a 47 routing domain running with both level 1 and level 2 Intermediate 48 Systems (IS) [routers] can distribute IP prefixes between level 1 and 49 level 2 and vice versa. This distribution requires certain 50 restrictions to insure that persistent forwarding loops do not form. 51 The goal of this domain-wide prefix distribution is to increase the 52 granularity of the routing information within the domain. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Motivations for domain-wide prefix distribution . . . . . 3 58 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.3. Requirements language . . . . . . . . . . . . . . . . . . 6 60 2. Proposed syntax and semantics for L2->L1 inter-area routes . . 6 61 2.1. Clarification of external route-type and external 62 metric-type . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.2. Definition of external IP prefixes in level 1 LSPs . . . . 7 64 3. Types of IP routes in IS-IS and their order of preference . . 8 65 3.1. Overview of all types of IP prefixes in IS-IS Link 66 State PDUs . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2. Order of preference for all types of IP routes in IS-IS . 11 68 3.3. Additional notes on what prefixes to accept or 69 advertise . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4. Inter-operability with older implementations . . . . . . . . . 12 71 5. Comparisons with other proposals . . . . . . . . . . . . . . . 13 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 Intellectual Property and Copyright Statements . . . . . . . . . . 16 80 1. Introduction 82 This document describes extensions to the Intermediate System to 83 Intermediate System (IS-IS) protocol to support optimal routing 84 within a two-level domain. The IS-IS protocol is specified in 85 [ISO-10589], with extensions for supporting IPv4 (Internet Protocol) 86 specified in [RFC1195]. 88 This document replaces [RFC2966], which was an Informational 89 document. This document is on the standards track. No other 90 intentional substantive changes have been made. 92 This document extends the semantics presented in RFC 1195 so that a 93 routing domain running with both level 1 and level 2 Intermediate 94 Systems (IS) [routers] can distribute IP prefixes between level 1 and 95 level 2 and vice versa. This distribution requires certain 96 restrictions to insure that persistent forwarding loops do not form. 97 The goal of this domain-wide prefix distribution is to increase the 98 granularity of the routing information within the domain. 100 An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) 101 can be partitioned into multiple level 1 (L1) areas, and a level 2 102 (L2) connected subset of the topology that interconnects all of the 103 L1 areas. Within each L1 area, all routers exchange link state 104 information. L2 routers also exchange L2 link state information to 105 compute routes between areas. 107 RFC 1195 defines the Type, Length and Value (TLV) tuples that are 108 used to transport IPv4 routing information in IS-IS. RFC 1195 also 109 specifies the semantics and procedures for interactions between 110 levels. Specifically, routers in a L1 area will exchange information 111 within the L1 area. For IP destinations not found in the prefixes in 112 the L1 database, the L1 router should forward packets to the nearest 113 router that is in both L1 and L2 (i.e., an L1L2 router) with the 114 "attached bit" set in its L1 Link State Protocol Data Unit (LSP). 116 Also per RFC 1195, an L1L2 router should be manually configured with 117 a set of prefixes that summarizes the IP prefixes reachable in that 118 L1 area. These summaries are injected into L2. RFC 1195 specifies 119 no further interactions between L1 and L2 for IPv4 prefixes. 121 1.1. Motivations for domain-wide prefix distribution 123 The mechanisms specified in RFC 1195 are appropriate in many 124 situations, and lead to excellent scalability properties. However, 125 in certain circumstances, the domain administrator may wish to 126 sacrifice some amount of scalability and distribute more specific 127 information than is described by RFC 1195. This section discusses 128 the various reasons why the domain administrator may wish to make 129 such a tradeoff. 131 One major reason for distributing more prefix information is to 132 improve the quality of the resulting routes. A well know property of 133 prefix summarization or any abstraction mechanism is that it 134 necessarily results in a loss of information. This loss of 135 information in turn results in the computation of a route based upon 136 less information, which will frequently result in routes that are not 137 optimal. 139 A simple example can serve to demonstrate this adequately. Suppose 140 that a L1 area has two L1L2 routers that both advertise a single 141 summary of all prefixes within the L1 area. To reach a destination 142 inside the L1 area, any other L2 router is going to compute the 143 shortest path to one of the two L1L2 routers for that area. Suppose, 144 for example, that both of the L1L2 routers are equidistant from the 145 L2 source, and that the L2 source arbitrarily selects one L1L2 146 router. This router may not be the optimal router when viewed from 147 the L1 topology. In fact, it may be the case that the path from the 148 selected L1L2 router to the destination router may traverse the L1L2 149 router that was not selected. If more detailed topological 150 information or more detailed metric information was available to the 151 L2 source router, it could make a more optimal route computation. 153 This situation is symmetric in that an L1 router has no information 154 about prefixes in L2 or within a different L1 area. In using the 155 nearest L1L2 router, that L1L2 is effectively injecting a default 156 route without metric information into the L1 area. The route 157 computation that the L1 router performs is similarly suboptimal. 159 Besides the optimality of the routes computed, there are two other 160 significant drivers for the domain wide distribution of prefix 161 information. 163 When a router learns multiple possible paths to external destinations 164 via BGP, it will select only one of those routes to be installed in 165 the forwarding table. One of the factors in the BGP route selection 166 is the IGP cost to the BGP next hop address. Many ISP networks 167 depend on this technique, which is known as "shortest exit routing". 168 If a L1 router does not know the exact IGP metric to all BGP speakers 169 in other L1 areas, it cannot do effective shortest exit routing. 171 The third driver is the current practice of using the IGP (IS-IS) 172 metric as part of the BGP Multi-Exit Discriminator (MED). The value 173 in the MED is advertised to other domains and is used to inform other 174 domains of the optimal entry point into the current domain. Current 175 practice is to take the IS-IS metric and insert it as the MED value. 177 This tends to cause external traffic to enter the domain at the point 178 closest to the exit router. Note that the receiving domain MAY, 179 based upon policy, choose to ignore the MED that is advertised. 180 However, current practice is to distribute the IGP metric in this way 181 in order to optimize routing wherever possible. This is possible in 182 current networks that only are a single area, but becomes problematic 183 if hierarchy is to be installed into the network. This is again 184 because the loss of end-to-end metric information means that the MED 185 value will not reflect the true distance across the advertising 186 domain. Full distribution of prefix information within the domain 187 would alleviate this problem as it would allow accurate computation 188 of the IS-IS metric across the domain, resulting in an accurate value 189 presented in the MED. 191 1.2. Scalability 193 The disadvantage to performing the domain-wide prefix distribution 194 described above is that it has an impact to the scalability of IS-IS. 195 Areas within IS-IS help scalability in that LSPs are contained within 196 a single area. This limits the size of the link state database, that 197 in turn limits the complexity of the shortest path computation. 199 Further, the summarization of the prefix information aids scalability 200 in that the abstraction of the prefix information removes the sheer 201 number of data items to be transported and the number of routes to be 202 computed. 204 It should be noted quite strongly that the distribution of prefixes 205 on a domain wide basis impacts the scalability of IS-IS in the second 206 respect. It will increase the number of prefixes throughout the 207 domain. This will result in increased memory consumption, 208 transmission requirements and computation requirements throughout the 209 domain. 211 It must also be noted that the domain-wide distribution of prefixes 212 has no effect whatsoever on the first aspect of scalability, namely 213 the existence of areas and the limitation of the distribution of the 214 link state database. 216 Thus, the net result is that the introduction of domain-wide prefix 217 distribution into a formerly flat, single area network is a clear 218 benefit to the scalability of that network. However, it is a 219 compromise and does not provide the maximum scalability available 220 with IS-IS. Domains that choose to make use of this facility should 221 be aware of the tradeoff that they are making between scalability and 222 optimality and provision and monitor their networks accordingly. 223 Normal provisioning guidelines that would apply to a fully 224 hierarchical deployment of IS-IS will not apply to this type of 225 configuration. 227 1.3. Requirements language 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [RFC2119]. 233 2. Proposed syntax and semantics for L2->L1 inter-area routes 235 This document defines the syntax of how to advertise level 2 routes 236 in level 1 LSPs. The encoding is an extension of the encoding in RFC 237 1195. 239 To some extent, in IS-IS the level 2 backbone can be seen as a 240 separate area itself. RFC 1195 defines that L1L2 routers can 241 advertise IP routes that were learned via L1 routing into L2. These 242 routes can be regarded as inter-area routes. RFC 1195 defines that 243 these L1->L2 inter-area routes must be advertised in L2 LSPs in the 244 "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 245 routes are also advertised in L2 LSPs in an "IP Internal Reachability 246 Information" TLV. Therefore, L1->L2 inter-area routes are 247 indistinguishable from L2 intra-area routes. 249 RFC 1195 does not define L2->L1 inter-area routes. A simple 250 extension would be to allow a L1L2 router to advertise routes learned 251 via L2 routing in its L1 LSP. However, to prevent routing-loops, 252 L1L2 routers must not advertise L2->L1 inter-area routes that they 253 learn via L1 routing, back into L2. Therefore, there must be a way 254 to distinguish L2->L1 inter-area routes from L1 intra-area routes. 255 [RFC3784] defines the "up/down bit" for this purpose in the extended 256 IP reachability TLV (TLV 135). RFC 1195 defines TLVs 128 and 130 to 257 contain IP routes. TVLs 128 and 130 have a metric field that 258 consists of 4 TOS metrics. The first metric, the so-called "default 259 metric", has the high-order bit reserved (bit 8). Routers must set 260 this bit to zero on transmission, and ignore it on receipt. 262 This document redefines this high-order bit in the default metric 263 field in TLVs 128 and 130 to be the up/down bit. L1L2 routers MUST 264 set this bit to one for prefixes that are derived from L2 routing and 265 are advertised into L1 LSPs. The bit MUST be set to zero for all 266 other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit 267 set that are learned via L1 routing, MUST NOT be advertised by L1L2 268 routers back into L2. 270 2.1. Clarification of external route-type and external metric-type 272 RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is 273 defined as "IP Internal Reachability Information", and should be used 274 to carry IP prefixes that are directly connected to IS-IS routers. 275 TLV 130 is defined as "IP External Reachability Information", and 276 should be used to carry routes learned from outside the IS-IS domain. 277 RFC 1195 documents TLV type 130 only for level 2 LSPs. 279 RFC 1195 also defines two types of metrics. Metrics of the internal 280 metric-type should be used when the metric is comparable to metrics 281 used to weigh links inside the ISIS domain. Metrics of the external 282 metric-type should be used if the metric of an IP prefix cannot be 283 directly compared to internal metrics. External metric-type can only 284 be used for external IP prefixes. A direct result is that metrics of 285 external metric-type should never be seen in TLV 128. 287 To prevent confusion, this document states again that when a router 288 computes IP routes, it MUST give the same preference to IP routes 289 advertised in an "IP Internal Reachability Information" TLV and IP 290 routes advertised in an "IP External Reachability Information" TLV. 291 RFC 1195 states this quite clearly in the note in paragraph 3.10.2, 292 item 2c). This document does not alter this rule of preference. 294 NOTE: Internal routes (routes to destinations announced in the "IP 295 Internal Reachability Information" field), and external routes 296 using internal metrics (routes to destinations announced in the 297 "IP External Reachability Information" field, with a metric of 298 type "internal") are treated identically for the purpose of the 299 order of preference of routes, and the Dijkstra calculation. 301 However, IP routes advertised in "IP External Reachability 302 Information" with external metric-type MUST be given less preference 303 than the same IP routes advertised with internal-metric type, 304 regardless of the value of the metrics. 306 While IS-IS routers MUST NOT give different preference to IP prefixes 307 learned via "IP Internal Reachability Information" and "IP External 308 Reachability Information" when executing the Dijkstra calculation, 309 routers that implement multiple IGPs are free to use this distinction 310 between internal and external routes when comparing routes derived 311 from different IGPs for inclusion in their global RIB. 313 2.2. Definition of external IP prefixes in level 1 LSPs 315 RFC 1195 does not define the "IP External Reachability Information" 316 TLV for L1 LSPs. However, there is no reason why an IS-IS 317 implementation could not allow for redistribution of external routes 318 into L1. Some IS-IS implementations already allow network 319 administrators to do this. This document loosens the restrictions in 320 RFC 1195, and allows for the inclusion of the "IP External 321 Reachability Information" TLV in L1 LSPs. 323 RFC 1195 defines that IP routes learned via L1 routing must always be 324 advertised in L2 LSPs in a "IP Internal Reachability Information" 325 TLV. Now that this document allows "IP External Reachability 326 Information" TLVs in L1 LSPs, and allows for the advertisement of 327 routes learned via L2 routing into L1, the above rule needs an 328 extension. 330 When a L1L2 router advertises a L1 route into L2, where that L1 route 331 was learned via a prefix advertised in an "IP External Reachability 332 Information" TLV, that L1L2 router SHOULD advertise that prefix in 333 its L2 LSP within an "IP External Reachability Information" TLV. L1 334 routes learned via an "IP Internal Reachability Information" TLV 335 SHOULD still be advertised within a "IP Internal Reachability 336 Information" TLV. These rules should also be applied when 337 advertising IP routes derived from L2 routing into L1. Of course in 338 this case also the up/down bit MUST be set. 340 RFC 1195 defines that if a router sees the same external prefix 341 advertised by two or more routers with the same external metric, it 342 must select the route that is advertised by the router that is 343 closest to itself. It should be noted that now that external routes 344 can be advertised from L1 into L2, and vice versa, that the router 345 that advertises an external prefix in its LSP might not be the router 346 that originally injected this prefix into the IS-IS domain. 347 Therefore, it is less useful to advertise external routes with 348 external metrics into other levels. 350 3. Types of IP routes in IS-IS and their order of preference 352 RFC 1195 and this document defines several ways of advertising IP 353 routes in IS-IS. There are four variables involved. 355 1. The level of the LSP in which the route is advertised. There are 356 currently two possible values: level 1 and level 2 358 2. The route-type, which can be derived from the type of TLV in 359 which the prefix is advertised. Internal routes are advertised 360 in IP Internal Reachability Information TLVs (TLV 128), and 361 external routes are advertised in IP External Reachability 362 Information TLVs (TLV 130). 364 3. The metric-type: Internal or External. The metric-type is 365 derived from the Internal/External metric-type bit in the metric 366 field (bit 7). 368 4. The fact whether this route is leaked down in the hierarchy, and 369 thus can not be advertised back up. This information can be 370 derived from the newly defined up/down bit in the default metric 371 field. 373 3.1. Overview of all types of IP prefixes in IS-IS Link State PDUs 375 The combination IP Internal Reachability Information and external 376 metric-type is not allowed. Also the up/down bit MUST NOT be set in 377 L2 LSPs. This leaves us with 8 different types of IP advertisements 378 in IS-IS. However, there are more than 8 reasons for IP prefixes to 379 be advertised in IS-IS. The following tables describe the types of 380 IP prefixes and how they are encoded. 382 L1 intra-area routes: These are advertised in L1 LSPs, in TLV 128. 383 The up/down bit is set to zero, metric-type is internal metric. 384 These IP prefixes are directly connected to the advertising 385 router. 387 L1 external routes: These are advertised in L1 LSPs, in TLV 130. 388 The up/down bit is set to zero, metric-type is internal metric. 389 These IP prefixes are learned from other IGPs, and are usually not 390 directly connected to the advertising router. 392 L2 intra-area routes: These are advertised in L2 LSPs, in TLV 128. 393 The up/down bit is set to zero, metric-type is internal metric. 394 These IP prefixes are directly connected to the advertising 395 router. These prefixes can not be distinguished from L1->L2 396 inter-area routes. 398 L2 external routes: These are advertised in L2 LSPs, in TLV 130. 399 The up/down bit is set to zero, metric-type is internal metric. 400 These IP prefixes are learned from other IGPs, and are usually not 401 directly connected to the advertising router. These prefixes can 402 not be distinguished from L1->L2 inter-area external routes. 404 L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 405 128. The up/down bit is set to zero, metric-type is internal 406 metric. These IP prefixes are learned via L1 routing, and were 407 derived during the L1 SPF computation from prefixes advertised in 408 L1 LSPs in TLV 128. These prefixes can not be distinguished from 409 L2 intra-area routes. 411 L1->L2 inter-area external routes: These are advertised in L2 LSPs, 412 in TLV 130. The up/down bit is set to zero, metric-type is 413 internal metric. These IP prefixes are learned via L1 routing, 414 and were derived during the L1 SPF computation from prefixes 415 advertised in L1 LSPs in TLV 130. These prefixes can not be 416 distinguished from L2 external routes. 418 L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 419 128. The up/down bit is set to one, metric-type is internal 420 metric. These IP prefixes are learned via L2 routing, and were 421 derived during the L2 SPF computation from prefixes advertised in 422 TLV 128. 424 L2->L1 inter-area external routes: These are advertised in L1 LSPs, 425 in TLV 130. The up/down bit is set to one, metric-type is 426 internal metric. These IP prefixes are learned via L2 routing, 427 and were derived during the L2 SPF computation from prefixes 428 advertised in L2 LSPs in TLV 130. 430 L1 external routes with external metric: These are advertised in L1 431 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is 432 external metric. These IP prefixes are learned from other IGPs, 433 and are usually not directly connected to the advertising router. 435 L2 external routes with external metric: These are advertised in L2 436 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is 437 external metric. These IP prefixes are learned from other IGPs, 438 and are usually not directly connected to the advertising router. 439 These prefixes can not be distinguished from L1->L2 inter-area 440 external routes with external metric. 442 L1->L2 inter-area external routes with external metric: These are 443 advertised in L2 LSPs, in TLV 130. The up/down bit is set to 444 zero, metric-type is external metric. These IP prefixes are 445 learned via L1 routing, and were derived during the L1 SPF 446 computation from prefixes advertised in L1 LSPs in TLV 130 with 447 external metrics. These prefixes can not be distinguished from L2 448 external routes with external metric. 450 L2->L1 inter-area external routes with external metric: These are 451 advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, 452 metric-type is external metric. These IP prefixes are learned via 453 L2 routing, and were derived during the L1 SPF computation from 454 prefixes advertised in L2 LSPs in TLV 130 with external metrics. 456 3.2. Order of preference for all types of IP routes in IS-IS 458 Unfortunately IS-IS cannot depend on metrics alone for route 459 selection. Some types of routes must always be preferred over 460 others, regardless of the costs that were computed in the Dijkstra 461 calculation. One of the reasons for this is that inter-area routes 462 can only be advertised with a maximum metric of 63. Another reason 463 is that this maximum value of 63 does not mean infinity (e.g. like a 464 hop count of 16 in RIP denotes unreachable). Introducing a value for 465 infinity cost in IS-IS inter-area routes would introduce counting- 466 to-infinity behavior via two or more L1L2 routers, which would have a 467 bad impact on network stability. 469 The order of preference of IP routes in IS-IS is based on a few 470 assumptions. 472 o RFC 1195 defines that routes derived from L1 routing are preferred 473 over routes derived from L2 routing. 475 o The note in RFC 1195 paragraph 3.10.2, item 2c) defines that 476 internal routes with internal metric-type and external prefixes 477 with internal metric-type have the same preference. 479 o RFC 1195 defines that external routes with internal metric-type 480 are preferred over external routes with external metric type. 482 o Routes derived from L2 routing are preferred over L2->L1 routes 483 derived from L1 routing. 485 Based on these assumptions, this document defines the following route 486 preferences. 488 1. L1 intra-area routes with internal metric; L1 external routes 489 with internal metric 491 2. L2 intra-area routes with internal metric; L2 external routes 492 with internal metric; L1->L2 inter-area routes with internal 493 metric; L1->L2 inter-area external routes with internal metric 495 3. L2->L1 inter-area routes with internal metric; L2->L1 inter-area 496 external routes with internal metric 498 4. L1 external routes with external metric 500 5. L2 external routes with external metric; L1->L2 inter-area 501 external routes with external metric 503 6. L2->L1 inter-area external routes with external metric 505 3.3. Additional notes on what prefixes to accept or advertise 507 Section 3.1 enumerates all used IP route types in IS-IS. Besides 508 these defined route types, the encoding used would allow for a few 509 more potential combinations. One of them is the combination of "IP 510 Internal Reachability Information" and external metric type. This 511 combination SHOULD NOT be used when building an LSP. Upon receipt of 512 an IP prefix with this combination, routers MUST ignore this prefix. 513 Another issue would be the usage of the up/down bit in L2 LSPs. 514 Because IS-IS is currently defined with two levels of hierarchy, 515 there should never be a need to set the up/down bit in L2 LSPs. 516 However, if IS-IS would ever be extended with more than two levels of 517 hierarchy, L2-only (or L1L2) routers will need to be able to accept 518 L2 IP routes with the up/down bit set. Therefore, it is RECOMMENDED 519 that implementations ignore the up/down bit in L2 LSPs, and accept 520 the prefixes in L2 LSPs regardless whether the up/down bit is set. 521 This will allow for simpler migration once more than two levels of 522 hierarchy are defined. 524 Another detail that implementors should be aware of is the fact that 525 L1L2 routers SHOULD only advertise in their L2 LSP those L1 routes 526 that they use for forwarding themselves. They SHOULD NOT 527 unconditionally advertise into L2 all prefixes from LSPs in the L1 528 database. 530 Not all prefixes need to be advertised up or down the hierarchy. 531 Implementations might allow for additional manual filtering or 532 summarization to further bring down the number of inter-area prefixes 533 they advertise in their LSPs. It is also RECOMMENDED that the 534 default configuration of L1L2 routers is to not advertise any L2 535 routes into L1 (see also Section 4). 537 4. Inter-operability with older implementations 539 The solution in this document is not fully compatible with RFC 1195. 540 It is an extension to RFC 1195. If routers do not use the new 541 functionality of external L1 routes, nor L2->L1 inter-area routes, 542 older implementations that strictly follow RFC 1195 will be 543 compatible with newer implementations that follow this document. 545 Implementations that do not accept the "IP External Reachability 546 Information" TLV in L1 LSPs will not be able to compute external L1 547 routes. This could cause routing loops between L1-only routers that 548 do understand external L1 routes for a particular destination, and 549 L1-only routers that use the default route pointing the closest 550 attached L1L2 router for that destination. 552 Implementations that follow RFC 1195 should ignore bit 8 in the 553 default metric field when computing routes. Therefore, even older 554 implementations that do not know of the up/down bit should be able to 555 accept the new L2->L1 inter-area routes. These older implementations 556 will install the new L2->L1 inter-area routes as L1 intra-area 557 routes, but that in itself does not cause routing loops among L1-only 558 routers. 560 However, it is vital that the up/down bit is recognized by L1L2 561 routers. As has been stated before, L1L2 routers MUST NOT advertise 562 L2->L1 inter-area routes back into L2. Therefore, if L2 routes are 563 advertised down into an L1 area, it is required that all L1L2 routers 564 in that area run software that understands the new up/down bit. 565 Older implementations that follow RFC 1195 and do not understand the 566 new up/down bit will treat the L2->L1 inter-area routes as L1 intra- 567 area routes, and they will advertise these routes back into L2. This 568 can cause routing loops, sub-optimal routing or extra routing 569 instability. For this reason it is RECOMMENDED that implementations 570 by default do not advertise any L2 routes into L1. Implementations 571 SHOULD force the network administrator to manually configure L1L2 572 routers to advertise any L2 routes into L1. 574 5. Comparisons with other proposals 576 In [RFC3784], a new TLV is defined to transport IP prefix 577 information. This TLV format also defines an up/down bit to allow 578 for L2->L1 inter-area routes. RFC 3784 also defines a new TLV to 579 describe links. Both TLVs have wider metric space, and have the 580 possibility to define sub-TLVs to advertise extra information 581 belonging to the link or prefix. The wider metric space in IP prefix 582 TLVs allows for more granular metric information about inter-area 583 path costs. To make full use of the wider metric space, network 584 administrators must deploy both new TLVs at the same time. 586 Deployment of RFC 3784 requires an upgrade of all routers in the 587 network and a transition to the new TLVs. Such a network-wide 588 upgrade and transition might not be an easy task. In this case, the 589 solution defined in this document, which requires only an upgrade of 590 L1L2 routers in selected areas, might be a good alternative to the 591 solution defined in 3784. 593 6. Security Considerations 595 This document raises no new security issues for IS-IS. 597 7. IANA Considerations 599 This memo includes no request to IANA. 601 8. References 603 8.1. Normative References 605 [ISO-10589] 606 ISO, "Intermediate System to Intermediate System Intra- 607 Domain Routeing Exchange Protocol for use in Conjunction 608 with the Protocol for Providing the Connectionless-mode 609 Network Service (ISO 8473)", International Standard 10589: 610 2002, Second Edition, 2002. 612 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 613 dual environments", RFC 1195, December 1990. 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 8.2. Informative References 620 [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix 621 Distribution with Two-Level IS-IS", RFC 2966, 622 October 2000. 624 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 625 System (IS-IS) Extensions for Traffic Engineering (TE)", 626 RFC 3784, June 2004. 628 Authors' Addresses 630 Tony Li 631 Redback Networks, Inc. 632 300 Holger Way 633 San Jose, CA 95134 634 USA 636 Phone: +1 408 750 5160 637 Email: tony.li@tony.li 638 Henk Smit 640 Email: hhw.smit@xs4all.nl 642 Tony Przygienda 643 Z2 Sagl 644 Via Tersaggio 20 645 CH-6949 Comano 647 Email: prz@net4u.ch 649 Full Copyright Statement 651 Copyright (C) The IETF Trust (2008). 653 This document is subject to the rights, licenses and restrictions 654 contained in BCP 78, and except as set forth therein, the authors 655 retain all their rights. 657 This document and the information contained herein are provided on an 658 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 659 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 660 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 661 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 662 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 663 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 665 Intellectual Property 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed to 669 pertain to the implementation or use of the technology described in 670 this document or the extent to which any license under such rights 671 might or might not be available; nor does it represent that it has 672 made any independent effort to identify any such rights. Information 673 on the procedures with respect to rights in RFC documents can be 674 found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use of 679 such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository at 681 http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at 687 ietf-ipr@ietf.org.