< draft-chunduri-lsr-isis-mt-deployment-cons-01.txt		draft-chunduri-lsr-isis-mt-deployment-cons-02.txt >
	LSR Working Group U. Chunduri		LSR Working Group U. Chunduri
	Internet-Draft Huawei USA		Internet-Draft Huawei USA
	Intended status: Standards Track J. Tantsura		Intended status: Informational J. Tantsura
	Expires: April 25, 2019 Apstra, Inc.		Expires: November 20, 2019 Apstra, Inc.
	October 22, 2018		S. Hegde
			Juniper Networks
			May 19, 2019
	IS-IS Multi Topology Deployment Considerations		IS-IS Multi Topology Deployment Considerations
	draft-chunduri-lsr-isis-mt-deployment-cons-01		draft-chunduri-lsr-isis-mt-deployment-cons-02
	Abstract		Abstract
	This document analyzes IS-IS Multi Topology (MT) considerations in		This document analyzes IS-IS Multi Topology (MT) applicability in
	various deployments (Core/Mobile Backhaul/Data Center underlays).		various deployments (Core/Mobile Backhaul/Data Center underlays).
	This document explores the nuances around the terminology and usage		This document explores the nuances around the terminology and usage
	of various IS-IS address families, topologies and considerations,		of various IS-IS address families, topologies with different
	while choosing the right combination for a specific deployment		considerations, for choosing the right combination for a specific
	scenario.		deployment scenario.
	This document also discusses various ways one can deploy IPv6 only		This document also discusses various ways one can deploy IPv6 only
	IS-IS topology.		IS-IS topology.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		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		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 25, 2019.		This Internet-Draft will expire on November 20, 2019.
	Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 30 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Need for MT in IS-IS networks . . . . . . . . . . . . . . . . 3		2. Need for MT in IS-IS networks . . . . . . . . . . . . . . . . 3
	3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Topologies and Address Families . . . . . . . . . . . . . . . 4		4. Topologies and Address Families . . . . . . . . . . . . . . . 4
	4.1. Single Topology Mode and Multiple 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. Multiple Topology Mode and Multiple Address Families . . 5
	4.2.1. Transition Mode . . . . . . . . . . . . . . . . . . . 6		4.2.1. Transition Mode . . . . . . . . . . . . . . . . . . . 6
	4.3. IPv6 Only Topology . . . . . . . . . . . . . . . . . . . 6		4.3. IPv6 Only Topology . . . . . . . . . . . . . . . . . . . 6
	5. IS-IS MT and LFA . . . . . . . . . . . . . . . . . . . . . . 6		5. IS-IS MT and LFA . . . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	ISIS originally developed for OSI [ISO10589], extensions have been		ISIS originally developed for OSI [ISO.10589.1992] and extensions
	made available to support IPv4 [RFC1195]. A method for exchanging		have been made available to support IPv4 [RFC1195]. A method for
	IPv6 routing information using the IS-IS routing protocol is		exchanging IPv6 routing information using the IS-IS routing protocol
	specified in [RFC5308]. How to run a set of independent IP		is specified in [RFC5308]. How to run a set of independent IP
	topologies with topology specific adjacencies, within a single IS-IS		topologies with topology specific adjacencies, within a single IS-IS
	domain has been defined in IS-IS MT [RFC5120].		domain has been defined in IS-IS MT [RFC5120].
	Multiple mobile backhaul network user plane proposals like		Multiple mobile backhaul network user plane proposals like
	[I-D.ietf-dmm-srv6-mobile-uplane] and [I-D.herbert-ila-mobile] use		[I-D.ietf-dmm-srv6-mobile-uplane] and [I-D.herbert-ila-mobile] use
	IPv6 only solution using source routing, address transformation		IPv6 only solution using source routing, address transformation
	respectively. It is possible to conceive, various parts of the		respectively. It is possible to conceive, various parts of the
	backhaul networks use IPv4 and appropriate migration strategy needed		backhaul networks use IPv4 and appropriate migration strategy needed
	Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018
	before eventually moving towards IPv6 only network. While any IGP		before eventually moving towards IPv6 only network. While any IGP
	can be used in these networks, this document covers only IS-IS		can be used in these networks, this document covers only IS-IS
	protocol aspects.		protocol aspects.
	Various layer-3 DC fabric routing options (refs: openfabric, spine-		Various layer-3 DC fabric routing options (refs: openfabric, spine-
	leaf, controller-based) by changing or optimizing some aspects w.r.t		leaf, controller-based) by changing or optimizing some aspects w.r.t
	adjacency formation, flooding optimizations, or/and mechanisms to		adjacency formation, flooding optimizations, or/and mechanisms to
	automatically compute the location of the node in the fat tree		automatically compute the location of the node in the fat tree
	topology are proposed recently and this document brings some of the		topology are proposed recently and this document brings some of the
	multi topology deployment aspects relevant to these networks. Please		multi topology deployment aspects relevant to these networks. Please
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 30 ¶
	For mobile transport backhaul networks seeking only IPv6 network or		For mobile transport backhaul networks seeking only IPv6 network or
	transitioning from parts of the network with only IPv4, IS-IS MT is		transitioning from parts of the network with only IPv4, IS-IS MT is
	needed. For layer-3 DC fabric underlay, which provide reachability,		needed. For layer-3 DC fabric underlay, which provide reachability,
	only one address family (either IPv4 or IPv6) SHOULD be sufficient.		only one address family (either IPv4 or IPv6) SHOULD be sufficient.
	However if either only IPv6 address family is needed in the underlay		However if either only IPv6 address family is needed in the underlay
	or deploying both IPv4 and IPv6 address families are desired		or deploying both IPv4 and IPv6 address families are desired
	discussion in Section 4 is relevant.		discussion in Section 4 is relevant.
	It is an unlikely requirement, where DC fabric to be partitioned		It is an unlikely requirement, where DC fabric to be partitioned
	logically to have different topologies in the underlay. If one does		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		the same to meet a particular requirement, it introduces a
	manageability complexity of these logical topologies. IS-IS MT		manageability complexity of these logical topologies. IS-IS MT
	[RFC5120] also designed to address the above need and discussion in		[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		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		deployments use MT primarily to have a separate logical topology for
	IPv6 address family.		IPv6 address family.
	3. Acronyms		3. Acronyms
	IIH : IS-IS Hello Protocol Data Unit		IIH : IS-IS Hello Protocol Data Unit
	LSP : Link State PDU		LSP : Link State PDU
	MT : Multi Topology		MT : Multi Topology
	SPF : Shortest Path First		SPF : Shortest Path First
	Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018
	4. Topologies and Address Families		4. Topologies and Address Families
	Terminology around IS-IS topologies and address families is somewhat		Terminology around IS-IS topologies and address families is somewhat
	confusing at best. Just to give an example, MT ID #2 defined in [RFC		confusing at best. Just to give an example, MT ID #2 defined in
	5120] says, it is "Reserved for IPv6 routing topology". While		[RFC5120] says, it is "Reserved for IPv6 routing topology". While
	multiple MT ID's can be deployed in a network with IPv6 topologies,		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		MT ID #2, perhaps referring to a first such topology with IPv6 only
	address family. This section details various topology and address		address family. This section details various topology and address
	family options possible with currently available IS-IS specifications		family options possible with currently available IS-IS specifications
	with respective defined TLVs.		with respective defined TLVs.
	4.1. Single Topology Mode and Multiple Address Families		4.1. Single Topology Mode and Multiple Address Families
	IS-IS with IPv4 address family and with wide-metrics [RFC 5305] is		IS-IS with IPv4 address family and with wide-metrics [RFC5305] is
	widely deployed, with TLV 22 defined for IS Reachability and TLV 135		widely deployed, with TLV 22 defined for IS Reachability and TLV 135
	for IP (IPv4) reachability information . This is essentially a single		for IP (IPv4) reachability information . This is essentially a single
	topology for the entire IS-IS area/domain with a single address		topology for the entire IS-IS area/domain with a single address
	family (IPv4 unicast).		family (IPv4 unicast).
	IS-IS can also be enabled with IPv6 unicast address family in a		IS-IS can also be enabled with IPv6 unicast address family in a
	single topology mode along with IPv4 unicast address family. Here		single topology mode along with IPv4 unicast address family. Here
	IPv6 uses the same underlying topology that is used for IPv4 and this		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		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		236, an IPv6 reachability TLV. It is important to note same IS-IS
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	However, for the above to work effectively, both IPv4 and IPv6		However, for the above to work effectively, both IPv4 and IPv6
	address families MUST share a common network topology. That is to		address families MUST share a common network topology. That is to
	use IS-IS for IPv4 and IPv6 routing, any interface configured for		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.		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		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		routing) MUST also support the same set of address families: IPv4
	only, IPv6 only, or both IPv4 and IPv6. Any discrepancy in the		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		configuration w.r.t above can cause routing black holes and one such
	scenario is discussed below.		scenario is discussed below.
	Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018
	| / \|		| / \|
	...Rx Ry...		...Rx Ry...
	| \ /		| \ /
	| \ / |		| \ / |
	| \ / |		| \ / |
	| /\ |		| /\ |
	| / \ |		| / \ |
	| / \|		| / \|
	... R1 R2...		... R1 R2...
	| \ / |		| \ / |
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 32 ¶
	the routers Rx and R2; due to a single IS-IS topology, the shortest		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		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		enabled on that link, Rx and R2 cannot exchange IPv6 data traffic
	even though there's an alternate path between them in the topology		even though there's an alternate path between them in the topology
	through Rx, R1, Ry and R2.		through Rx, R1, Ry and R2.
	Hence to summarize the restrictions: all routers in the topology MUST		Hence to summarize the restrictions: all routers in the topology MUST
	support only IPv4, only IPv6 or both IPv4 and IPv6 address families		support only IPv4, only IPv6 or both IPv4 and IPv6 address families
	on all links and node. In other words, network MUST be congruent.		on all links and node. In other words, network MUST be congruent.
	While this model is to simpler to operate, might not be flexible		While this model is to simpler to operate, might not be flexible
	enough for some IS-IS deployments.		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		4.2. Multiple Topology Mode and Multiple Address Families
	Multi-topology IS-IS uses multiple SPFs to compute routes and removes		Multi-topology IS-IS uses multiple SPFs to compute routes and removes
	the restriction that all interfaces MUST support all configured		the restriction that all interfaces MUST support all configured
	address families and that all routers in an IS-IS area or domain MUST		address families and that all routers in an IS-IS area or domain MUST
	support the same set of address families. This introduces the		support the same set of address families. This introduces the
	concept of topology specific adjacency with MT IS Reachability TLV		concept of topology specific adjacency with MT IS Reachability TLV
	222 and MT capable IPv4 Reachability with TLV 235 and MT capable IPv6		222 and MT capable IPv4 Reachability with TLV 235 and MT capable IPv6
	Reachability with TLV 237.		Reachability with TLV 237.
	When MT IS-IS is enabled with IPv4 and IPv6 address families, the		When MT IS-IS is enabled with IPv4 and IPv6 address families, the
	routers build two topologies, one for each address family (IPv4 and		routers build two topologies, one for each address family (IPv4 and
	IPv6) and can find the optimum path for each address family even when		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		some links in the network support only one of them. IS-IS MT
	5120] defines MT ID #0 for backward compatibility, as the "standard"		[RFC5120] defines MT ID #0 for backward compatibility, as the
	topology and this essentially operate as IS-IS single topology mode		"standard" topology and this essentially operate as IS-IS single
	as specified in Section 4.1 and supports both IPv4 and IPv6 address		topology mode as specified in Section 4.1 and supports both IPv4 and
			IPv6 address families. MT ID #2 [RFC5120] is defined for IPv6
	Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018		address family in MT mode.
	families. MT ID #2 [RFC 5120] is defined for IPv6 address family in
	MT mode.
	4.2.1. Transition Mode		4.2.1. Transition Mode
	Most of the vendors supported MT transition feature (though some		Most of the vendors supported MT transition feature (though some
	vendors disabled to avoid confusion around this) in the IS-IS		vendors disabled to avoid confusion around this) in the IS-IS
	networks to facilitate MT deployments without disrupting the single		networks to facilitate MT deployments without disrupting the single
	topology mode. The MT transition mode allows a network operating in		topology mode. The MT transition mode allows a network operating in
	single topology IS-IS IPv6 [RFC 5308] to continue to work while		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		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		with [RFC5120] . While in transition mode, both types of TLVs
	(single-topology with TLV 236 and MT with TLV 237) are sent in LSPs		(single-topology with TLVs 22/236 and MT with TLVs 222/237) are sent
	for all configured IPv6 addresses, nodes can continue to operate in		in LSPs for all configured IPv6 addresses, nodes can continue to
	single topology mode though being in MT mode ("standard" IS-IS		process these and operate in single topology mode though being in MT
	topology with MT ID #0). After all routers in the area or domain		mode ("standard" IS-IS topology with MT ID #0). After all routers in
	have been upgraded to support MT IPv6 transition mode can be removed		the area or domain have been upgraded to support MT IPv6 transition
	from the configuration. Once all routers in the area or domain are		mode can be removed from the configuration. Once all routers in the
	operating in MT IPv6 mode, the topological restrictions of single-		area or domain are operating in MT IPv6 mode, the topological
	topology mode are no longer in effect.		restrictions of single-topology mode can be made no longer in effect.
	When transition mode is enabled, the router advertises both MT TLVs		When transition mode is enabled, the router advertises both MT TLVs
	and the old style IS-IS IPv6 TLVs but the topological restrictions of		and the old style IS-IS IPv6 TLVs but the topological restrictions of
	the single topology mode discussed above are in effect with MT		the single topology mode discussed above are in effect. However,
	transition mode. However, there were instances while this is enabled		there were instances while this mode is enabled and expectations for
	and folks expect a different result in the actual deployments.		different result in the actual deployments.
	4.3. IPv6 Only Topology		4.3. IPv6 Only Topology
	Though it is theoretically possible to build IPv6 only underlay (with		Though it is theoretically possible to build IPv6 only underlay (with
	TLV 236 for IPv6 reachability prefixes) in single topology mode as		TLV 236 for IPv6 reachability prefixes) in single topology mode as
	discussed in Section 4.1, lot of legacy implementations require IPv4		discussed in Section 4.1, lot of legacy implementations require IPv4
	address families too be configured in single topology mode (ingrained		address families too be configured in single topology mode (ingrained
	code structures for IPv4 address family). IPv6 only DC underlay		code structures for IPv4 address family). IPv6 only DC underlay
	network can be built with multi topology adjacencies (TLV 222) and		network can be built with multi topology adjacencies (TLV 222) and
	reachability prefixes (TLV 237) with MT ID #2 as discussed above in		reachability prefixes (TLV 237) with MT ID #2 as discussed above in
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 11 ¶
	including "standard" topology MT ID #0 (Single topology mode with		including "standard" topology MT ID #0 (Single topology mode with
	both address families) and there are no restrictions on which address		both address families) and there are no restrictions on which address
	family has to enable on which link as specified in Section 4.1.		family has to enable on which link as specified in Section 4.1.
	5. IS-IS MT and LFA		5. IS-IS MT and LFA
	IP Fast Reroute (FRR) or Loop Free Alternative (LFA) computation in		IP Fast Reroute (FRR) or Loop Free Alternative (LFA) computation in
	MT mode are described in detail in Section 5.2 of		MT mode are described in detail in Section 5.2 of
	[I-D.ietf-rtgwg-multihomed-prefix-lfa].		[I-D.ietf-rtgwg-multihomed-prefix-lfa].
	Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018
	6. Acknowledgements		6. Acknowledgements
	Thanks to .. TBD.		Thanks to Acee Lindem, Chris Hopps, Michael Abramson and Les Ginsberg
			for various inputs on this work.
	7. IANA Considerations		7. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	8. Security Considerations		8. Security Considerations
	Security concerns for IS-IS are addressed in [RFC5304]and [RFC5310].		Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310].
	Further security analysis for IS-IS protocol is done in [RFC7645].		Further security analysis for IS-IS protocol is done in [RFC7645].
	This document does not introduce any change in any of the IS-IS		This document does not introduce any change in any of the IS-IS
	protocol or IS-IS protocol extensions. This document also does not		protocol or IS-IS protocol extensions. This document also does not
	introduce any new security issues other than as noted in the		introduce any new security issues other than as noted in the
	referenced IS-IS protocol extensions.		referenced IS-IS protocol extensions.
	9. References		9. References
	9.1. Normative 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		[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
	dual environments", RFC 1195, DOI 10.17487/RFC1195,		dual environments", RFC 1195, DOI 10.17487/RFC1195,
	December 1990, <https://www.rfc-editor.org/info/rfc1195>.		December 1990, <https://www.rfc-editor.org/info/rfc1195>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<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>.
	9.2. Informative References		9.2. Informative References
	[I-D.herbert-ila-mobile]		[I-D.herbert-ila-mobile]
	Herbert, T. and K. Bogineni, "Identifier Locator		Herbert, T. and K. Bogineni, "Identifier Locator
	Addressing for Mobile User-Plane", draft-herbert-ila-		Addressing for Mobile User-Plane", draft-herbert-ila-
	mobile-01 (work in progress), March 2018.		mobile-01 (work in progress), March 2018.
	[I-D.ietf-dmm-srv6-mobile-uplane]		[I-D.ietf-dmm-srv6-mobile-uplane]
	Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,		Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
	daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing		daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing
	IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-		IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-
	uplane-03 (work in progress), October 2018.		uplane-04 (work in progress), March 2019.
	Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018
	[I-D.ietf-rtgwg-multihomed-prefix-lfa]		[I-D.ietf-rtgwg-multihomed-prefix-lfa]
	Sarkar, P., Chunduri, U., Hegde, S., Tantsura, J., and H.		Sarkar, P., Chunduri, U., Hegde, S., Tantsura, J., and H.
	Gredler, "LFA selection for Multi-Homed Prefixes", draft-		Gredler, "Loop-Free Alternates selection for Multi-Homed
	ietf-rtgwg-multihomed-prefix-lfa-08 (work in progress),		Prefixes", draft-ietf-rtgwg-multihomed-prefix-lfa-09 (work
	October 2018.		in progress), November 2018.
	[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi		[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
	Topology (MT) Routing in Intermediate System to		Topology (MT) Routing in Intermediate System to
	Intermediate Systems (IS-ISs)", RFC 5120,		Intermediate Systems (IS-ISs)", RFC 5120,
	DOI 10.17487/RFC5120, February 2008,		DOI 10.17487/RFC5120, February 2008,
	<https://www.rfc-editor.org/info/rfc5120>.		<https://www.rfc-editor.org/info/rfc5120>.
	[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic		[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
	Authentication", RFC 5304, DOI 10.17487/RFC5304, October		Authentication", RFC 5304, DOI 10.17487/RFC5304, October
	2008, <https://www.rfc-editor.org/info/rfc5304>.		2008, <https://www.rfc-editor.org/info/rfc5304>.
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 20 ¶
	Authors' Addresses		Authors' Addresses
	Uma Chunduri		Uma Chunduri
	Huawei USA		Huawei USA
	2330 Central Expressway		2330 Central Expressway
	Santa Clara, CA 95050		Santa Clara, CA 95050
	USA		USA
	Email: uma.chunduri@huawei.com		Email: uma.chunduri@huawei.com
	Internet-DrafIS-IS Multi Topology Deployment Considerations October 2018
	Jeff Tantsura		Jeff Tantsura
	Apstra, Inc.		Apstra, Inc.
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
			Shraddha Hegde
			Juniper Networks
			Elnath-Exora Business Park Survey
			Bangalore, Karnataka 560103
			USA
			Email: shraddha@juniper.net
End of changes. 30 change blocks.
	66 lines changed or deleted		75 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/