idnits 2.17.1 draft-litkowski-isis-ip-route-preference-issue-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2014) is 3591 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ISO-10589' is mentioned on line 110, but not defined ** Obsolete normative reference: RFC 2966 (Obsoleted by RFC 5302) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ISIS Working Group S. Litkowski 3 Internet-Draft Orange Business Service 4 Intended status: Informational June 27, 2014 5 Expires: December 29, 2014 7 IP Route preference specification issue 8 draft-litkowski-isis-ip-route-preference-issue-00 10 Abstract 12 This document details a potential specification issue in IP route 13 preference in ISIS. As a consequence, some implementations does not 14 interoperate correctly and leads to routing loops. Authors tries to 15 analyse if we need to fix current specification. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 29, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Specification analysis . . . . . . . . . . . . . . . . . . . 3 59 3. IPv6 and MT extensions cases . . . . . . . . . . . . . . . . 4 60 4. Enhancing the RFC5305 . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Problem statement 69 L2 L2 L2 L2|L2 L2 70 10/8 - R0 ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8 71 | 72 Figure 1 74 Considering the figure 1, both R0 and R4 are advertising the prefix 75 10/8. Two ISIS L2 process are running on R3 to separate network. R3 76 is performing route-leaking and advertise prefix from R4 to the other 77 L2 process. The network is using extended metrics (TLV135 defined in 78 [RFC5305]). Considering that R0 is advertising 10/8 with metric 2000 79 and R3 with metric 100, and all the links have a metric of 1. When 80 advertising route in L2, R3 set the down bit, according to [RFC5305]. 82 During interoperability testings, authors observed some routing loops 83 in this scenario. 85 R1, R2 and R3 are from three different vendors (R1->Vendor1, 86 R2->Vendor2, R3->Vendor3). 88 o R2 has two possible paths to reach 10/8, L2 up route with metric 89 2002 (from R0), and L2 down route with metric 101 (from R3). R2 90 selects R1 as nexthop to 10/8 because it is an Up route. 92 o R3 has two possible paths to reach 10/8, L2 up route with metric 93 2002 from R1, L2 up metric 101 from R4. R3 selects R4 as nexthop 94 due to lowest metric. 96 o R1 has two possible paths to reach 10/8, L2 up route with metric 97 2001 from R0, L2 down metric 102 from R2. R1 selects R2 as 98 nexthop due to lowest metric. 100 When R1 or R2 try to send traffic to 10/8, packets are looping due to 101 inconsistent routing decision between R1 and R2. 103 2. Specification analysis 105 [RFC5305] defines IP extended reachability (TLV135), it also defines 106 the notion of "Up/Down bit" that did not exist in [RFC1195] : 108 "The existing IP reachability TLVs (TLV type 128 and TLV type 130, 109 defined in [RFC1195]) carry IP prefixes in a format that is analogous 110 to the IS neighbor TLV from ISO 10589 [ISO-10589]. They carry four 111 metrics, of which only the default metric is commonly used. The 112 default metric has a possible range of 0-63. We would like to remove 113 this restriction. 115 In addition, route redistribution (a.k.a. route leaking) has a key 116 problem that was not fully addressed by the existing IP reachability 117 TLVs. [RFC1195] allows a router to advertise prefixes upwards in the 118 level hierarchy. Unfortunately, there were no mechanisms defined to 119 advertise prefixes downwards in the level hierarchy. 121 To address these two issues, the proposed extended IP reachability 122 TLV provides for a 32-bit metric and adds one bit to indicate that a 123 prefix has been redistributed 'down' in the hierarchy." 125 [RFC5305] does not provide any rule for taking into account up/down 126 bit in route preference. 128 [RFC5302] replaces [RFC2966] and defines extension to support optimal 129 routing in multi-level environment. It especially defines up/down 130 bit for IP prefix semantics defined in [RFC1195] (aka TLV 131 128,TLV130). Section 3.2 of [RFC5302] clearly specifies the order of 132 preference between IP route types in ISIS. 134 "Based on these assumptions, this document defines the following route 135 preferences. 137 1. L1 intra-area routes with internal metric; L1 external routes 138 with internal metric 140 2. L2 intra-area routes with internal metric; L2 external routes 141 with internal metric; L1->L2 inter-area routes with internal 142 metric; L1->L2 inter-area external routes with internal metric 144 3. L2->L1 inter-area routes with internal metric; L2->L1 inter-area 145 external routes with internal metric 147 4. L1 external routes with external metric 149 5. L2 external routes with external metric; L1->L2 inter-area 150 external routes with external metric 152 6. L2->L1 inter-area external routes with external metric" 154 It is quite clear that for IP Reachability defined in [RFC1195], up 155 routes are prefered over down routes. It sounds that [RFC5302] does 156 not apply to TLV defined in [RFC5305] : section 5 of [RFC5302] 157 describes [RFC5305] as another proposal to deal with the issues 158 described. 160 3. IPv6 and MT extensions cases 162 [RFC5308] defines IPv6 Reachability extension for ISIS (TLV 236). 163 Section 5 of the RFC clearly defines the order of preference between 164 route types : 166 "The order of preference between paths for a given prefix MUST be 167 modified to consider the up/down bit. The new order of preference is 168 as follows (from best to worst). 170 1. Level 1 up prefix 172 2. Level 2 up prefix 174 3. Level 2 down prefix 176 4. Level 1 down prefix 178 If multiple paths have the same best preference, then selection 179 occurs based on metric. Any remaining multiple paths SHOULD be 180 considered for equal-cost multi-path routing if the router supports 181 this; otherwise, the router can select any one of the multiple paths." 183 [RFC5120] defines Multitopology extension for ISIS and new IPv4 and 184 IPv6 reachability TLVs (TLV 235 and 237). No guideline are provided 185 in this RFC for route type preference but as MT extensions are based 186 on basic TLVs (135 and 236), we expect the same behavior as for the 187 associated TLVs. 189 4. Enhancing the RFC5305 191 [RFC5305] lacks of text regarding order of route preference compared 192 to [RFC5308] and [RFC5302]. [RFC5302] does not seem to apply to 193 TLV135 defined in [RFC5305]. As [RFC5302] and [RFC5308] are already 194 aligned in term of behavior, authors propose to enhance [RFC5305] 195 with a clear text stating the route preference order with the same 196 behavior described in the two other specifications. 198 5. Security Considerations 200 There is no security consideration. 202 6. Acknowledgements 204 7. IANA Considerations 206 There is no IANA consideration. 208 8. Normative References 210 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 211 dual environments", RFC 1195, December 1990. 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix 217 Distribution with Two-Level IS-IS", RFC 2966, October 218 2000. 220 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 221 Topology (MT) Routing in Intermediate System to 222 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 224 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 225 Distribution with Two-Level IS-IS", RFC 5302, October 226 2008. 228 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 229 Engineering", RFC 5305, October 2008. 231 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 232 2008. 234 Author's Address 236 Stephane Litkowski 237 Orange Business Service 239 Email: stephane.litkowski@orange.com