idnits 2.17.1 draft-chunduri-lsr-isis-mt-deployment-cons-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 70 has weird spacing: '...gy Mode and M...' -- The document date (October 22, 2018) is 2014 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) == Missing Reference: 'ISO10589' is mentioned on line 84, but not defined == Missing Reference: 'RFC 5305' is mentioned on line 158, but not defined == Missing Reference: 'RFC 5120' is mentioned on line 244, but not defined == Missing Reference: 'RFC 5308' is mentioned on line 242, but not defined == Unused Reference: 'RFC5305' is defined on line 344, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-03 == Outdated reference: A later version (-09) exists of draft-ietf-rtgwg-multihomed-prefix-lfa-08 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group U. Chunduri 3 Internet-Draft Huawei USA 4 Intended status: Standards Track J. Tantsura 5 Expires: April 25, 2019 Apstra, Inc. 6 October 22, 2018 8 IS-IS Multi Topology Deployment Considerations 9 draft-chunduri-lsr-isis-mt-deployment-cons-01 11 Abstract 13 This document analyzes IS-IS Multi Topology (MT) considerations in 14 various deployments (Core/Mobile Backhaul/Data Center underlays). 15 This document explores the nuances around the terminology and usage 16 of various IS-IS address families, topologies and considerations, 17 while choosing the right combination for a specific deployment 18 scenario. 20 This document also discusses various ways one can deploy IPv6 only 21 IS-IS topology. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2019. 46 Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Need for MT in IS-IS networks . . . . . . . . . . . . . . . . 3 67 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Topologies and Address Families . . . . . . . . . . . . . . . 4 69 4.1. Single Topology Mode and Multiple Address Families . . . 4 70 4.2. Multiple Topology Mode and Multiple Address Families . . 5 71 4.2.1. Transition Mode . . . . . . . . . . . . . . . . . . . 6 72 4.3. IPv6 Only Topology . . . . . . . . . . . . . . . . . . . 6 73 5. IS-IS MT and LFA . . . . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 9.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 ISIS originally developed for OSI [ISO10589], extensions have been 85 made available to support IPv4 [RFC1195]. A method for exchanging 86 IPv6 routing information using the IS-IS routing protocol is 87 specified in [RFC5308]. How to run a set of independent IP 88 topologies with topology specific adjacencies, within a single IS-IS 89 domain has been defined in IS-IS MT [RFC5120]. 91 Multiple mobile backhaul network user plane proposals like 92 [I-D.ietf-dmm-srv6-mobile-uplane] and [I-D.herbert-ila-mobile] use 93 IPv6 only solution using source routing, address transformation 94 respectively. It is possible to conceive, various parts of the 95 backhaul networks use IPv4 and appropriate migration strategy needed 97 Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018 99 before eventually moving towards IPv6 only network. While any IGP 100 can be used in these networks, this document covers only IS-IS 101 protocol aspects. 103 Various layer-3 DC fabric routing options (refs: openfabric, spine- 104 leaf, controller-based) by changing or optimizing some aspects w.r.t 105 adjacency formation, flooding optimizations, or/and mechanisms to 106 automatically compute the location of the node in the fat tree 107 topology are proposed recently and this document brings some of the 108 multi topology deployment aspects relevant to these networks. Please 109 note, part of the discussion around IS-IS MT is not specific to DC or 110 CLOS fabrics and generally applicable to any IS-IS deployment but 111 discussed here because of multiple proposals to use various forms of 112 IS-IS in this context. 114 2. Need for MT in IS-IS networks 116 For mobile transport backhaul networks seeking only IPv6 network or 117 transitioning from parts of the network with only IPv4, IS-IS MT is 118 needed. For layer-3 DC fabric underlay, which provide reachability, 119 only one address family (either IPv4 or IPv6) SHOULD be sufficient. 120 However if either only IPv6 address family is needed in the underlay 121 or deploying both IPv4 and IPv6 address families are desired 122 discussion in Section 4 is relevant. 124 It is an unlikely requirement, where DC fabric to be partitioned 125 logically to have different topologies in the underlay. If one does 126 the same to meet a particular requirement, it introduces a 127 manageability complexity of these logical topologies. IS-IS MT 128 [RFC5120] also designed to address the above need and discussion in 129 Section 4.2 is relevant. It is worth noting, majority of the IS-IS 130 deployments use MT primarily to have a separate logical topology for 131 IPv6 address family. 133 3. Acronyms 135 IIH : IS-IS Hello Protocol Data Unit 137 LSP : Link State PDU 139 MT : Multi Topology 141 SPF : Shortest Path First 143 Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018 145 4. Topologies and Address Families 147 Terminology around IS-IS topologies and address families is somewhat 148 confusing at best. Just to give an example, MT ID #2 defined in [RFC 149 5120] says, it is "Reserved for IPv6 routing topology". While 150 multiple MT ID's can be deployed in a network with IPv6 topologies, 151 MT ID #2, perhaps referring to a first such topology with IPv6 only 152 address family. This section details various topology and address 153 family options possible with currently available IS-IS specifications 154 with respective defined TLVs. 156 4.1. Single Topology Mode and Multiple Address Families 158 IS-IS with IPv4 address family and with wide-metrics [RFC 5305] is 159 widely deployed, with TLV 22 defined for IS Reachability and TLV 135 160 for IP (IPv4) reachability information . This is essentially a single 161 topology for the entire IS-IS area/domain with a single address 162 family (IPv4 unicast). 164 IS-IS can also be enabled with IPv6 unicast address family in a 165 single topology mode along with IPv4 unicast address family. Here 166 IPv6 uses the same underlying topology that is used for IPv4 and this 167 can be done as specified in IS-IS IPv6 [RFC5308] which introduces TLV 168 236, an IPv6 reachability TLV. It is important to note same IS-IS 169 adjacency is used for both address families and with a single SPF 170 (decision process) both IPv4 and IPv6 reachability would be computed. 172 However, for the above to work effectively, both IPv4 and IPv6 173 address families MUST share a common network topology. That is to 174 use IS-IS for IPv4 and IPv6 routing, any interface configured for 175 IPv4 IS-IS MUST also be configured for IPv6 IS-IS, and vice versa. 176 All routers within an IS-IS area (Level 1 routing) or domain (Level 2 177 routing) MUST also support the same set of address families: IPv4 178 only, IPv6 only, or both IPv4 and IPv6. Any discrepancy in the 179 configuration w.r.t above can cause routing black holes and one such 180 scenario is discussed below. 182 Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018 184 | / \| 185 ...Rx Ry... 186 | \ / 187 | \ / | 188 | \ / | 189 | /\ | 190 | / \ | 191 | / \| 192 ... R1 R2... 193 | \ / | 195 Figure 1: IS-IS with multiple address families 197 As shown, in the above diagram all routers in the network enabled 198 with both IPv4 and IPv6 unicast address families at the IS level and 199 single topology would be built. However, at a link level all but 200 except one link, say if IPv6 is not configured on the link between 201 the routers Rx and R2; due to a single IS-IS topology, the shortest 202 path between Rx and R2 is the direct link and since IPv6 is not 203 enabled on that link, Rx and R2 cannot exchange IPv6 data traffic 204 even though there's an alternate path between them in the topology 205 through Rx, R1, Ry and R2. 207 Hence to summarize the restrictions: all routers in the topology MUST 208 support only IPv4, only IPv6 or both IPv4 and IPv6 address families 209 on all links and node. In other words, network MUST be congruent. 210 While this model is to simpler to operate, might not be flexible 211 enough for some IS-IS deployments. 213 4.2. Multiple Topology Mode and Multiple Address Families 215 Multi-topology IS-IS uses multiple SPFs to compute routes and removes 216 the restriction that all interfaces MUST support all configured 217 address families and that all routers in an IS-IS area or domain MUST 218 support the same set of address families. This introduces the 219 concept of topology specific adjacency with MT IS Reachability TLV 220 222 and MT capable IPv4 Reachability with TLV 235 and MT capable IPv6 221 Reachability with TLV 237. 223 When MT IS-IS is enabled with IPv4 and IPv6 address families, the 224 routers build two topologies, one for each address family (IPv4 and 225 IPv6) and can find the optimum path for each address family even when 226 some links in the network support only one of them. IS-IS MT [RFC 227 5120] defines MT ID #0 for backward compatibility, as the "standard" 228 topology and this essentially operate as IS-IS single topology mode 229 as specified in Section 4.1 and supports both IPv4 and IPv6 address 231 Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018 233 families. MT ID #2 [RFC 5120] is defined for IPv6 address family in 234 MT mode. 236 4.2.1. Transition Mode 238 Most of the vendors supported MT transition feature (though some 239 vendors disabled to avoid confusion around this) in the IS-IS 240 networks to facilitate MT deployments without disrupting the single 241 topology mode. The MT transition mode allows a network operating in 242 single topology IS-IS IPv6 [RFC 5308] to continue to work while 243 upgrading routers to include MT IS-IS IPv6 support i.e., MT ID #2 244 with [RFC 5120] . While in transition mode, both types of TLVs 245 (single-topology with TLV 236 and MT with TLV 237) are sent in LSPs 246 for all configured IPv6 addresses, nodes can continue to operate in 247 single topology mode though being in MT mode ("standard" IS-IS 248 topology with MT ID #0). After all routers in the area or domain 249 have been upgraded to support MT IPv6 transition mode can be removed 250 from the configuration. Once all routers in the area or domain are 251 operating in MT IPv6 mode, the topological restrictions of single- 252 topology mode are no longer in effect. 254 When transition mode is enabled, the router advertises both MT TLVs 255 and the old style IS-IS IPv6 TLVs but the topological restrictions of 256 the single topology mode discussed above are in effect with MT 257 transition mode. However, there were instances while this is enabled 258 and folks expect a different result in the actual deployments. 260 4.3. IPv6 Only Topology 262 Though it is theoretically possible to build IPv6 only underlay (with 263 TLV 236 for IPv6 reachability prefixes) in single topology mode as 264 discussed in Section 4.1, lot of legacy implementations require IPv4 265 address families too be configured in single topology mode (ingrained 266 code structures for IPv4 address family). IPv6 only DC underlay 267 network can be built with multi topology adjacencies (TLV 222) and 268 reachability prefixes (TLV 237) with MT ID #2 as discussed above in 269 Section 4.2. With this, any other address family can be introduced 270 including "standard" topology MT ID #0 (Single topology mode with 271 both address families) and there are no restrictions on which address 272 family has to enable on which link as specified in Section 4.1. 274 5. IS-IS MT and LFA 276 IP Fast Reroute (FRR) or Loop Free Alternative (LFA) computation in 277 MT mode are described in detail in Section 5.2 of 278 [I-D.ietf-rtgwg-multihomed-prefix-lfa]. 280 Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018 282 6. Acknowledgements 284 Thanks to .. TBD. 286 7. IANA Considerations 288 This document has no actions for IANA. 290 8. Security Considerations 292 Security concerns for IS-IS are addressed in [RFC5304]and [RFC5310]. 293 Further security analysis for IS-IS protocol is done in [RFC7645]. 295 This document does not introduce any change in any of the IS-IS 296 protocol or IS-IS protocol extensions. This document also does not 297 introduce any new security issues other than as noted in the 298 referenced IS-IS protocol extensions. 300 9. References 302 9.1. Normative References 304 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 305 dual environments", RFC 1195, DOI 10.17487/RFC1195, 306 December 1990, . 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, 310 DOI 10.17487/RFC2119, March 1997, 311 . 313 9.2. Informative References 315 [I-D.herbert-ila-mobile] 316 Herbert, T. and K. Bogineni, "Identifier Locator 317 Addressing for Mobile User-Plane", draft-herbert-ila- 318 mobile-01 (work in progress), March 2018. 320 [I-D.ietf-dmm-srv6-mobile-uplane] 321 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 322 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 323 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 324 uplane-03 (work in progress), October 2018. 326 Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018 328 [I-D.ietf-rtgwg-multihomed-prefix-lfa] 329 Sarkar, P., Chunduri, U., Hegde, S., Tantsura, J., and H. 330 Gredler, "LFA selection for Multi-Homed Prefixes", draft- 331 ietf-rtgwg-multihomed-prefix-lfa-08 (work in progress), 332 October 2018. 334 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 335 Topology (MT) Routing in Intermediate System to 336 Intermediate Systems (IS-ISs)", RFC 5120, 337 DOI 10.17487/RFC5120, February 2008, 338 . 340 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 341 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 342 2008, . 344 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 345 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 346 2008, . 348 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 349 DOI 10.17487/RFC5308, October 2008, 350 . 352 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 353 and M. Fanto, "IS-IS Generic Cryptographic 354 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 355 2009, . 357 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 358 Authentication for Routing Protocol (KARP) IS-IS Security 359 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 360 . 362 Authors' Addresses 364 Uma Chunduri 365 Huawei USA 366 2330 Central Expressway 367 Santa Clara, CA 95050 368 USA 370 Email: uma.chunduri@huawei.com 372 Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018 374 Jeff Tantsura 375 Apstra, Inc. 377 Email: jefftant.ietf@gmail.com