idnits 2.17.00 (12 Aug 2021) /tmp/idnits10477/draft-ct-mt-considerations-dc-fabrics-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 (October 30, 2017) is 1657 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 217, but not defined == Missing Reference: 'RFC 5305' is mentioned on line 136, but not defined == Missing Reference: 'RFC 5308' is mentioned on line 215, but not defined == Unused Reference: 'RFC0791' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 304, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group U. Chunduri 3 Internet-Draft Huawei Technologies 4 Intended status: Informational J. Tantsura 5 Expires: May 3, 2018 Individual 6 October 30, 2017 8 Multi Topology Considerations for DC Fabrics 9 draft-ct-mt-considerations-dc-fabrics-00 11 Abstract 13 This document analyzes IS-IS Multi Topology (MT) considerations in 14 general and specific to layer-3 Data Center (DC) proposals based on 15 IS-IS protocol. This document explores various IS-IS address 16 families, topologies and considerations while choosing the right 17 combination for a specific DC 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 May 3, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 multiple topologies in fabric . . . . . . . . . . . 3 61 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Topologies and Address Families . . . . . . . . . . . . . . . 3 63 4.1. Single Topology Mode and Multiple Address Families . . . 3 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. Openfabric . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 Various layer-3 DC fabric routing options (refs: openfabric, spine- 86 leaf, controller-based) by changing or optimizing some aspects w.r.t 87 adjacency formation, flooding optimizations, or/and mechanisms to 88 automatically compute the location of the node in the fat tree 89 topology are proposed recently and this document brings some of the 90 multi topology deployment aspects relevant to these networks. Please 91 note part of the discussion around IS-IS MT is not specific to DC or 92 CLOS fabrics and generally applicable to any IS-IS deployment but 93 discussed here because of multiple proposals to use various forms of 94 IS-IS in this context. 96 2. Need for multiple topologies in fabric 98 In the spirit of DC fabric just provide reachability, only one 99 address family (either IPv4 or IPv6) SHOULD be sufficient. However 100 if either only IPv6 address family is needed in the underlay or 101 deploying both IPv4 and IPv6 address families are desired discussion 102 in Section 4 is relevant. 104 It is an unlikely requirement, where DC fabric to be partitioned 105 logically to have different topologies in the underlay. If one does 106 to meet a particular requirement, this does introduce manageability 107 complexity of these logical topologies. IS-IS MT [RFC 5120] also 108 designed to address the above need and discussion in Section 4.2 is 109 relevant. It is worth noting, majority of the IS-IS deployments (non 110 DC) use MT primarily to have a separate logical topology for IPv6 111 address family. 113 3. Acronyms 115 IIH : IS-IS Hello Protocol Data Unit 117 LSP : Link State PDU 119 MT : Multi Topology 121 SPF : Shortest Path First 123 4. Topologies and Address Families 125 Terminology around IS-IS topologies and address families is somewhat 126 confusing at best. Just to give an example, MT ID #2 defined in [RFC 127 5120] says, it is "Reserved for IPv6 routing topology". While 128 multiple MT ID's can be deployed in a network with IPv6 topologies, 129 MT ID #2, perhaps referring to a first such topology with IPv6 only 130 address family. This section details various topology and address 131 family options possible with currently available IS-IS specifications 132 with respective defined TLVs. 134 4.1. Single Topology Mode and Multiple Address Families 136 IS-IS with IPv4 address family and with wide-metrics [RFC 5305] is 137 widely deployed, with TLV 22 defined for IS Reachability and TLV 135 138 for IP (IPv4) reachability information . This is essentially a single 139 topology for the entire IS-IS area/domain with a single address 140 family (IPv4 unicast). 142 IS-IS can also be enabled with IPv6 unicast address family in a 143 single topology mode along with IPv4 unicast address family. Here 144 IPv6 uses the same underlying topology that is used for IPv4 and this 145 can be done as specified in IS-IS IPv6 [RFC5308] which introduces TLV 146 236, an IPv6 reachability TLV. It is important to note same IS-IS 147 adjacency is used for both address families and with a single SPF 148 (decision process) both IPv4 and IPv6 reachability would be computed. 150 However, for the above to work effectively, both IPv4 and IPv6 151 address families MUST share a common network topology. That is to 152 use IS-IS for IPv4 and IPv6 routing, any interface configured for 153 IPv4 IS-IS MUST also be configured for IPv6 IS-IS, and vice versa. 154 All routers within an IS-IS area (Level 1 routing) or domain (Level 2 155 routing) MUST also support the same set of address families: IPv4 156 only, IPv6 only, or both IPv4 and IPv6. Any discrepancy in the 157 configuration w.r.t above can cause routing black holes and one such 158 scenario is discussed below. 160 | / \| 161 ...Rx Ry... 162 | \ / 163 | \ / | 164 | \ / | 165 | /\ | 166 | / \ | 167 | / \| 168 ... R1 R2... 169 | \ / | 171 Figure 1: IS-IS with multiple address families 173 As shown, in the above diagram all routers in the network enabled 174 with both IPv4 and IPv6 unicast address families at the IS level and 175 single topology would be built. However, at a link level all but 176 except one link, say if IPv6 is not configured on the link between 177 the routers Rx and R2; due to a single IS-IS topology, the shortest 178 path between Rx and R2 is the direct link and since IPv6 is not 179 enabled on that link, Rx and R2 cannot exchange IPv6 data traffic 180 even though there's an alternate path between them in the topology 181 through Rx, R1, Ry and R2. 183 Hence to summarize the restrictions, as laid out above: all routers 184 in the topology MUST support only IPv4, only IPv6 or both IPv4 and 185 IPv6 address families on all links and node. In other words, network 186 MUST be congruent. While this model is to simpler to operate, might 187 not be flexible enough for some IS-IS deployments. 189 4.2. Multiple Topology Mode and Multiple Address Families 191 Multi-topology IS-IS uses multiple SPFs to compute routes and removes 192 the restriction that all interfaces MUST support all configured 193 address families and that all routers in an IS-IS area or domain MUST 194 support the same set of address families. This introduces the 195 concept of topology specific adjacency with MT IS Reachability TLV 196 222 and MT capable IPv4 Reachability with TLV 235 and MT capable IPv6 197 Reachability with TLV 237. 199 When MT IS-IS is enabled with IPv4 and IPv6 address families, the 200 routers build two topologies, one for each address family (IPv4 and 201 IPv6) and can find the optimum path for each address family even when 202 some links in the network support only one of them. IS-IS MT [RFC 203 5120] defines MT ID #0 for backward compatibility, as the "standard" 204 topology and this essentially operate as IS-IS single topology mode 205 as specified in Section 4.1 and supports both IPv4 and IPv6 address 206 families. MT ID #2 [RFC 5120] is defined for IPv6 address family in 207 MT mode. 209 4.2.1. Transition Mode 211 Most of the vendors supported MT transition feature (though some 212 vendors disabled to avoid confusion around this) in the IS-IS 213 networks to facilitate MT deployments without disrupting the single 214 topology mode. The MT transition mode allows a network operating in 215 single topology IS-IS IPv6 [RFC 5308] to continue to work while 216 upgrading routers to include MT IS-IS IPv6 support i.e., MT ID #2 217 with [RFC 5120] . While in transition mode, both types of TLVs 218 (single-topology with TLV 236 and MT with TLV 237) are sent in LSPs 219 for all configured IPv6 addresses, nodes can continue to operate in 220 single topology mode though being in MT mode ("standard" IS-IS 221 topology with MT ID #0). After all routers in the area or domain 222 have been upgraded to support MT IPv6 transition mode can be removed 223 from the configuration. Once all routers in the area or domain are 224 operating in MT IPv6 mode, the topological restrictions of single- 225 topology mode are no longer in effect. 227 When transition mode is enabled, the router advertises both MT TLVs 228 and the old style IS-IS IPv6 TLVs but the topological restrictions of 229 the single topology mode discussed above are in effect with MT 230 transition mode. However, there were instances while this is enabled 231 and folks expect a different result in the actual deployments. 233 4.3. IPv6 Only Topology 235 Though it is theoretically possible to build IPv6 only underlay (with 236 TLV 236 for IPv6 reachability prefixes) in single topology mode as 237 discussed in Section 4.1, lot of legacy implementations require IPv4 238 address families too be configured in single topology mode (ingrained 239 code structures for IPv4 address family). IPv6 only DC underlay 240 network can be built with multi topology adjacencies (TLV 222) and 241 reachability prefixes (TLV 237) with MT ID #2 as discussed above in 242 Section 4.2. With this any other address family can be introduced 243 including "standard" topology MT ID #0 (Single topology mode with 244 both address families) and there are no restrictions on which address 245 family has to enable on which link as specified in Section 4.1. 247 5. Openfabric 249 What is needed for Openfabric (TBD). Depends on Section 2; however 250 following apply - 252 o Topology specific modified adjacency formation process (if both 253 IPv4 and IPv6 address families are used with MT). 255 o Mechanisms for determining which tier within a spine and leaf 256 fabric in which the IS is located MUST be specific to MT ID # 257 (TBD). 259 o Advertisement of Reachability Information as specified in the 260 above section is specific to if MT is enabled or not. 262 o TBD. 264 6. Acknowledgements 266 Thanks to .. TBD. 268 7. IANA Considerations 270 This document has no actions for IANA. 272 8. Security Considerations 274 This document does not introduce any change in any of the IS-IS 275 protocol or IS-IS protocol extensions. This document also does not 276 introduce any new security issues other than as noted in the 277 referenced IS-IS protocol extensions. 279 9. References 281 9.1. Normative References 283 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 284 DOI 10.17487/RFC0791, September 1981, 285 . 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 9.2. Informative References 294 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 295 dual environments", RFC 1195, DOI 10.17487/RFC1195, 296 December 1990, . 298 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 299 Topology (MT) Routing in Intermediate System to 300 Intermediate Systems (IS-ISs)", RFC 5120, 301 DOI 10.17487/RFC5120, February 2008, 302 . 304 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 305 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 306 2008, . 308 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 309 DOI 10.17487/RFC5308, October 2008, 310 . 312 Authors' Addresses 314 Uma Chunduri 315 Huawei Technologies 316 2330 Central Expressway 317 Santa Clara, CA 95050 318 USA 320 Email: uma.chunduri@huawei.com 321 Jeff Tantsura 322 Individual 323 USA 325 Email: jefftant.ietf@gmail.con