idnits 2.17.1 draft-chunduri-lsr-isis-mt-deployment-cons-02.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 72 has weird spacing: '...gy Mode and M...' -- The document date (May 19, 2019) is 1804 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-04 Summary: 0 errors (**), 0 flaws (~~), 3 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: Informational J. Tantsura 5 Expires: November 20, 2019 Apstra, Inc. 6 S. Hegde 7 Juniper Networks 8 May 19, 2019 10 IS-IS Multi Topology Deployment Considerations 11 draft-chunduri-lsr-isis-mt-deployment-cons-02 13 Abstract 15 This document analyzes IS-IS Multi Topology (MT) applicability in 16 various deployments (Core/Mobile Backhaul/Data Center underlays). 17 This document explores the nuances around the terminology and usage 18 of various IS-IS address families, topologies with different 19 considerations, for choosing the right combination for a specific 20 deployment scenario. 22 This document also discusses various ways one can deploy IPv6 only 23 IS-IS topology. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC2119 [RFC2119], 30 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 31 shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 20, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Need for MT in IS-IS networks . . . . . . . . . . . . . . . . 3 69 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Topologies and Address Families . . . . . . . . . . . . . . . 4 71 4.1. Single Topology Mode and Multiple Address Families . . . 4 72 4.2. Multiple Topology Mode and Multiple Address Families . . 5 73 4.2.1. Transition Mode . . . . . . . . . . . . . . . . . . . 6 74 4.3. IPv6 Only Topology . . . . . . . . . . . . . . . . . . . 6 75 5. IS-IS MT and LFA . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 9.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 ISIS originally developed for OSI [ISO.10589.1992] and extensions 87 have been made available to support IPv4 [RFC1195]. A method for 88 exchanging IPv6 routing information using the IS-IS routing protocol 89 is specified in [RFC5308]. How to run a set of independent IP 90 topologies with topology specific adjacencies, within a single IS-IS 91 domain has been defined in IS-IS MT [RFC5120]. 93 Multiple mobile backhaul network user plane proposals like 94 [I-D.ietf-dmm-srv6-mobile-uplane] and [I-D.herbert-ila-mobile] use 95 IPv6 only solution using source routing, address transformation 96 respectively. It is possible to conceive, various parts of the 97 backhaul networks use IPv4 and appropriate migration strategy needed 98 before eventually moving towards IPv6 only network. While any IGP 99 can be used in these networks, this document covers only IS-IS 100 protocol aspects. 102 Various layer-3 DC fabric routing options (refs: openfabric, spine- 103 leaf, controller-based) by changing or optimizing some aspects w.r.t 104 adjacency formation, flooding optimizations, or/and mechanisms to 105 automatically compute the location of the node in the fat tree 106 topology are proposed recently and this document brings some of the 107 multi topology deployment aspects relevant to these networks. Please 108 note, part of the discussion around IS-IS MT is not specific to DC or 109 CLOS fabrics and generally applicable to any IS-IS deployment but 110 discussed here because of multiple proposals to use various forms of 111 IS-IS in this context. 113 2. Need for MT in IS-IS networks 115 For mobile transport backhaul networks seeking only IPv6 network or 116 transitioning from parts of the network with only IPv4, IS-IS MT is 117 needed. For layer-3 DC fabric underlay, which provide reachability, 118 only one address family (either IPv4 or IPv6) SHOULD be sufficient. 119 However if either only IPv6 address family is needed in the underlay 120 or deploying both IPv4 and IPv6 address families are desired 121 discussion in Section 4 is relevant. 123 It is an unlikely requirement, where DC fabric to be partitioned 124 logically to have different topologies in the underlay but this can 125 happen in various scenarios as listed in Section 4.1. 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 4. Topologies and Address Families 145 Terminology around IS-IS topologies and address families is somewhat 146 confusing at best. Just to give an example, MT ID #2 defined in 147 [RFC5120] says, it is "Reserved for IPv6 routing topology". While 148 multiple MT ID's can be deployed in a network with IPv6 topologies, 149 MT ID #2, perhaps referring to a first such topology with IPv6 only 150 address family. This section details various topology and address 151 family options possible with currently available IS-IS specifications 152 with respective defined TLVs. 154 4.1. Single Topology Mode and Multiple Address Families 156 IS-IS with IPv4 address family and with wide-metrics [RFC5305] is 157 widely deployed, with TLV 22 defined for IS Reachability and TLV 135 158 for IP (IPv4) reachability information . This is essentially a single 159 topology for the entire IS-IS area/domain with a single address 160 family (IPv4 unicast). 162 IS-IS can also be enabled with IPv6 unicast address family in a 163 single topology mode along with IPv4 unicast address family. Here 164 IPv6 uses the same underlying topology that is used for IPv4 and this 165 can be done as specified in IS-IS IPv6 [RFC5308] which introduces TLV 166 236, an IPv6 reachability TLV. It is important to note same IS-IS 167 adjacency is used for both address families and with a single SPF 168 (decision process) both IPv4 and IPv6 reachability would be computed. 170 However, for the above to work effectively, both IPv4 and IPv6 171 address families MUST share a common network topology. That is to 172 use IS-IS for IPv4 and IPv6 routing, any interface configured for 173 IPv4 IS-IS MUST also be configured for IPv6 IS-IS, and vice versa. 174 All routers within an IS-IS area (Level 1 routing) or domain (Level 2 175 routing) MUST also support the same set of address families: IPv4 176 only, IPv6 only, or both IPv4 and IPv6. Any discrepancy in the 177 configuration w.r.t above can cause routing black holes and one such 178 scenario is discussed below. 180 | / \| 181 ...Rx Ry... 182 | \ / 183 | \ / | 184 | \ / | 185 | /\ | 186 | / \ | 187 | / \| 188 ... R1 R2... 189 | \ / | 191 Figure 1: IS-IS with multiple address families 193 As shown, in the above diagram all routers in the network enabled 194 with both IPv4 and IPv6 unicast address families at the IS level and 195 single topology would be built. However, at a link level all but 196 except one link, say if IPv6 is not configured on the link between 197 the routers Rx and R2; due to a single IS-IS topology, the shortest 198 path between Rx and R2 is the direct link and since IPv6 is not 199 enabled on that link, Rx and R2 cannot exchange IPv6 data traffic 200 even though there's an alternate path between them in the topology 201 through Rx, R1, Ry and R2. 203 Hence to summarize the restrictions: all routers in the topology MUST 204 support only IPv4, only IPv6 or both IPv4 and IPv6 address families 205 on all links and node. In other words, network MUST be congruent. 206 While this model is to simpler to operate, might not be flexible 207 enough for some IS-IS deployments. Some examples where congruency is 208 not possible as follows: 210 a. When IPv6 is getting introduced in the network legacy nodes that 211 are IPv6 incapable. 213 b. Implementation issues causing IPv6 to be disabled on some nodes. 215 c. Hardware scale limitations causing IPv6 to be disabled on some 216 low-end nodes. 218 4.2. Multiple Topology Mode and Multiple Address Families 220 Multi-topology IS-IS uses multiple SPFs to compute routes and removes 221 the restriction that all interfaces MUST support all configured 222 address families and that all routers in an IS-IS area or domain MUST 223 support the same set of address families. This introduces the 224 concept of topology specific adjacency with MT IS Reachability TLV 225 222 and MT capable IPv4 Reachability with TLV 235 and MT capable IPv6 226 Reachability with TLV 237. 228 When MT IS-IS is enabled with IPv4 and IPv6 address families, the 229 routers build two topologies, one for each address family (IPv4 and 230 IPv6) and can find the optimum path for each address family even when 231 some links in the network support only one of them. IS-IS MT 232 [RFC5120] defines MT ID #0 for backward compatibility, as the 233 "standard" topology and this essentially operate as IS-IS single 234 topology mode as specified in Section 4.1 and supports both IPv4 and 235 IPv6 address families. MT ID #2 [RFC5120] is defined for IPv6 236 address family in MT mode. 238 4.2.1. Transition Mode 240 Most of the vendors supported MT transition feature (though some 241 vendors disabled to avoid confusion around this) in the IS-IS 242 networks to facilitate MT deployments without disrupting the single 243 topology mode. The MT transition mode allows a network operating in 244 single topology IS-IS IPv6 [RFC5308] to continue to work while 245 upgrading routers to include MT IS-IS IPv6 support i.e., MT ID #2 246 with [RFC5120] . While in transition mode, both types of TLVs 247 (single-topology with TLVs 22/236 and MT with TLVs 222/237) are sent 248 in LSPs for all configured IPv6 addresses, nodes can continue to 249 process these and operate in single topology mode though being in MT 250 mode ("standard" IS-IS topology with MT ID #0). After all routers in 251 the area or domain have been upgraded to support MT IPv6 transition 252 mode can be removed from the configuration. Once all routers in the 253 area or domain are operating in MT IPv6 mode, the topological 254 restrictions of single-topology mode can be made no longer in effect. 256 When transition mode is enabled, the router advertises both MT TLVs 257 and the old style IS-IS IPv6 TLVs but the topological restrictions of 258 the single topology mode discussed above are in effect. However, 259 there were instances while this mode is enabled and expectations for 260 different result in the actual deployments. 262 4.3. IPv6 Only Topology 264 Though it is theoretically possible to build IPv6 only underlay (with 265 TLV 236 for IPv6 reachability prefixes) in single topology mode as 266 discussed in Section 4.1, lot of legacy implementations require IPv4 267 address families too be configured in single topology mode (ingrained 268 code structures for IPv4 address family). IPv6 only DC underlay 269 network can be built with multi topology adjacencies (TLV 222) and 270 reachability prefixes (TLV 237) with MT ID #2 as discussed above in 271 Section 4.2. With this, any other address family can be introduced 272 including "standard" topology MT ID #0 (Single topology mode with 273 both address families) and there are no restrictions on which address 274 family has to enable on which link as specified in Section 4.1. 276 5. IS-IS MT and LFA 278 IP Fast Reroute (FRR) or Loop Free Alternative (LFA) computation in 279 MT mode are described in detail in Section 5.2 of 280 [I-D.ietf-rtgwg-multihomed-prefix-lfa]. 282 6. Acknowledgements 284 Thanks to Acee Lindem, Chris Hopps, Michael Abramson and Les Ginsberg 285 for various inputs on this work. 287 7. IANA Considerations 289 This document has no actions for IANA. 291 8. Security Considerations 293 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 294 Further security analysis for IS-IS protocol is done in [RFC7645]. 296 This document does not introduce any change in any of the IS-IS 297 protocol or IS-IS protocol extensions. This document also does not 298 introduce any new security issues other than as noted in the 299 referenced IS-IS protocol extensions. 301 9. References 303 9.1. Normative References 305 [ISO.10589.1992] 306 International Organization for Standardization, 307 "Intermediate system to intermediate system intra-domain- 308 routing routine information exchange protocol for use in 309 conjunction with the protocol for providing the 310 connectionless-mode Network Service (ISO 8473)", 311 ISO Standard 10589, 1992. 313 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 314 dual environments", RFC 1195, DOI 10.17487/RFC1195, 315 December 1990, . 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 323 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 324 May 2017, . 326 9.2. Informative References 328 [I-D.herbert-ila-mobile] 329 Herbert, T. and K. Bogineni, "Identifier Locator 330 Addressing for Mobile User-Plane", draft-herbert-ila- 331 mobile-01 (work in progress), March 2018. 333 [I-D.ietf-dmm-srv6-mobile-uplane] 334 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 335 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 336 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 337 uplane-04 (work in progress), March 2019. 339 [I-D.ietf-rtgwg-multihomed-prefix-lfa] 340 Sarkar, P., Chunduri, U., Hegde, S., Tantsura, J., and H. 341 Gredler, "Loop-Free Alternates selection for Multi-Homed 342 Prefixes", draft-ietf-rtgwg-multihomed-prefix-lfa-09 (work 343 in progress), November 2018. 345 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 346 Topology (MT) Routing in Intermediate System to 347 Intermediate Systems (IS-ISs)", RFC 5120, 348 DOI 10.17487/RFC5120, February 2008, 349 . 351 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 352 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 353 2008, . 355 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 356 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 357 2008, . 359 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 360 DOI 10.17487/RFC5308, October 2008, 361 . 363 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 364 and M. Fanto, "IS-IS Generic Cryptographic 365 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 366 2009, . 368 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 369 Authentication for Routing Protocol (KARP) IS-IS Security 370 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 371 . 373 Authors' Addresses 375 Uma Chunduri 376 Huawei USA 377 2330 Central Expressway 378 Santa Clara, CA 95050 379 USA 381 Email: uma.chunduri@huawei.com 383 Jeff Tantsura 384 Apstra, Inc. 386 Email: jefftant.ietf@gmail.com 388 Shraddha Hegde 389 Juniper Networks 390 Elnath-Exora Business Park Survey 391 Bangalore, Karnataka 560103 392 USA 394 Email: shraddha@juniper.net