idnits 2.17.1 draft-ietf-isis-l1l2-00.txt: 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 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. ** The abstract seems to contain references ([Cal90a,Cal90b,, [RL95], ISO90]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 71: '...external metrics MUST NOT be leaked. ...' RFC 2119 keyword, line 72: '...l 1 are undefined and MUST be ignored....' RFC 2119 keyword, line 95: '... receives such a TLV MAY ignore it. Traditional RFC 1195 [Cal90b]...' RFC 2119 keyword, line 111: '... MUST not leak level 1 external pref...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An implementation that supports handling of the (TLV 130) at level 1 MUST not leak level 1 external prefixes into level 2 since otherwise persistent routing loops are possible if metrics conversions are not executed carefully. To understand why level 1 external prefixes must not be leaked into level 2 consider again the simple topology given in Figure 1. We assume that RT4 leaks N-8 as level 1 external with external cost of 2 to RT5. If RT6 does not leak N-8 into level-1 but would re-advertise level 1 N-8 again into level 2 as external with internal cost of less or equal to 3, RT4 would form a persistent routing loop (2) -- 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 (15 February 1999) is 9202 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) == Unused Reference: 'Cal90a' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'ISO90' is defined on line 227, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90b' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO90' -- Possible downref: Non-RFC (?) normative reference: ref. 'LMJ99' ** Obsolete normative reference: RFC 1771 (ref. 'RL95') (Obsoleted by RFC 4271) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Patel/T. Przygienda 3 INTERNET DRAFT Bell Labs 4 15 February 1999 6 L1/L2 Optimal IS-IS Routing 7 9 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 except that the right to 12 produce derivative works is not granted. 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. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at 20 any time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 29 This draft describes an optional extension within IS-IS [Cal90a, 30 Cal90b, ISO90] for leaking level 2 IP prefixes into level 1. IS-IS 31 is an interior gateway routing protocol developed originally by OSI 32 and used with IP extensions as IGP. This draft describes how to allow 33 for optimal routing in L1/L2 per destination prefix and to support 34 BGP [RL95] MEDs derived from level 1 and level 2 IGP metric when 35 using ISIS. 37 1. Introduction 38 In IS-IS extensions described in RFC 1195 [Cal90b] all level 1 39 routers are equivalent to ``stub'' routers which translates into the 40 fact that no level 2 routes are being leaked actively into level 41 1. Globally optimal routing across levels is hard since routers in 42 level 1 are forced to route to the closest level 2 gateway due to 43 the lack of more specific information than just the default route. 44 For scalability and management reasons it is preferable to divide 45 the topology into level 1 and level 2 from a certain size on. With 46 the extension proposed, globally optimal routing is possible that 47 does route per destination prefix to the appropriate level 2 gateway. 48 Moreover, beside the scalability and optimality reasons, given a case 49 where an ISP desires to advertise MEDs to their customer based on 50 IGP metric to BGP next hops [LMJ99], it is not possible or at least 51 misleading to use today's metrics. The metric consists of the cost 52 to traverse the area to the closest level 2 router and a default 53 level 2 cost which is inaccurate. This documents proposes to use 54 existing TLVs and extended processing rules to allow for routing 55 where such cost is adequately computed. 57 It is important for the understanding of this draft to properly 58 differentiate between level 1 routes, level 2 routes, level 2 59 external routes with internal metrics (1) and level 2 external routes 60 with external metrics. 62 2. Description 64 We extend the usual preference within IS-IS with a new type of 65 routes called level 1 external route which is not defined within RFC 66 1195 [Cal90b]. To advertise such routes, as an optional capability 67 described in this RFC, IP external reachability information (TLV 68 130) is allowed within level 1 TLVs. Level 2 routes or level 2 69 external routes with internal metric are leaked using internal metric 70 translated into an external level 1 metric. Level 2 external routes 71 with external metrics MUST NOT be leaked. (TLV 130) with internal 72 metrics in level 1 are undefined and MUST be ignored. 73 At this point, we introduce a simple topology in Figure 1 to discuss 74 scenarios encountered. Lines between routers indicate physical 75 point-to-point networks. RT1 is a level-1 router deploying the 76 proposed extension. RT2 is a conventional level-1 router. RT7 is a 77 level-2-only router. RT3, RT4 and RT6 are level-1-2 routers and also 78 participate in level-2 to level-1 leaking. Links between RT3 and RT4 79 and RT0 and RT3 are level-2-only links. Naturally, links between RT4 81 ___________________________________________ 82 1. which is equivalent to a (TLV 130) in level-2 with the I/E bit not 83 set. 85 and RT7 and RT6 are level-2-only as well. A cost for each physical 86 point-to-point network is being assumed as having the cost of 1, 87 except between RT3 and RT2 having a cost of 3. On RT0, RT3 and RT4 88 externally derived data (e.g., BGP-learned routes) are leaked into 89 level-2 as an external route with internal cost of 1. Therefore, 90 network N-8 will be present in RT3's level-2 LSP as external route 91 with internal cost of 1 and within the level-1 as external route with 92 external cost of 1. 94 An implementation that does not supports the proposed extension and 95 receives such a TLV MAY ignore it. Traditional RFC 1195 [Cal90b] 96 implementations ignoring this TLV can form routing loops if deployed 97 in a level-1-only domain mixed with level-1-only routers supporting 98 this capability. This happens since routers can disagree on the 99 best possible level-2 gateway for a destination for which no level-1 100 internal route exists. No routing loops can be formed if traditional 101 RFC 1195 routers are run in level-1-2 or level-2 only mixed with 102 routers deploying the proposed capability. 103 To see why routing loops in mixed level-1 deployment are possible, 104 consider RT1 that sees an level 1 external route for N-8 with 105 external cost 1 from RT3 and cost 2 from RT0. To route towards N-8 106 it will choose RT2 as its next hop. RT2 does not understand level 1 107 external routes and will therefore try to forward towards the closest 108 level-2 gateway, which happens to be RT0. 110 An implementation that supports handling of the (TLV 130) at level 1 111 MUST not leak level 1 external prefixes into level 2 since otherwise 112 persistent routing loops are possible if metrics conversions are not 113 executed carefully. To understand why level 1 external prefixes must 114 not be leaked into level 2 consider again the simple topology given 115 in Figure 1. We assume that RT4 leaks N-8 as level 1 external with 116 external cost of 2 to RT5. If RT6 does not leak N-8 into level-1 117 but would re-advertise level 1 N-8 again into level 2 as external 118 with internal cost of less or equal to 3, RT4 would form a persistent 119 routing loop (2) 121 ___________________________________________ 122 2. it would be theoretically possible to leak 123 level 1 external routes (that always have internal metric) into level 124 2 external routes with external metrics. 126 3. Order of Preference of Routes 128 In order to ensure correct inter-operation of different 129 implementations, it is necessary to specify the order of preference 130 of routes in the forwarding decision which is an extension of the one 131 used today. 132 For routers participating in level 1 and level 2 and leaking level 2 133 into level 1, the routes are preferred in the following sequence: 135 1. Amongst all routes, if the specified destination address matches 136 more than one [IP address, subnet mask] pair, then the most 137 specific address match (the one with more "1" bits in the mask) 138 is preferred. 140 2. Among the routes with equal address match the preference is 141 determined by the type in the following sequence: 143 - level 1 145 - level 2 147 - level 2 external with internal metric type 149 - level 1 external with external metric type (3) 151 - level 2 external with external metric type 153 3. Amongst routes of the same type with equal cost, multi-path load 154 balancing may be performed. 155 To visualize the concept, consider again Figure 1. After ISIS 156 converges, RT4 will see following entries for network N-8. 158 - level-2-external route with internal metric 2 with next-hop 159 towards RT3 generated by RT3. 161 - level-1-external route with next-hop towards RT5 with external 162 metric 3 obtained from RT6 that leaked it from within L2 into L1 163 domain. 165 ___________________________________________ 166 3. observe again that level 1 external with internal metric are not 167 allowed. 169 | N-8 170 | 171 +====+======+ +===========+ 172 I RT3 +==L2 only===+ RT4 I 173 +=====+ Level-1-2 I I Level-1-2 +=====+ 174 I +=====v=====+ +===v====== + I 175 I | | L2 only 176 I cost 3 | I 177 I | | I 178 I +%%%%%+%%%%+ +-----+----+ +~~~+~~~~~~~+ 179 I ! RT2 ! | RT5 | : RT7 : 180 I + L1,no 130! | L1 only | : L2 only : 181 I +%%%%%%%%%%+ +-----+----+ +~~~+~~~~~~~+ 182 L2 only | | I 183 I | | L2 only 184 I +-----+----+ +===^=======+ I 185 I | RT1 | I RT6 +=====+ 186 I | L1 only | I Level-1-2 I 187 I +-----+----+ +===========+ 188 I | 189 I | 190 I +=====^=====+ 191 +=====+ RT0 I 192 I Level-1-2 I 193 +===========+ 195 +==+ +--+ 196 I I Level-1-2 Router | | Level-1 Only Router 197 +==+ +--+ 199 +~~+ +%%+ 200 : : Level-2 Only Router ! ! Level-1 Only Router 201 +~~+ +%%+ without Level 1 TLV 130 Support 203 Figure 1: Topology used in our examples 205 From those entries, route towards N-8 must be chosen according to 206 preferences specified above. Following the rules, level 2 external 207 route through RT3 with internal metric 2 must be preferred, otherwise 208 a stable loop through RT6 would exist if e.g. level-1 external would 209 be given preference over level-2 external route with internal metric. 211 4. Acknowledgments 212 Rohit Dube reviewed the draft carefully and helped to clarify it. 214 5. Security Consideration 215 ISIS security applies to the work presented. No specific security 216 issues with the proposed solutions are known. 218 References 220 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 221 INTERNET-RFC, Internet Engineering Task Force, February 1990. 223 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 224 Environments. INTERNET-RFC, Internet Engineering Task Force, 225 December 1990. 227 [ISO90] ISO. Information Technology - Telecommunications and 228 Information Exchange between Systems - Intermediate System 229 to Intermediate System Routing Exchange Protocol for 230 Use in Conjunction with the Protocol for Providing the 231 Connectionless-Mode Network Service. ISO, 1990. 233 [LMJ99] C. Labovitz, G. Malan, and F. Jahanian. Origins of internet 234 routing instability. In Proceedings of Infocomm'99 235 Conference, 236 New York, USA, 3 1999. 238 [RL95] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4), 239 RFC 1771. Internet Engineering Task Force, March 1995. 241 Authors' Addresses 243 Ajay Patel 244 Bell Labs, Lucent Technologies 245 101 Crawfords Corner Road 246 Holmdel, NJ 07733-3030 247 ajayp@dnrc.bell-labs.com 248 Tony Przygienda 249 Bell Labs, Lucent Technologies 250 101 Crawfords Corner Road 251 Holmdel, NJ 07733-3030 252 prz@dnrc.bell-labs.com