Internet DRAFT - draft-chunduri-lsr-isis-mt-deployment-cons
draft-chunduri-lsr-isis-mt-deployment-cons
LSR Working Group U. Chunduri
Internet-Draft Futurewei USA
Intended status: Informational J. Tantsura
Expires: May 28, 2021 Apstra, Inc.
S. Hegde
Juniper Networks
November 24, 2020
IS-IS Multi Topology Deployment Considerations
draft-chunduri-lsr-isis-mt-deployment-cons-04
Abstract
This document analyzes IS-IS Multi Topology (MT) applicability in
various IS-IS deployments. This document explores the nuances around
the terminology and usage of various IS-IS address families,
topologies with different considerations, for choosing the right
combination for a specific deployment scenario.
This document also discusses various ways one can deploy IPv6 only
IS-IS topology.
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],
RFC8174 [RFC8174] when, and only when they appear in all capitals, as
shown here.
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 28, 2021.
Chunduri, et al. Expires May 28, 2021 [Page 1]
Internet-DraftIS-IS Multi Topology Deployment ConsiderationNovember 2020
Copyright Notice
Copyright (c) 2020 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
(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 MT in IS-IS networks . . . . . . . . . . . . . . . . 3
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Topologies and Address Families . . . . . . . . . . . . . . . 4
4.1. Single Topology Mode and Multiple Address Families . . . 4
4.2. Multiple Topology Mode and Multiple Address Families . . 5
4.2.1. Transition Mode . . . . . . . . . . . . . . . . . . . 6
4.3. IPv6 Only Topology . . . . . . . . . . . . . . . . . . . 6
5. IS-IS MT and LFA . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
IS-IS originally developed for OSI [ISO.10589.1992] and 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].
There are number of networks, including mobile backhaul networks
seeking to use IPv6 only solutions. It is possible to conceive,
various parts of the backhaul networks use IPv4 and appropriate
migration strategy needed before eventually moving towards IPv6 only
Chunduri, et al. Expires May 28, 2021 [Page 2]
Internet-DraftIS-IS Multi Topology Deployment ConsiderationNovember 2020
network. While any IGP can be used in these networks, this document
covers only IS-IS protocol aspects.
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.
2. Need for MT in IS-IS networks
For mobile transport backhaul networks seeking only IPv6 network or
transitioning from parts of the network with only IPv4, IS-IS MT is
needed. For layer-3 DC fabric underlay, which 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 but this can
happen in various scenarios as listed in Section 4.1. If one does
the same to meet a particular requirement, it introduces a
manageability complexity of these logical topologies. IS-IS MT
[RFC5120] 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 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
Chunduri, et al. Expires May 28, 2021 [Page 3]
Internet-DraftIS-IS Multi Topology Deployment ConsiderationNovember 2020
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
[RFC5120] 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 [RFC5305] 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
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.
Chunduri, et al. Expires May 28, 2021 [Page 4]
Internet-DraftIS-IS Multi Topology Deployment ConsiderationNovember 2020
| / \|
...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: 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. Some examples where congruency is
not possible as follows:
a. When IPv6 is getting introduced in the network legacy nodes that
are IPv6 incapable.
b. Implementation issues causing IPv6 to be disabled on some nodes.
c. Hardware scale limitations causing IPv6 to be disabled on some
low-end nodes.
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.
Chunduri, et al. Expires May 28, 2021 [Page 5]
Internet-DraftIS-IS Multi Topology Deployment ConsiderationNovember 2020
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
[RFC5120] 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 [RFC5120] 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 [RFC5308] to continue to work while
upgrading routers to include MT IS-IS IPv6 support i.e., MT ID #2
with [RFC5120] . While in transition mode, both types of TLVs
(single-topology with TLVs 22/236 and MT with TLVs 222/237) are sent
in LSPs for all configured IPv6 addresses, nodes can continue to
process these and 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 can be made 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. However,
there were instances while this mode is enabled and expectations for
different result in the actual deployments.
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.
Chunduri, et al. Expires May 28, 2021 [Page 6]
Internet-DraftIS-IS Multi Topology Deployment ConsiderationNovember 2020
5. IS-IS MT and LFA
IP Fast Reroute (FRR) or Loop Free Alternative (LFA) computation in
MT mode are described in detail in Section 5.2 of [RFC5120].
6. Acknowledgements
Thanks to Acee Lindem, Chris Hopps, Michael Abramson and Les Ginsberg
for various inputs on this work.
7. IANA Considerations
This document has no actions for IANA.
8. Security Considerations
Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310].
Further security analysis for IS-IS protocol is done in [RFC7645].
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.
9. References
9.1. Normative References
[ISO.10589.1992]
International Organization for Standardization,
"Intermediate system to intermediate system intra-domain-
routing routine information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)",
ISO Standard 10589, 1992.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Chunduri, et al. Expires May 28, 2021 [Page 7]
Internet-DraftIS-IS Multi Topology Deployment ConsiderationNovember 2020
9.2. Informative References
[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,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and
Authentication for Routing Protocol (KARP) IS-IS Security
Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015,
<https://www.rfc-editor.org/info/rfc7645>.
[RFC8518] Sarkar, P., Ed., Chunduri, U., Ed., Hegde, S., Tantsura,
J., and H. Gredler, "Selection of Loop-Free Alternates for
Multi-Homed Prefixes", RFC 8518, DOI 10.17487/RFC8518,
March 2019, <https://www.rfc-editor.org/info/rfc8518>.
Authors' Addresses
Uma Chunduri
Futurewei USA
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: umac.ietf@gmail.com
Chunduri, et al. Expires May 28, 2021 [Page 8]
Internet-DraftIS-IS Multi Topology Deployment ConsiderationNovember 2020
Jeff Tantsura
Apstra, Inc.
Email: jefftant.ietf@gmail.com
Shraddha Hegde
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore, Karnataka 560103
USA
Email: shraddha@juniper.net
Chunduri, et al. Expires May 28, 2021 [Page 9]
