idnits 2.17.1 draft-ietf-isis-domain-wide-00.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 339 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 3 instances of too long lines in the document, the longest one being 4 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 (February 1999) is 9174 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-00 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Li 2 INTERNET DRAFT Juniper Networks 3 February 1999 5 Domain-wide Prefix Distribution with Multi-Level IS-IS 7 9 Status 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1.0 Abstract 32 This document describes extensions to the IS-IS protocol to support 33 optimal routing within a multi-level domain. The IS-IS protocol is 34 specified in ISO 10589 [1], with extensions for supporting IPv4 35 specified in RFC 1195 [2]. 37 This document extends the semantics presented in RFC 1195 so that a 38 routing domain running with both Level 1 and Level 2 Intermediate 39 Systems (IS) [routers] can distribute IP prefixes between Level 1 and 40 Level 2 and vice versa. This distribution requires certain 41 restrictions to insure that persistent forwarding loops do not form. 42 The goal of this domain-wide prefix distribution is to increase the 43 granularity of the routing information within the domain. 45 2.0 Introduction 47 An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) 48 can be partitioned into multiple level 1 (L1) areas, and a level 2 49 (L2) connected subset of the topology that interconnects all of the 50 L1 areas. Within each L1 area, all routers exchange link state 51 information. L2 routers also exchange L2 link state information to 52 compute routes between areas. 54 RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that are 55 used to transport IPv4 routing information in IS-IS. RFC 1195 also 56 specifies the semantics and procedures for interactions between 57 levels. Specifically, routers in a L1 area will exchange information 58 within the L1 area. For IP destinations not found in the prefixes in 59 the L1 database, the L1 router should forward packets to the nearest 60 router that is in both L1 and L2 (i.e., an L1L2 router) with the 61 'attach' bit set in its L1 Link State Protocol Data Unit (LSP). 63 Also per RFC 1195, an L1L2 router should be manually configured with 64 a set of prefixes that summarize the IP prefixes found in that L1 65 area. These summaries are injected into L2. RFC 1195 specifies no 66 further interactions between L1 and L2 for IPv4 prefixes. 68 2.1 Motivations for domain-wide prefix distribution 70 The mechanisms specified in RFC 1195 are appropriate in many 71 situations, and lead to excellent scalability properties. However, 72 in certain circumstances, the domain administrator may wish to 73 sacrifice some amount of scalability and distribute more specific 74 information than is described by RFC 1195. This section discusses 75 the various reasons why the domain administrator may wish to make 76 such a tradeoff. 78 One major reason for distributing more prefix information is to 79 improve the quality of the resulting routes. A well know property of 80 prefix summarization or any abstraction mechanism is that it 81 necessarily results in a loss of information. This loss of 82 information in turn results in the computation of a route based upon 83 less information, which will frequently result in routes that are not 84 optimal. 86 A simple example can serve to demonstrate this adequately. Suppose 87 that a L1 area has two L1L2 routers that both advertise a single 88 summary of all prefixes within the L1 area. To reach a destination 89 inside the L1 area, any other L2 router is going to compute the 90 shortest path to one of the two L1L2 routers for that area. Suppose, 91 for example, that both of the L1L2 routers are equidistant from the 92 L2 source, and that the L2 source arbitrarily selects one L1L2 93 router. This router may not be the optimal router when viewed from 94 the L1 topology. In fact, it may be the case that the path from the 95 selected L1L2 router to the destination router may traverse the L1L2 96 router that was not selected. If more detailed topological 97 information or more detailed metric information was available to the 98 L2 source router, it could make a more optimal route computation. 100 This situation is symmetric in that an L1 router has no information 101 about prefixes in L2 or within a different L1 area. In using the 102 nearest L1L2 router, that L1L2 is effectively injecting a default 103 route without metric information into the L1 area. The route 104 computation that the L1 router performs is similarly suboptimal. 106 Besides the optimality of the routes computed, there is another 107 significant driver for the domain wide distribution of prefix 108 information. That driver is the current practice of using the IGP 109 (IS-IS) metric as part of the BGP Multi-Exit Discriminator (MED). 110 The value in the MED is advertised to other domains and is used to 111 inform other domains of the optimal entry point into the current 112 domain. Current practice is to take the IS-IS metric and insert it 113 as the MED value. This tends to cause external traffic to enter the 114 domain at the point closest to the exit router. Note that the 115 receiving domain may, based upon policy, choose to ignore the MED 116 that is advertised. However, current practice is to distribute the 117 IGP metric in this way in order to optimize routing wherever 118 possible. This is possible in current networks that only are a 119 single area, but becomes problematic if hierarchy is to be installed 120 into the network. This is again because the loss of end-to-end 121 metric information means that the MED value will not reflect the true 122 distance across the advertising domain. Full distribution of prefix 123 information within the domain would alleviate this problem as it 124 would allow accurate computation of the IS-IS metric across the 125 domain, resulting in an accurate value presented in the MED. 127 2.2 Scalability 129 The disadvantage to performing the domain-wide prefix distribution 130 described above is that it has an impact to the scalability of IS-IS. 131 Areas within IS-IS help scalability in that LSPs are contained within 132 a single area. This limits the size of the link state database, that 133 in turn limits the complexity of the shortest path computation. 135 Further, the summarization of the prefix information aids scalability 136 in that the abstraction of the prefix information removes the sheer 137 number of data items to be transported and the number of routes to be 138 computed. 140 It should be noted quite strongly that the distribution of prefixes 141 on a domain wide basis impacts the scalability of IS-IS in the second 142 respect. It will increase the number of prefixes throughout the 143 domain. This will result in increased memory consumption, 144 transmission requirements and computation requirements throughout the 145 domain. 147 It must also be noted that the domain-wide distribution of prefixes 148 has no effect whatsoever on the first aspect of scalability, namely 149 the existence of areas and the limitation of the distribution of the 150 link state database. 152 Thus, the net result is that the introduction of domain-wide prefix 153 distribution into a formerly flat, single area network is a clear 154 benefit to the scalability of that network. However, it is a 155 compromise and does not provide the maximum scalability available 156 with IS-IS. Domains that choose to make use of this facility should 157 be aware of the tradeoff that they are making between scalability and 158 optimality and provision and monitor their networks accordingly. 159 Normal provisioning guidelines that would apply to a fully 160 hierarchical deployment of IS-IS will not apply to this type of 161 configuration. 163 4.0 New semantics for external type metrics 165 RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is 166 defined to carry 'internal' prefixes and TLV 130 is defined to carry 167 'external' prefixes. The original intent of RFC 1195 was to carry 168 intra-domain routes within the internal prefix TLV and inter-domain 169 routes or intra-domain routes from alternate IGPs in an external 170 prefix TLV. Interestingly, TLV type 130 is not documented to exist 171 in Level 2 LSPs. 173 In addition to this distinction, RFC 1195 provides for a bit in each 174 of these TLVs that distinguishes between an internal metric type and 175 an external metric type. Similarly, the clear intent was that the 176 internal metric type should reflect a total metric that is the sum of 177 the metrics to the advertising router plus the metric to the prefix. 178 Further, for an external metric type, the total metric should simply 179 be the metric advertised to the prefix, not including the total 180 metric necessary to reach the exit router. Prefixes with internal 181 metrics are always preferred over external metrics, regardless of the 182 value of the metrics. 184 It should be noted that the combination of an internal prefix with an 185 external metric type is not obviously useful, and is not well defined 186 by RFC 1195. 188 It should also be noted that as of this writing, the author knows of 189 no deployed implementations that make use of either the external 190 prefix or the external metric type. The implication is that this 191 proposal is free to redefine the semantics of the external metric 192 type without conflict. 194 An essential property when redistributing prefixes between levels is 195 to insure that no persistent loops form in the distribution of 196 information (i.e., a routing loop), as this would lead to the 197 indefinite propagation of the information, even in the event that the 198 information was no longer originated by some system in the domain. 199 Further, a routing loop is likely to form a forwarding loop, where 200 actual traffic traverses the network in a cycle in the topology. 201 Forwarding loops are known to consume large amounts of resources and 202 are to be avoided. 204 4.1 Proposed semantics for the external metric type 206 To provide the above properties, this proposal defines the following 207 semantics. 209 1) Only internal metric type prefixes are redistributed from L1 into 210 L2, and these will be marked as an external metric type when 211 advertised into L2. 213 2) All prefixes can be redistributed from L2 into L1 but again will 214 be marked as an external metric type when advertised into L1. 216 3) Within L1, a route to a prefix with an internal metric type is 217 preferred over a route to the same prefix with an external metric 218 type, regardless of the comparison of the metrics. 220 Based on these rules, we first observe that this proposal is free 221 from routing loops. No prefix can be redistributed from L2 to L1 and 222 back into L2, because the route is marked with external metric type 223 in L1 and by rule 1 cannot be redistributed into L2. Similarly, a 224 prefix redistributed from L1 to L2 and back into the original L1 area 225 will not be used while an L1 internal metric type prefix is 226 available. There is the possibility of a transient routing loop in 227 this situation when the original prefix is withdrawn and the external 228 prefix is selected. However, all link state protocols are subject to 229 transient routing loops, so this is no worse than the status quo. 231 Note that this proposal is not radically different than the current 232 semantics for RFC 1195: internal metric types are always preferred 233 over externals, so rule (3) is an extension that allows external 234 metric types in internal prefix TLVs. It does not introduce a new 235 comparison between internal and external metric types. 237 4.2 Transition issues 239 Because no implementations currently make use of the external metric 240 type, the deployment of prefixes with an external metric type is 241 somewhat problematic. There is the possibility that the new type of 242 advertisement may result in software instability in systems that do 243 not deal with even the original semantics correctly. Further, there 244 is a danger that haphazard deployment of systems supporting this 245 proposal and legacy systems would have an unfortunate interaction. 246 It is recommended, for any L1 area that should perform the mutual 247 redistribution described in this proposal, that the L1L2 systems be 248 updated first. If these systems operate correctly, this is 249 sufficient to insure that there are no persistent routing loops. 251 5.0 Comparisons with other proposals 253 There are two other proposals currently being discussed which are 254 similar to this proposal in nature. This section discusses each of 255 these proposals and their relationship to this proposal. 257 5.1 Creation of new TLVs 259 In [3], a new TLV is proposed to transport IP prefix information. 260 Because this is a new TLV, it is somewhat harder to deploy, requiring 261 that all systems understand the new TLV before it can become 262 effective. For this reason, this proposal provides an alternative 263 that can be deployed sooner. There is no effective semantic 264 difference between the two proposals. In [3], a bit is defined to 265 mark a prefix as 'up' or 'down'. This is essentially the same 266 semantics as is proposed here. 268 5.2 Usage of external prefixes 270 An alternate proposal, [4], also uses effectively the same semantics, 271 but encodes the information somewhat differently. Prefixes that 272 would be marked with the external metric type would be instead 273 encoded as external prefixes. This forces the usage of a separate 274 TLV, resulting in a few extra bytes of overhead. This is not a 275 significant difference. The primary differences are syntactic, and 276 the addition of the external prefix TLV to the L1 LSP. The latter is 277 a clear omission in RFC 1195 and should have been in the original 278 RFC. 280 6.0 Security Considerations 282 This document raises no new security issues for IS-IS. 284 7.0 Acknowledgments 286 The authors would like to thank Henk Smit for his comments on this 287 work. 289 8.0 References 291 [1] ISO 10589, "Intermediate System to Intermediate System Intra- 292 Domain Routeing Exchange Protocol for use in Conjunction with the 293 Protocol for Providing the Connectionless-mode Network Service (ISO 294 8473)" [Also republished as RFC 1142] 296 [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 297 environments", R.W. Callon, Dec. 1990 299 [3] Smit, H., Li, T. "IS-IS extensions for Traffic Engineering", 300 draft-ietf-isis-traffic-00.txt, work in progress 302 [4] Patel, A., Przygienda, T., "L1/L2 Optimal IS-IS Routing", draft- 303 ietf-isis-l1l2-00.txt, work in progress 305 9.0 Author's Address 307 Tony Li 308 Juniper Networks, Inc. 309 385 Ravendale Dr. 310 Mountain View, CA 94043 311 Email: tli@juniper.net 312 Fax: +1 650 526 8001 313 Voice: +1 650 526 8006