idnits 2.17.1 draft-ietf-isis-domain-wide-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 647 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2000) is 8657 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) ** Obsolete normative reference: RFC 1142 (ref. '1') (Obsoleted by RFC 7142) == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. '3') Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Li 2 INTERNET DRAFT Procket Networks 4 Tony Przygienda 5 Redback 7 Henk Smit 8 Procket Networks 9 July 2000 11 Domain-wide Prefix Distribution with Two-Level IS-IS 13 15 Status 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC 2026. 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 1.0 Abstract 38 This document describes extensions to the IS-IS protocol to support 39 optimal routing within a two-level domain. The IS-IS protocol is 40 specified in ISO 10589 [1], with extensions for supporting IPv4 41 specified in RFC 1195 [2]. 43 This document extends the semantics presented in RFC 1195 so that a 44 routing domain running with both level 1 and level 2 Intermediate 45 Systems (IS) [routers] can distribute IP prefixes between level 1 and 46 level 2 and vice versa. This distribution requires certain 47 restrictions to insure that persistent forwarding loops do not form. 48 The goal of this domain-wide prefix distribution is to increase the 49 granularity of the routing information within the domain. 51 2.0 Introduction 53 An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) 54 can be partitioned into multiple level 1 (L1) areas, and a level 2 55 (L2) connected subset of the topology that interconnects all of the 56 L1 areas. Within each L1 area, all routers exchange link state 57 information. L2 routers also exchange L2 link state information to 58 compute routes between areas. 60 RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are 61 used to transport IPv4 routing information in IS-IS. RFC 1195 also 62 specifies the semantics and procedures for interactions between 63 levels. Specifically, routers in a L1 area will exchange information 64 within the L1 area. For IP destinations not found in the prefixes in 65 the L1 database, the L1 router should forward packets to the nearest 66 router that is in both L1 and L2 (i.e., an L1L2 router) with the 67 "attached bit" set in its L1 Link State Protocol Data Unit (LSP). 69 Also per RFC 1195, an L1L2 router should be manually configured with 70 a set of prefixes that summarizes the IP prefixes reachable in that 71 L1 area. These summaries are injected into L2. RFC 1195 specifies 72 no further interactions between L1 and L2 for IPv4 prefixes. 74 2.1 Motivations for domain-wide prefix distribution 76 The mechanisms specified in RFC 1195 are appropriate in many 77 situations, and lead to excellent scalability properties. However, 78 in certain circumstances, the domain administrator may wish to 79 sacrifice some amount of scalability and distribute more specific 80 information than is described by RFC 1195. This section discusses 81 the various reasons why the domain administrator may wish to make 82 such a tradeoff. 84 One major reason for distributing more prefix information is to 85 improve the quality of the resulting routes. A well know property of 86 prefix summarization or any abstraction mechanism is that it 87 necessarily results in a loss of information. This loss of 88 information in turn results in the computation of a route based upon 89 less information, which will frequently result in routes that are not 90 optimal. 92 A simple example can serve to demonstrate this adequately. Suppose 93 that a L1 area has two L1L2 routers that both advertise a single 94 summary of all prefixes within the L1 area. To reach a destination 95 inside the L1 area, any other L2 router is going to compute the 96 shortest path to one of the two L1L2 routers for that area. Suppose, 97 for example, that both of the L1L2 routers are equidistant from the 98 L2 source, and that the L2 source arbitrarily selects one L1L2 99 router. This router may not be the optimal router when viewed from 100 the L1 topology. In fact, it may be the case that the path from the 101 selected L1L2 router to the destination router may traverse the L1L2 102 router that was not selected. If more detailed topological 103 information or more detailed metric information was available to the 104 L2 source router, it could make a more optimal route computation. 106 This situation is symmetric in that an L1 router has no information 107 about prefixes in L2 or within a different L1 area. In using the 108 nearest L1L2 router, that L1L2 is effectively injecting a default 109 route without metric information into the L1 area. The route 110 computation that the L1 router performs is similarly suboptimal. 112 Besides the optimality of the routes computed, there are two other 113 significant drivers for the domain wide distribution of prefix 114 information. 116 When a router learns multiple possible paths to external destinations 117 via BGP, it will select only one of those routes to be installed in 118 the forwarding table. One of the factors in the BGP route selection 119 is the IGP cost to the BGP next hop address. Many ISP networks 120 depend on this technique, which is known as "shortest exit routing". 121 If a L1 router does not know the exact IGP metric to all BGP speakers 122 in other L1 areas, it cannot do effective shortest exit routing. 124 The third driver is the current practice of using the IGP (IS-IS) 125 metric as part of the BGP Multi-Exit Discriminator (MED). The value 126 in the MED is advertised to other domains and is used to inform other 127 domains of the optimal entry point into the current domain. Current 128 practice is to take the IS-IS metric and insert it as the MED value. 129 This tends to cause external traffic to enter the domain at the point 130 closest to the exit router. Note that the receiving domain may, 131 based upon policy, choose to ignore the MED that is advertised. 132 However, current practice is to distribute the IGP metric in this way 133 in order to optimize routing wherever possible. This is possible in 134 current networks that only are a single area, but becomes problematic 135 if hierarchy is to be installed into the network. This is again 136 because the loss of end-to-end metric information means that the MED 137 value will not reflect the true distance across the advertising 138 domain. Full distribution of prefix information within the domain 139 would alleviate this problem as it would allow accurate computation 140 of the IS-IS metric across the domain, resulting in an accurate value 141 presented in the MED. 143 2.2 Scalability 145 The disadvantage to performing the domain-wide prefix distribution 146 described above is that it has an impact to the scalability of IS-IS. 147 Areas within IS-IS help scalability in that LSPs are contained within 148 a single area. This limits the size of the link state database, that 149 in turn limits the complexity of the shortest path computation. 151 Further, the summarization of the prefix information aids scalability 152 in that the abstraction of the prefix information removes the sheer 153 number of data items to be transported and the number of routes to be 154 computed. 156 It should be noted quite strongly that the distribution of prefixes 157 on a domain wide basis impacts the scalability of IS-IS in the second 158 respect. It will increase the number of prefixes throughout the 159 domain. This will result in increased memory consumption, 160 transmission requirements and computation requirements throughout the 161 domain. 163 It must also be noted that the domain-wide distribution of prefixes 164 has no effect whatsoever on the first aspect of scalability, namely 165 the existence of areas and the limitation of the distribution of the 166 link state database. 168 Thus, the net result is that the introduction of domain-wide prefix 169 distribution into a formerly flat, single area network is a clear 170 benefit to the scalability of that network. However, it is a 171 compromise and does not provide the maximum scalability available 172 with IS-IS. Domains that choose to make use of this facility should 173 be aware of the tradeoff that they are making between scalability and 174 optimality and provision and monitor their networks accordingly. 175 Normal provisioning guidelines that would apply to a fully 176 hierarchical deployment of IS-IS will not apply to this type of 177 configuration. 179 3.0 Proposed syntax and semantics for L2->L1 inter-area routes 181 This document defines the syntax of how to advertise level 2 routes 182 in level 1 LSPs. The encoding is an extension of the encoding in RFC 183 1195. 185 To some extent, in IS-IS the level 2 backbone can be seen as a 186 separate area itself. RFC 1195 defines that L1L2 routers can 187 advertise IP routes that were learned via L1 routing into L2. These 188 routes can be regarded as inter-area routes. RFC 1195 defines that 189 these L1->L2 inter-area routes must be advertised in L2 LSPs in the 190 "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 191 routes are also advertised in L2 LSPs in an "IP Internal Reachability 192 Information" TLV. Therefor L1->L2 inter-area routes are 193 indistinguishable from L2 intra-area routes. 195 RFC 1195 does not define L2->L1 inter-area routes. A simple extension 196 would be to allow a L1L2 router to advertise routes learned via L2 197 routing in its L1 LSP. However, to prevent routing-loops, L1L2 198 routers must never advertise L2->L1 inter-area routes that they learn 199 via L1 routing, back into L2. Therefor there must be a way to 200 distinguish L2->L1 inter-area routes from L1 intra-area routes. 201 Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for this 202 purpose. RFC 1195 defines TLVs 128 and 130 to contain IP routes. 203 TVLs 128 and 130 have a metric field that consists of 4 TOS metrics. 204 The first metric, the so-called "default metric", has the high-order 205 bit reserved (bit 8). Routers must set this bit to zero on 206 transmission, and ignore it on receipt. 208 This document redefines this high-order bit in the default metric 209 field in TLVs 128 and 130 to be the up/down bit. L1L2 routers must 210 set this bit to one for prefixes that are derived from L2 routing and 211 are advertised into L1 LSPs. The bit must be set to zero for all 212 other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit 213 set that are learned via L1 routing, must never be advertised by L1L2 214 routers back into L2. 216 3.1 Clarification of external route-type and external metric-type 218 RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is 219 defined as "IP Internal Reachability Information", and should be used 220 to carry IP prefixes that are directly connected to IS-IS routers. 221 TLV 130 is defined as "IP External Reachability Information", and 222 should be used to carry routes learned from outside the IS-IS domain. 223 RFC 1195 documents TLV type 130 only for level 2 LSPs. 225 RFC 1195 also defines two types of metrics. Metrics of the internal 226 metric-type should be used when the metric is comparable to metrics 227 used to weigh links inside the ISIS domain. Metrics of the external 228 metric-type should be used if the metric of an IP prefix cannot be 229 directly compared to internal metrics. External metric-type can only 230 be used for external IP prefixes. A direct result is that metrics of 231 external metric-type should never be seen in TLV 128. 233 To prevent confusion, this document states again that when a router 234 computes IP routes, it must give the same preference to IP routes 235 advertised in an "IP Internal Reachability Information" TLV and IP 236 routes advertised in an "IP External Reachability Information" TLV. 237 RFC 1195 states this quite clearly in the note in paragraph 3.10.2, 238 item 2c). This document does not alter this rule of preference. 240 NOTE: Internal routes (routes to destinations announced in the 241 "IP Internal Reachability Information" field), and external 242 routes using internal metrics (routes to destinations announced 243 in the "IP External Reachability Information" field, with a 244 metric of type "internal") are treated identically for the 245 purpose of the order of preference of routes, and the Dijkstra 246 calculation. 248 However, IP routes advertised in "IP External Reachability 249 Information" with external metric-type must be given less preference 250 than the same IP routes advertised with internal-metric type, 251 regardless of the value of the metrics. 253 While IS-IS routers must not give different preference to IP prefixes 254 learned via "IP Internal Reachability Information" and "IP External 255 Reachability Information" when executing the Dijkstra calculation, 256 routers that implement multiple IGPs are free to use this distinction 257 between internal and external routes when comparing routes derived 258 from different IGPs for inclusion in their global RIB. 260 3.2 Definition of external IP prefixes in level 1 LSPs 262 RFC 1195 does not define the "IP External Reachability Information" 263 TLV for L1 LSPs. However, there is no reason why an IS-IS 264 implementation could not allow for redistribution of external routes 265 into L1. Some IS-IS implementations already allow network 266 administrators to do this. This document loosens the restrictions in 267 RFC 1195, and allows for the inclusion of the "IP External 268 Reachability Information" TLV in L1 LSPs. 270 RFC 1195 defines that IP routes learned via L1 routing must always be 271 advertised in L2 LSPs in a "IP Internal Reachability Information" 272 TLV. Now that this document allows "IP External Reachability 273 Information" TLVs in L1 LSPs, and allows for the advertisement of 274 routes learned via L2 routing into L1, the above rule needs a 275 extensions. 277 When a L1L2 router advertises a L1 route into L2, where that L1 route 278 was learned via a prefix advertised in a "IP External Reachability 279 Information" TLV, that L1L2 router should advertise that prefix in 280 its L2 LSP within an "IP External Reachability Information" TLV. L1 281 routes learned via an "IP Internal Reachability Information" TLV 282 should still be advertised within a "IP Internal Reachability 283 Information" TLV. These rules should also be applied when advertising 284 IP routes derived from L2 routing into L1. Of course in this case 285 also the up/down bit must be set. 287 RFC 1195 defines that if a router sees the same external prefix 288 advertised by two or more routers with the same external metric, it 289 must select the route that is advertised by the router that is 290 closest to itself. It should be noted that now that external routes 291 can be advertised from L1 into L2, and vice versa, that the router 292 that advertises an external prefix in its LSP might not be the router 293 that originally injected this prefix into the IS-IS domain. Therefor 294 it is less useful to advertise external routes with external metrics 295 into other levels. 297 4.0 Types of IP routes in IS-IS and their order of preference 299 RFC 1195 and this document defines several ways of advertising IP 300 routes in IS-IS. There are four variables involved. 302 1) The level of the LSP in which the route is advertised. 303 There are currently two possible values: level 1 and level 2 304 2) The route-type, which can be derived from the type of TLV in which 305 the prefix is advertised. 306 Internal routes are advertised in IP Internal Reachability Information 307 TLVs (TLV 128), and external routes are advertised in IP External 308 Reachability Information TLVs (TLV 130). 309 3) The metric-type: Internal or External. The metric-type is derived from 310 the Internal/External metric-type bit in the metric field (bit 7). 311 4) The fact whether this route is leaked down in the hierarchy, and 312 thus can not be advertised back up. This information can be derived 313 from the newly defined up/down bit in the default metric field. 315 4.1 Overview of all types of IP prefixes in IS-IS Link State PDUs 317 The combination IP Internal Reachability Information and external 318 metric-type is not allowed. Also the up/down bit is never set in L2 319 LSPs. This leaves us with 8 different types of IP advertisements in 320 IS-IS. However, there are more than 8 reasons for IP prefixes to be 321 advertised in IS-IS. The following tables describe the types of IP 322 prefixes and how they are encoded. 324 1) L1 intra-area routes 326 These are advertised in L1 LSPs, in TLV 128. 327 The up/down bit is set to zero, metric-type is internal metric. 328 These IP prefixes are directly connected to the advertising router. 330 2) L1 external routes 332 These are advertised in L1 LSPs, in TLV 130. 333 The up/down bit is set to zero, metric-type is internal metric. 334 These IP prefixes are learned from other IGPs, and are usually not 335 directly connected to the advertising router. 337 3) L2 intra-area routes 339 These are advertised in L2 LSPs, in TLV 128. 340 The up/down bit is set to zero, metric-type is internal metric. 341 These IP prefixes are directly connected to the advertising router. 342 These prefixes can not be distinguished from L1->L2 inter-area 343 routes. 345 4) L2 external routes 347 These are advertised in L2 LSPs, in TLV 130. 348 The up/down bit is set to zero, metric-type is internal metric. 349 These IP prefixes are learned from other IGPs, and are usually not 350 directly connected to the advertising router. 351 These prefixes can not be distinguished from L1->L2 inter-area 352 external routes. 354 5) L1->L2 inter-area routes 356 These are advertised in L2 LSPs, in TLV 128. 357 The up/down bit is set to zero, metric-type is internal metric. 358 These IP prefixes are learned via L1 routing, and were derived 359 during the L1 SPF computation from prefixes advertised in L1 LSPs 360 in TLV 128. 361 These prefixes can not be distinguished from L2 intra-area routes. 363 6) L1->L2 inter-area external routes 365 These are advertised in L2 LSPs, in TLV 130. 366 The up/down bit is set to zero, metric-type is internal metric. 367 These IP prefixes are learned via L1 routing, and were derived 368 during the L1 SPF computation from prefixes advertised in L1 LSPs 369 in TLV 130. 370 These prefixes can not be distinguished from L2 external routes. 372 7) L2->L1 inter-area routes 374 These are advertised in L1 LSPs, in TLV 128. 375 The up/down bit is set to one, metric-type is internal metric. 376 These IP prefixes are learned via L2 routing, and were derived 377 during the L2 SPF computation from prefixes advertised in TLV 128. 379 8) L2->L1 inter-area external routes 381 These are advertised in L1 LSPs, in TLV 130. 382 The up/down bit is set to one, metric-type is internal metric. 383 These IP prefixes are learned via L2 routing, and were derived 384 during the L2 SPF computation from prefixes advertised in L2 LSPs 385 in TLV 130. 387 9) L1 external routes with external metric 389 These are advertised in L1 LSPs, in TLV 130. 390 The up/down bit is set to zero, metric-type is external metric. 391 These IP prefixes are learned from other IGPs, and are usually not 392 directly connected to the advertising router. 394 10) L2 external routes with external metric 396 These are advertised in L2 LSPs, in TLV 130. 397 The up/down bit is set to zero, metric-type is external metric. 398 These IP prefixes are learned from other IGPs, and are usually not 399 directly connected to the advertising router. 400 These prefixes can not be distinguished from L1->L2 inter-area 401 external routes with external metric. 403 11) L1->L2 inter-area external routes with external metric 405 These are advertised in L2 LSPs, in TLV 130. 406 The up/down bit is set to zero, metric-type is external metric. 407 These IP prefixes are learned via L1 routing, and were derived 408 during the L1 SPF computation from prefixes advertised in L1 LSPs 409 in TLV 130 with external metrics. 410 These prefixes can not be distinguished from L2 external routes with 411 external metric. 413 12) L2->L1 inter-area external routes with external metric 415 These are advertised in L1 LSPs, in TLV 130. 416 The up/down bit is set to one, metric-type is external metric. 417 These IP prefixes are learned via L2 routing, and were derived 418 during the L1 SPF computation from prefixes advertised in L2 LSPs 419 in TLV 130 with external metrics. 421 4.2 Order of preference for all types of IP routes in IS-IS 423 Unfortunately IS-IS cannot depend on metrics alone for route 424 selection. Some types of routes must always preferred over others, 425 regardless of the costs that were computed in the Dijkstra 426 calculation. One of the reasons for this is that inter-area routes 427 can only be advertised with a maximum metric of 63. Another reason is 428 that this maximum value of 63 does not mean infinity (e.g. like a hop 429 count of 16 in RIP denotes unreachable). Introducing a value for 430 infinity cost in IS-IS inter-area routes would introduce counting- 431 to-infinity behavior via two or more L1L2 routers, which would have a 432 bad impact on network stability. 434 The order of preference of IP routes in IS-IS is based on a few 435 assumptions. 437 - RFC 1195 defines that routes derived from L1 routing are preferred over 438 routes derived from L2 routing. 439 - The note in RFC 1195 paragraph 3.10.2, item 2c) defines that internal 440 routes with internal metric-type and external prefixes with internal 441 metric-type have the same preference. 442 - RFC 1195 defines that external routes with internal metric-type are 443 preferred over external routes with external metric type. 444 - Routes derived from L2 routing are preferred over L2->L1 routes 445 derived from L1 routing. 447 Based on these assumptions, this document defines the following route 448 preferences. 450 1) L1 intra-area routes with internal metric 451 L1 external routes with internal metric 452 2) L2 intra-area routes with internal metric 453 L2 external routes with internal metric 454 L1->L2 inter-area routes with internal metric 455 L1->L2 inter-area external routes with internal metric 456 3) L2->L1 inter-area routes with internal metric 457 L2->L1 inter-area external routes with internal metric 458 4) L1 external routes with external metric 459 5) L2 external routes with external metric 460 L1->L2 inter-area external routes with external metric 461 6) L2->L1 inter-area external routes with external metric 463 4.3 Additional notes on what prefixes to accept or advertise 465 Paragraphs 4.1 and 4.2 enumerate all used IP route types in IS-IS. 466 Besides these defined route types, the encoding used would allow for 467 a few more potential combinations. One of them is the combination of 468 "IP Internal Reachability Information" and external metric type. 469 This combination should never be used when building an LSP. Upon 470 receipt of an IP prefix with this combination, routers must ignore 471 this prefix. 473 Another issue would be the usage of the up/down bit in L2 LSPs. 474 Because IS-IS is currently defined with two levels of hierarchy, 475 there should never be a need to set the up/down bit in L2 LSPs. 476 However, if IS-IS would ever be extended with more than two levels of 477 hierarchy, L2-only (or L1L2) routers will need to be able to accept 478 L2 IP routes with the up/down bit set. Therefor it is recommended 479 that implementations ignore the up/down bit in L2 LSPs, and accept 480 the prefixes in L2 LSPs regardless whether the up/down bit is set. 481 This will allow for simpler migration once more than two levels of 482 hierarchy are defined. 484 Another detail that implementors should be aware of is the fact that 485 L1L2 routers should only advertise in their L2 LSP those L1 routes 486 that they use for forwarding themselves. They should not 487 unconditionally advertise into L2 all prefixes from LSPs in the L1 488 database. 490 Not all prefixes need to be advertised up or down the hierarchy. 491 Implementations might allow for additional manual filtering or 492 summarization to further bring down the number of inter-area prefixes 493 they advertise in their LSPs. It is also recommended that the 494 default configuration of L1L2 routers is to not advertise any L2 495 routes into L1 (see also paragraph 5.0). 497 5.0 Inter-operability with older implementations 499 The solution in this document is not fully compatible with RFC 1195. 500 It is an extension to RFC 1195. If routers do not use the new 501 functionality of external L1 routes, nor L2->L1 inter-area routes, 502 older implementations that strictly follow RFC 1195 will be 503 compatible with newer implementations that follow this document. 505 Implementations that do not accept the "IP External Reachability 506 Information" TLV in L1 LSPs will not be able to compute external L1 507 routes. This could cause routing loops between L1-only routers that 508 do understand external L1 routes for a particular destination, and 509 L1-only routers that use the default route pointing the closest 510 attached L1L2 router for that destination. 512 Implementations that follow RFC 1195 should ignore bit 8 in the 513 default metric field when computing routes. Therefor even older 514 implementations that do not know of the up/down bit should be able to 515 accept the new L2->L1 inter-area routes. These older implementations 516 will install the new L2->L1 inter-area routes as L1 intra-area 517 routes, but that in itself does not cause routing loops among L1-only 518 routers. 520 However, it is vital that the up/down bit is recognized by L1L2 521 routers. As has been stated before, L1L2 routers must never 522 advertise L2->L1 inter-area routes back into L2. Therefor if L2 523 routes are advertised down into L1 area, it is required that all L1L2 524 routers in that area run software that understands the new up/down 525 bit. Older implementations that follow RFC 1195 and do not understand 526 the new up/down bit will threat the L2->L1 inter-area routes as L1 527 intra-area routes, and they will advertise these routes back into L2. 528 This can cause routing loops, sub-optimal routing or extra routing 529 instability. For this reason it is recommended that implementations 530 by default do not advertise any L2 routes into L1. Implementations 531 should force the network administrator to manually configure L1L2 532 routers to advertise any L2 routes into L1. 534 6.0 Comparisons with other proposals 536 In [3], a new TLV is defined to transport IP prefix information. 537 This TLV format also defines an up/down bit to allow for L2->L1 538 inter-area routes. [3] also defines a new TLV to describe links. 539 Both TLVs have wider metric space, and have the possibility to define 540 sub-TLVs to advertise extra information belonging to the link or 541 prefix. The wider metric space in IP prefix TLVs allows for more 542 granular metric information about inter-area path costs. To make 543 full use of the wider metric space, network administrators must 544 deploy both new TLVs at the same time. 546 Deployment of [3] requires an upgrade of all routers in the network 547 and a transition to the new TLVs. Such a network-wide upgrade and 548 transition might not be an easy task. In this case, the solution 549 defined in this document, which requires only an upgrade of L1L2 550 routers in selected areas, might be a good alternative to the 551 solution defined in [3]. 553 5.0 Security Considerations 555 This document raises no new security issues for IS-IS. 557 6.0 References 559 [1] ISO 10589, "Intermediate System to Intermediate System Intra- 560 Domain Routeing Exchange Protocol for use in Conjunction with the 561 Protocol for Providing the Connectionless-mode Network Service (ISO 562 8473)" [Also republished as RFC 1142] 564 [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 565 environments", R.W. Callon, Dec. 1990 567 [3] Smit, H., Li, T. "IS-IS extensions for Traffic Engineering", 568 draft-ietf-isis-traffic-01.txt, work in progress 570 7.0 Authors' Addresses 572 Tony Li 573 Procket Networks 574 3910 Freedom Circle, Ste. 102A 575 Santa Clara, CA 95054 576 Email: tli@procket.net 578 Tony Przygienda 579 Redback 580 350 Holger Way 581 San Jose, CA 95134 582 Email: prz@redback.com 584 Henk Smit 585 Procket Networks 586 3910 Freedom Circle, Ste. 102A 587 Santa Clara, CA 95054 588 Email: henk@procket.net