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