Network Working Group U. Chunduri Internet-Draft Huawei Technologies Intended status: Informational J. Tantsura Expires: May 3, 2018 Individual October 30, 2017 Multi Topology Considerations for DC Fabrics draft-ct-mt-considerations-dc-fabrics-00 Abstract This document analyzes IS-IS Multi Topology (MT) considerations in general and specific to layer-3 Data Center (DC) proposals based on IS-IS protocol. This document explores various IS-IS address families, topologies and considerations while choosing the right combination for a specific DC deployment. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Chunduri & Tantsura Expires May 3, 2018 [Page 1] Internet-DraftMulti Topology Considerations for DC Fabrics October 2017 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Need for multiple topologies in fabric . . . . . . . . . . . 3 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Topologies and Address Families . . . . . . . . . . . . . . . 3 4.1. Single Topology Mode and Multiple Address Families . . . 3 4.2. Multiple Topology Mode and Multiple Address Families . . 5 4.2.1. Transition Mode . . . . . . . . . . . . . . . . . . . 5 4.3. IPv6 Only Topology . . . . . . . . . . . . . . . . . . . 6 5. Openfabric . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction ISIS originally developed for OSI [ISO10589], extensions have been made available to support IPv4 [RFC1195]. A method for exchanging IPv6 routing information using the IS-IS routing protocol is specified in [RFC5308]. How to run a set of independent IP topologies with topology specific adjacencies, within a single IS-IS domain has been defined in IS-IS MT [RFC5120]. Various layer-3 DC fabric routing options (refs: openfabric, spine- leaf, controller-based) by changing or optimizing some aspects w.r.t adjacency formation, flooding optimizations, or/and mechanisms to automatically compute the location of the node in the fat tree topology are proposed recently and this document brings some of the multi topology deployment aspects relevant to these networks. Please note part of the discussion around IS-IS MT is not specific to DC or CLOS fabrics and generally applicable to any IS-IS deployment but discussed here because of multiple proposals to use various forms of IS-IS in this context. Chunduri & Tantsura Expires May 3, 2018 [Page 2] Internet-DraftMulti Topology Considerations for DC Fabrics October 2017 2. Need for multiple topologies in fabric In the spirit of DC fabric just provide reachability, only one address family (either IPv4 or IPv6) SHOULD be sufficient. However if either only IPv6 address family is needed in the underlay or deploying both IPv4 and IPv6 address families are desired discussion in Section 4 is relevant. It is an unlikely requirement, where DC fabric to be partitioned logically to have different topologies in the underlay. If one does to meet a particular requirement, this does introduce manageability complexity of these logical topologies. IS-IS MT [RFC 5120] also designed to address the above need and discussion in Section 4.2 is relevant. It is worth noting, majority of the IS-IS deployments (non DC) use MT primarily to have a separate logical topology for IPv6 address family. 3. Acronyms IIH : IS-IS Hello Protocol Data Unit LSP : Link State PDU MT : Multi Topology SPF : Shortest Path First 4. Topologies and Address Families Terminology around IS-IS topologies and address families is somewhat confusing at best. Just to give an example, MT ID #2 defined in [RFC 5120] says, it is "Reserved for IPv6 routing topology". While multiple MT ID's can be deployed in a network with IPv6 topologies, MT ID #2, perhaps referring to a first such topology with IPv6 only address family. This section details various topology and address family options possible with currently available IS-IS specifications with respective defined TLVs. 4.1. Single Topology Mode and Multiple Address Families IS-IS with IPv4 address family and with wide-metrics [RFC 5305] is widely deployed, with TLV 22 defined for IS Reachability and TLV 135 for IP (IPv4) reachability information . This is essentially a single topology for the entire IS-IS area/domain with a single address family (IPv4 unicast). IS-IS can also be enabled with IPv6 unicast address family in a single topology mode along with IPv4 unicast address family. Here Chunduri & Tantsura Expires May 3, 2018 [Page 3] Internet-DraftMulti Topology Considerations for DC Fabrics October 2017 IPv6 uses the same underlying topology that is used for IPv4 and this can be done as specified in IS-IS IPv6 [RFC5308] which introduces TLV 236, an IPv6 reachability TLV. It is important to note same IS-IS adjacency is used for both address families and with a single SPF (decision process) both IPv4 and IPv6 reachability would be computed. However, for the above to work effectively, both IPv4 and IPv6 address families MUST share a common network topology. That is to use IS-IS for IPv4 and IPv6 routing, any interface configured for IPv4 IS-IS MUST also be configured for IPv6 IS-IS, and vice versa. All routers within an IS-IS area (Level 1 routing) or domain (Level 2 routing) MUST also support the same set of address families: IPv4 only, IPv6 only, or both IPv4 and IPv6. Any discrepancy in the configuration w.r.t above can cause routing black holes and one such scenario is discussed below. | / \| ...Rx Ry... | \ / | \ / | | \ / | | /\ | | / \ | | / \| ... R1 R2... | \ / | Figure 1: IS-IS with multiple address families As shown, in the above diagram all routers in the network enabled with both IPv4 and IPv6 unicast address families at the IS level and single topology would be built. However, at a link level all but except one link, say if IPv6 is not configured on the link between the routers Rx and R2; due to a single IS-IS topology, the shortest path between Rx and R2 is the direct link and since IPv6 is not enabled on that link, Rx and R2 cannot exchange IPv6 data traffic even though there's an alternate path between them in the topology through Rx, R1, Ry and R2. Hence to summarize the restrictions, as laid out above: all routers in the topology MUST support only IPv4, only IPv6 or both IPv4 and IPv6 address families on all links and node. In other words, network MUST be congruent. While this model is to simpler to operate, might not be flexible enough for some IS-IS deployments. Chunduri & Tantsura Expires May 3, 2018 [Page 4] Internet-DraftMulti Topology Considerations for DC Fabrics October 2017 4.2. Multiple Topology Mode and Multiple Address Families Multi-topology IS-IS uses multiple SPFs to compute routes and removes the restriction that all interfaces MUST support all configured address families and that all routers in an IS-IS area or domain MUST support the same set of address families. This introduces the concept of topology specific adjacency with MT IS Reachability TLV 222 and MT capable IPv4 Reachability with TLV 235 and MT capable IPv6 Reachability with TLV 237. When MT IS-IS is enabled with IPv4 and IPv6 address families, the routers build two topologies, one for each address family (IPv4 and IPv6) and can find the optimum path for each address family even when some links in the network support only one of them. IS-IS MT [RFC 5120] defines MT ID #0 for backward compatibility, as the "standard" topology and this essentially operate as IS-IS single topology mode as specified in Section 4.1 and supports both IPv4 and IPv6 address families. MT ID #2 [RFC 5120] is defined for IPv6 address family in MT mode. 4.2.1. Transition Mode Most of the vendors supported MT transition feature (though some vendors disabled to avoid confusion around this) in the IS-IS networks to facilitate MT deployments without disrupting the single topology mode. The MT transition mode allows a network operating in single topology IS-IS IPv6 [RFC 5308] to continue to work while upgrading routers to include MT IS-IS IPv6 support i.e., MT ID #2 with [RFC 5120] . While in transition mode, both types of TLVs (single-topology with TLV 236 and MT with TLV 237) are sent in LSPs for all configured IPv6 addresses, nodes can continue to operate in single topology mode though being in MT mode ("standard" IS-IS topology with MT ID #0). After all routers in the area or domain have been upgraded to support MT IPv6 transition mode can be removed from the configuration. Once all routers in the area or domain are operating in MT IPv6 mode, the topological restrictions of single- topology mode are no longer in effect. When transition mode is enabled, the router advertises both MT TLVs and the old style IS-IS IPv6 TLVs but the topological restrictions of the single topology mode discussed above are in effect with MT transition mode. However, there were instances while this is enabled and folks expect a different result in the actual deployments. Chunduri & Tantsura Expires May 3, 2018 [Page 5] Internet-DraftMulti Topology Considerations for DC Fabrics October 2017 4.3. IPv6 Only Topology Though it is theoretically possible to build IPv6 only underlay (with TLV 236 for IPv6 reachability prefixes) in single topology mode as discussed in Section 4.1, lot of legacy implementations require IPv4 address families too be configured in single topology mode (ingrained code structures for IPv4 address family). IPv6 only DC underlay network can be built with multi topology adjacencies (TLV 222) and reachability prefixes (TLV 237) with MT ID #2 as discussed above in Section 4.2. With this any other address family can be introduced including "standard" topology MT ID #0 (Single topology mode with both address families) and there are no restrictions on which address family has to enable on which link as specified in Section 4.1. 5. Openfabric What is needed for Openfabric (TBD). Depends on Section 2; however following apply - o Topology specific modified adjacency formation process (if both IPv4 and IPv6 address families are used with MT). o Mechanisms for determining which tier within a spine and leaf fabric in which the IS is located MUST be specific to MT ID # (TBD). o Advertisement of Reachability Information as specified in the above section is specific to if MT is enabled or not. o TBD. 6. Acknowledgements Thanks to .. TBD. 7. IANA Considerations This document has no actions for IANA. 8. Security Considerations This document does not introduce any change in any of the IS-IS protocol or IS-IS protocol extensions. This document also does not introduce any new security issues other than as noted in the referenced IS-IS protocol extensions. Chunduri & Tantsura Expires May 3, 2018 [Page 6] Internet-DraftMulti Topology Considerations for DC Fabrics October 2017 9. References 9.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . Authors' Addresses Uma Chunduri Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Email: uma.chunduri@huawei.com Chunduri & Tantsura Expires May 3, 2018 [Page 7] Internet-DraftMulti Topology Considerations for DC Fabrics October 2017 Jeff Tantsura Individual USA Email: jefftant.ietf@gmail.con Chunduri & Tantsura Expires May 3, 2018 [Page 8]