< draft-ietf-mpls-ldp-mrt-03.txt		draft-ietf-mpls-ldp-mrt-04.txt >
	MPLS Working Group A. Atlas		MPLS Working Group A. Atlas
	Internet-Draft K. Tiruveedhula		Internet-Draft K. Tiruveedhula
	Intended status: Standards Track C. Bowers		Intended status: Standards Track C. Bowers
	Expires: November 19, 2016 Juniper Networks		Expires: April 2, 2017 Juniper Networks
	J. Tantsura		J. Tantsura
	Individual		Individual
	IJ. Wijnands		IJ. Wijnands
	Cisco Systems, Inc.		Cisco Systems, Inc.
	May 18, 2016		September 29, 2016
	LDP Extensions to Support Maximally Redundant Trees		LDP Extensions to Support Maximally Redundant Trees
	draft-ietf-mpls-ldp-mrt-03		draft-ietf-mpls-ldp-mrt-04
	Abstract		Abstract
	This document specifies extensions to the Label Distribution		This document specifies extensions to the Label Distribution
	Protocol(LDP) to support the creation of label-switched paths for		Protocol(LDP) to support the creation of label-switched paths for
	Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast		Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast
	and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR.		and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR.
	The sole protocol extension to LDP is simply the ability to advertise		The sole protocol extension to LDP is simply the ability to advertise
	an MRT Capability. This document describes that extension and the		an MRT Capability. This document describes that extension and the
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 November 19, 2016.		This Internet-Draft will expire on April 2, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document describes the LDP signaling extension and associated		This document describes the LDP signaling extension and associated
	behavior necessary to support the architecture that defines how IP/		behavior necessary to support the architecture that defines how IP/
	LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture].		LDP Fast-Reroute can use MRTs [RFC7812]. It is necessary to be
	It is necessary to be familiar with the architecture in		familiar with the architecture in [RFC7812] to understand how and why
	[I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the		the LDP extensions for behavior are needed.
	LDP extensions for behavior are needed.
	At least one common standardized algorithm (e.g. the MRT Lowpoint		At least one common standardized algorithm (e.g. the MRT Lowpoint
	algorithm explained and fully documented in		algorithm explained and fully documented in [RFC7811]) is required so
	[I-D.ietf-rtgwg-mrt-frr-algorithm]) is required so that the routers		that the routers supporting MRT computation consistently compute the
	supporting MRT computation consistently compute the same MRTs. LDP		same MRTs. LDP depends on an IGP for computation of MRTs and
	depends on an IGP for computation of MRTs and alternates. Extensions		alternates. Extensions to OSPF are defined in [I-D.ietf-ospf-mrt].
	to OSPF are defined in [I-D.ietf-ospf-mrt]. Extension to IS-IS are		Extension to IS-IS are defined in [I-D.ietf-isis-mrt].
	defined in [I-D.ietf-isis-mrt].
	MRT can also be used to protect multicast traffic (signalled via PIM		MRT can also be used to protect multicast traffic (signalled via PIM
	or mLDP) using either global protection or local protection		or mLDP) using either global protection or local protection
	[I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used to provide		[I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used to provide
	node-protection for mLDP traffic via the mechanisms described in		node-protection for mLDP traffic via the mechanisms described in
	[I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be		[I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be
	used to provide link protection for mLDP traffic.		used to provide link protection for mLDP traffic.
	For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates		For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates
	two alternate destination-based trees separate from the shortest path		two alternate destination-based trees separate from the shortest path
	forwarding used during stable operation. LDP uses the multi-topology		forwarding used during stable operation. LDP uses the multi-topology
	extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs)		extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs)
	for these two sets of forwarding trees, MRT-Blue and MRT-Red.		for these two sets of forwarding trees, MRT-Blue and MRT-Red.
	In order to create MRT paths and support IP/LDP Fast-Reroute, a new		In order to create MRT paths and support IP/LDP Fast-Reroute, a new
	capability extension is needed for LDP. An LDP implementation		capability extension is needed for LDP. An LDP implementation
	supporting MRT MUST also follow the rules described here for		supporting MRT MUST also follow the rules described here for
	originating and managing FECs related to MRT, as indicated by their		originating and managing FECs related to MRT, as indicated by their
	multi-topology ID. Network reconvergence is described in		multi-topology ID. Network reconvergence is described in [RFC7812]
	[I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network		and the worst-case network convergence time can be flooded via the
	convergence time can be flooded via the extension in Section 7 of		extension in Section 7 of [I-D.ietf-ospf-mrt].
	[I-D.ietf-ospf-mrt].
	IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and		IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and
	node failures in an arbitrary network topology where the failure		node failures in an arbitrary network topology where the failure
	doesn't partition the network. It can also be deployed		doesn't partition the network. It can also be deployed
	incrementally; an MRT Island is formed of connected supporting		incrementally; an MRT Island is formed of connected supporting
	routers and the MRTs are computed inside that island.		routers and the MRTs are computed inside that island.
	2. Requirements Language		2. 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]		document are to be interpreted as described in [RFC2119]
	3. Terminology		3. Terminology
	For ease of reading, some of the terminology defined in		For ease of reading, some of the terminology defined in [RFC7812] is
	[I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here.		repeated here.
	Redundant Trees (RT): A pair of trees where the path from any node		Redundant Trees (RT): A pair of trees where the path from any node
	X to the root R along the first tree is node-disjoint with the		X to the root R along the first tree is node-disjoint with the
	path from the same node X to the root along the second tree.		path from the same node X to the root along the second tree.
	These can be computed in 2-connected graphs.		Redundant trees can always be computed in 2-connected graphs.
	Maximally Redundant Trees (MRT): A pair of trees where the path		Maximally Redundant Trees (MRT): A pair of trees where the path
	from any node X to the root R along the first tree and the path		from any node X to the root R along the first tree and the path
	from the same node X to the root along the second tree share the		from the same node X to the root along the second tree share the
	minimum number of nodes and the minimum number of links. Each		minimum number of nodes and the minimum number of links. Each
	such shared node is a cut-vertex. Any shared links are cut-links.		such shared node is a cut-vertex. Any shared links are cut-links.
	Any RT is an MRT but many MRTs are not RTs. The two MRTs are		In graphs that are not 2-connected, it is not possible to compute
	referred to as MRT-Blue and MRT-Red.		RTs. However, it is possible to compute MRTs. MRTs are maximally
			redundant in the sense that they are as redundant as possible
			given the constraints of the network graph.
	MRT-Red: MRT-Red is used to describe one of the two MRTs; it is		MRT-Red: MRT-Red is used to describe one of the two MRTs; it is
	used to described the associated forwarding topology and MT-ID.		used to describe the associated forwarding topology and MPLS
	Specifically, MRT-Red is the decreasing MRT where links in the		Multi-Topology IDentifier (MT-ID). Specifically, MRT-Red is the
	GADAG are taken in the direction from a higher topologically		decreasing MRT where links in the GADAG are taken in the direction
	ordered node to a lower one.		from a higher topologically ordered node to a lower one.
	MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is		MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is
	used to described the associated forwarding topology and MT-ID.		used to described the associated forwarding topology and MPLS MT-
	Specifically, MRT-Blue is the increasing MRT where links in the		ID. Specifically, MRT-Blue is the increasing MRT where links in
	GADAG are taken in the direction from a lower topologically		the GADAG are taken in the direction from a lower topologically
	ordered node to a higher one.		ordered node to a higher one.
	Rainbow MRT MT-ID: It is useful to have an MT-ID that refers to the		Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the
	multiple MRT topologies and to the default topology. This is		multiple MRT forwarding topologies and to the default forwarding
	referred to as the Rainbow MRT MT-ID and is used by LDP to reduce		topology. This is referred to as the Rainbow MRT MPLS MT-ID and
	signaling and permit the same label to always be advertised to all		is used by LDP to reduce signaling and permit the same label to
	peers for the same (MT-ID, Prefix).		always be advertised to all peers for the same (MT-ID, Prefix).
	MRT Island: From the computing router, the set of routers that		MRT Island: The set of routers that support a particular MRT
	support a particular MRT profile and are connected via MRT-		profile and the links connecting them that support MRT.
	eligible links.
	Island Border Router (IBR): A router in the MRT Island that is		Island Border Router (IBR): A router that is not in the MRT Island
	connected to a router not in the MRT Island and both routers are		but is adjacent to an IBR and in the same area/level as the IBR.
	in a common area or level.
	Island Neighbor (IN): A router that is not in the MRT Island but is		Island Neighbor (IN): A router that is not in the MRT Island but is
	adjacent to an IBR and in the same area/level as the IBR..		adjacent to an IBR and in the same area/level as the IBR..
	4. Overview of LDP Signaling Extensions for MRT		4. Overview of LDP Signaling Extensions for MRT
	Routers need to know which of their LDP neighbors support MRT. This		Routers need to know which of their LDP neighbors support MRT. This
	is communicated using the MRT Capability Advertisement. Supporting		is communicated using the MRT Capability Advertisement. Supporting
	MRT indicates several different aspects of behavior, as listed below.		MRT indicates several different aspects of behavior, as listed below.
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 14 ¶
	and shortest path FEC-label bindings for IPv4 only (or IPv6 only)		and shortest path FEC-label bindings for IPv4 only (or IPv6 only)
	would be expected to advertise MRT-related FEC-label binding for IPv4		would be expected to advertise MRT-related FEC-label binding for IPv4
	only (or IPv6 only). An LSR advertising the MRT LDP capability and		only (or IPv6 only). An LSR advertising the MRT LDP capability and
	shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected		shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected
	to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6.		to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6.
	In this scenario, advertising MRT-related FEC-label bindings only for		In this scenario, advertising MRT-related FEC-label bindings only for
	IPv4 only (or only for IPv6) is not supported.		IPv4 only (or only for IPv6) is not supported.
	4.2. Use of the Rainbow MRT MT-ID		4.2. Use of the Rainbow MRT MT-ID
	Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the		Section 10.1 of [RFC7812] describes the need for an area border
	need for an area border router (ABR) to have different neighbors use		router (ABR) to have different neighbors use different MPLS labels
	different MPLS labels when sending traffic to the ABR for the same		when sending traffic to the ABR for the same FEC. More detailed
	FEC. More detailed discussion of the Rainbow MRT MT-ID is provided		discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1 of
	in Section 5.1.1.		the current document.
	Another use for the Rainbow MRT MT-ID is for an LSR to send the		Another use for the Rainbow MRT MT-ID is for an LSR to send the
	Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate		Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate
	penultimate-hop-popping for all three types of FECs (shortest path,		penultimate-hop-popping for all three types of FECs (shortest path,
	red, and blue). The EXPLICIT_NULL label advertised using the Rainbow		red, and blue). The EXPLICIT_NULL label advertised using the Rainbow
	MRT MT-ID similarly applies to all the types of FECs. Note that the		MRT MT-ID similarly applies to all the types of FECs. Note that the
	only scenario in which it is generally useful to advertise the		only scenario in which it is generally useful to advertise the
	implicit or explicit null label for all three FEC types is when the		implicit or explicit null label for all three FEC types is when the
	FEC refers to the LSR itself. See Section 5.2.3 for more details.		FEC refers to the LSR itself. See Section 5.2.3 for more details.
	The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be		The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be
	assigned by IANA from the MPLS MT-ID space. Prototype experiments		assigned by IANA from the MPLS MT-ID space. Prototype experiments
	have used the value 3999.		have used the value 3999.
	4.3. MRT-Blue and MRT-Red FECs		4.3. MRT-Blue and MRT-Red FECs
	To provide MRT support in LDP, the MT Prefix FEC is used.		To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812]
	[I-D.ietf-rtgwg-mrt-frr-architecture] defines the Default MRT		defines the Default MRT Profile. This document contains the IANA
	Profile. This document contains the IANA request for the MRT-Red and		request for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the
	MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (TBD-		Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5).
	MRT-LDP-4 and TBD-MRT-LDP-5).
	The MT Prefix FEC encoding is defined in [RFC7307] and is used		The MT Prefix FEC encoding is defined in [RFC7307] and is used
	without alteration for advertising label mappings for MRT-Blue, MRT-		without alteration for advertising label mappings for MRT-Blue, MRT-
	Red and Rainbow MRT FECs.		Red and Rainbow MRT FECs.
	5. LDP MRT FEC Advertisements		5. LDP MRT FEC Advertisements
	This sections describes how and when labels for MRT-Red and MRT-Blue		This sections describes how and when labels for MRT-Red and MRT-Blue
	FECs are advertised. The associated LSPs must be created before a		FECs are advertised. The associated LSPs must be created before a
	failure occurs, in order to provide protection paths which are		failure occurs, in order to provide protection paths which are
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 20 ¶
	a given prefix as determined by a particular MRT algorithm.		a given prefix as determined by a particular MRT algorithm.
	We first describe label distribution behavior specific to MRT. Then		We first describe label distribution behavior specific to MRT. Then
	we provide the correct interpretation of several important concepts		we provide the correct interpretation of several important concepts
	in [RFC5036] in the context of MRT FEC label distribution.		in [RFC5036] in the context of MRT FEC label distribution.
	5.1. MRT-specific behavior		5.1. MRT-specific behavior
	5.1.1. ABR behavior and use of the Rainbow FEC		5.1.1. ABR behavior and use of the Rainbow FEC
	Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the		Section 10.1 of [RFC7812] describes the need for an area border
	need for an area border router (ABR) to have different neighbors use		router (ABR) to have different neighbors use different MPLS labels
	different MPLS labels when sending traffic to the ABR for the same		when sending traffic to the ABR for the same FEC. The method to
	FEC. The method to accomplish this using the Rainbow MRT MT-ID is		accomplish this using the Rainbow MRT MT-ID is described in detail in
	described in detail in [I-D.ietf-rtgwg-mrt-frr-architecture]. Here		[RFC7812]. Here we provide a brief summary. To those LDP peers in
	we provide a brief summary. To those LDP peers in the same area as		the same area as the best route to the destination, the ABR
	the best route to the destination, the ABR advertises two different		advertises two different labels corresponding to the MRT-Red and MRT-
	labels corresponding to the MRT-Red and MRT-Blue forwarding trees for		Blue forwarding trees for the destination. An LDP peer receiving
	the destination. An LDP peer receiving these advertisements forwards		these advertisements forwards MRT traffic to the ABR using these two
	MRT traffic to the ABR using these two different labels, depending on		different labels, depending on the FEC of the traffic. We refer to
	the FEC of the traffic. We refer to this as best-area advertising		this as best-area advertising and forwarding behavior, which is
	and forwarding behavior, which is identical to normal MRT behavior.		identical to normal MRT behavior.
	For all other LDP peers supporting MRT, the ABR advertises a FEC-		For all other LDP peers supporting MRT, the ABR advertises a FEC-
	label binding for the Rainbow MRT MT-ID scoped FEC with the label		label binding for the Rainbow MRT MT-ID scoped FEC with the label
	corresponding to the default forwarding tree for the destination. An		corresponding to the default forwarding tree for the destination. An
	LDP peer receiving this advertisement forwards MRT traffic to the ABR		LDP peer receiving this advertisement forwards MRT traffic to the ABR
	using this label, for both MRT Red and MRT Blue traffic. We refer to		using this label, for both MRT Red and MRT Blue traffic. We refer to
	this as non-best-area advertising and forwarding behavior.		this as non-best-area advertising and forwarding behavior.
	The use of the Rainbow-FEC by the ABR for non-best-area		The use of the Rainbow-FEC by the ABR for non-best-area
	advertisements is RECOMMENDED. An ABR MAY advertise the label for		advertisements is RECOMMENDED. An ABR MAY advertise the label for
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 23 ¶
	mapping for the red or blue FEC, and it MUST send a Label Release		mapping for the red or blue FEC, and it MUST send a Label Release
	Message corresponding to the rainbow FEC label advertisement. If an		Message corresponding to the rainbow FEC label advertisement. If an
	LSR receives a label mapping advertisement for red or blue FEC while		LSR receives a label mapping advertisement for red or blue FEC while
	it still retains a label mapping for the corresponding rainbow FEC,		it still retains a label mapping for the corresponding rainbow FEC,
	the LSR MUST continue to use the label mapping for the rainbow FEC,		the LSR MUST continue to use the label mapping for the rainbow FEC,
	and it MUST send a Label Release Message corresponding to the red or		and it MUST send a Label Release Message corresponding to the red or
	blue FEC label advertisement.		blue FEC label advertisement.
	5.1.2. Proxy-node attachment router behavior		5.1.2. Proxy-node attachment router behavior
	Section 11.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes how		Section 11.2 of [RFC7812] describes how MRT provides FRR protection
	MRT provides FRR protection for multi-homed prefixes using		for multi-homed prefixes using calculations involving a named proxy-
	calculations involving a named proxy-node. This covers the scenario		node. This covers the scenario where a prefix is originated by a
	where a prefix is originated by a router in the same area as the MRT		router in the same area as the MRT Island, but outside of the MRT
	Island, but outside of the MRT Island. It also covers the scenario		Island. It also covers the scenario of a prefix being advertised by
	of a prefix being advertised by a multiple routers in the MRT Island.		a multiple routers in the MRT Island.
	In the named proxy-node calculation, each multi-homed prefix is		In the named proxy-node calculation, each multi-homed prefix is
	represented by a conceptual proxy-node which is attached to two real		represented by a conceptual proxy-node which is attached to two real
	proxy-node attachment routers. (A single proxy-node attachment		proxy-node attachment routers. (A single proxy-node attachment
	router is allowed in the case of a prefix advertised by a same area		router is allowed in the case of a prefix advertised by a same area
	router outside of the MRT Island which is singly connected to the MRT		router outside of the MRT Island which is singly connected to the MRT
	Island.) All routers in the MRT Island perform the same calculations		Island.) All routers in the MRT Island perform the same calculations
	to determine the same two proxy-node attachment routers for each		to determine the same two proxy-node attachment routers for each
	multi-homed prefix. [I-D.ietf-rtgwg-mrt-frr-algorithm] describes the		multi-homed prefix. [RFC7811] describes the procedure for
	procedure for identifying one proxy-node attachment router as "red"		identifying one proxy-node attachment router as "red" and one as
	and one as "blue" with respect to the multi-homed prefix, and		"blue" with respect to the multi-homed prefix, and computing the MRT
	computing the MRT red and blue next-hops to reach those red and blue		red and blue next-hops to reach those red and blue proxy-node
	proxy-node attachment routers.		attachment routers.
	In terms of LDP behavior, a red proxy-node attachment router for a		In terms of LDP behavior, a red proxy-node attachment router for a
	given prefix MUST originate a label mapping for the red FEC for that		given prefix MUST originate a label mapping for the red FEC for that
	prefix, while the a blue proxy-node attachment router for a given		prefix, while the a blue proxy-node attachment router for a given
	prefix MUST originate a label mapping for the blue FEC for that		prefix MUST originate a label mapping for the blue FEC for that
	prefix. If the red(blue) proxy-node attachment router is an Island		prefix. If the red(blue) proxy-node attachment router is an Island
	Border Router (IBR), then when it receives a packet with the label		Border Router (IBR), then when it receives a packet with the label
	corresponding to the red(blue) FEC for a prefix, it MUST forward the		corresponding to the red(blue) FEC for a prefix, it MUST forward the
	packet to the Island Neighbor (IN) whose whose cost was used in the		packet to the Island Neighbor (IN) whose whose cost was used in the
	selection of the IBR as a proxy-node attachment router. The IBR MUST		selection of the IBR as a proxy-node attachment router. The IBR MUST
	skipping to change at page 13, line 38 ¶		skipping to change at page 13, line 36 ¶
	5.2.7. Not propagating Rainbow FEC label mappings		5.2.7. Not propagating Rainbow FEC label mappings
	A label mapping for the Rainbow FEC should only be originated by an		A label mapping for the Rainbow FEC should only be originated by an
	ABR under the conditions described in Section 5.1.1. A neighbor of		ABR under the conditions described in Section 5.1.1. A neighbor of
	the ABR that receives a label mapping for the Rainbow FEC MUST NOT		the ABR that receives a label mapping for the Rainbow FEC MUST NOT
	propagate a label mapping for that Rainbow FEC.		propagate a label mapping for that Rainbow FEC.
	6. Security Considerations		6. Security Considerations
	The labels distributed by the extensions in this document create		The labels distributed by the extensions in this document create
	additional forwarding paths that do not following shortest path		additional forwarding paths that do not follow shortest path routes.
	routes. The transit label swapping operations defining these		The transit label swapping operations defining these alternative
	alternative forwarding paths are created during normal operations		forwarding paths are created during normal operations (before a
	(before a failure occurs). Therefore, a malicious packet with an		failure occurs). Therefore, a malicious packet with an appropriate
	appropriate label injected into the network from a compromised		label injected into the network from a compromised location would be
	location would be forwarded to a destination along a non-shortest		forwarded to a destination along a non-shortest path. When this
	path. When this technology is deployed, a network security design		technology is deployed, a network security design should not rely on
	should not rely on assumptions about potentially malicious traffic		assumptions about potentially malicious traffic only following
	only following shortest paths.		shortest paths.
	It should be noted that the creation of non-shortest forwarding paths		It should be noted that the creation of non-shortest forwarding paths
	is not unique to MRT.		is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to
			construct forwarding paths that do not follow the shortest path.
	7. Potential restrictions on MRT-related MT-ID values imposed by		7. Potential restrictions on MRT-related MT-ID values imposed by
	RFC6420		RFC6420
	As discussed in the introduction, in addition to unicast forwarding		As discussed in the introduction, in addition to unicast forwarding
	applications, MRT can be used to provide disjoint trees for multicast		applications, MRT can be used to provide disjoint trees for multicast
	traffic distribution. In the case of PIM, this is accomplished by		traffic distribution. In the case of PIM, this is accomplished by
	using the MRT red and blue next-hops as the PIM RPF topology, the		using the MRT red and blue next-hops as the PIM RPF topology, the
	collection of routes used by PIM to perform the RPF operation when		collection of routes used by PIM to perform the RPF operation when
	building source trees. The PIM Multi-Topology ID (MT-ID) Join		building source trees. The PIM Multi-Topology ID (MT-ID) Join
	skipping to change at page 16, line 9 ¶		skipping to change at page 16, line 9 ¶
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Ross Callon, Loa Andersson, Stewart		The authors would like to thank Ross Callon, Loa Andersson, Stewart
	Bryant, Mach Chen, and Greg Mirsky for their suggestions.		Bryant, Mach Chen, and Greg Mirsky for their suggestions.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-rtgwg-mrt-frr-algorithm]
	Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
	Gopalan, "Algorithms for computing Maximally Redundant
	Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
	algorithm-05 (work in progress), July 2015.
	[I-D.ietf-rtgwg-mrt-frr-architecture]
	Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
	A., Tantsura, J., and R. White, "An Architecture for IP/
	LDP Fast-Reroute Using Maximally Redundant Trees", draft-
	ietf-rtgwg-mrt-frr-architecture-05 (work in progress),
	January 2015.
	[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,		"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
	October 2007, <http://www.rfc-editor.org/info/rfc5036>.		October 2007, <http://www.rfc-editor.org/info/rfc5036>.
	[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.		[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
	Le Roux, "LDP Capabilities", RFC 5561,		Le Roux, "LDP Capabilities", RFC 5561,
	DOI 10.17487/RFC5561, July 2009,		DOI 10.17487/RFC5561, July 2009,
	<http://www.rfc-editor.org/info/rfc5561>.		<http://www.rfc-editor.org/info/rfc5561>.
	[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join		[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
	Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011,		Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011,
	<http://www.rfc-editor.org/info/rfc6420>.		<http://www.rfc-editor.org/info/rfc6420>.
	[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.		[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
	King, "LDP Extensions for Multi-Topology", RFC 7307,		King, "LDP Extensions for Multi-Topology", RFC 7307,
	DOI 10.17487/RFC7307, July 2014,		DOI 10.17487/RFC7307, July 2014,
	<http://www.rfc-editor.org/info/rfc7307>.		<http://www.rfc-editor.org/info/rfc7307>.
			[RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
			Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
			Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
			DOI 10.17487/RFC7811, June 2016,
			<http://www.rfc-editor.org/info/rfc7811>.
			[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
			IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
			FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
			<http://www.rfc-editor.org/info/rfc7812>.
	10.2. Informative References		10.2. Informative References
	[I-D.atlas-rtgwg-mrt-mc-arch]		[I-D.atlas-rtgwg-mrt-mc-arch]
	Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.		Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.
	Envedi, "An Architecture for Multicast Protection Using		Envedi, "An Architecture for Multicast Protection Using
	Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc-		Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc-
	arch-02 (work in progress), July 2013.		arch-02 (work in progress), July 2013.
	[I-D.ietf-isis-mrt]		[I-D.ietf-isis-mrt]
	Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J.		Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J.
	Tantsura, "Intermediate System to Intermediate System (IS-		Tantsura, "Intermediate System to Intermediate System (IS-
	IS) Extensions for Maximally Redundant Trees (MRT)",		IS) Extensions for Maximally Redundant Trees (MRT)",
	draft-ietf-isis-mrt-00 (work in progress), February 2015.		draft-ietf-isis-mrt-02 (work in progress), May 2016.
	[I-D.ietf-ospf-mrt]		[I-D.ietf-ospf-mrt]
	Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,		Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
	"OSPF Extensions to Support Maximally Redundant Trees",		"OSPF Extensions to Support Maximally Redundant Trees",
	draft-ietf-ospf-mrt-00 (work in progress), January 2015.		draft-ietf-ospf-mrt-02 (work in progress), May 2016.
	[I-D.wijnands-mpls-mldp-node-protection]		[I-D.wijnands-mpls-mldp-node-protection]
	Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,		Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,
	A., and Q. Zhao, "mLDP Node Protection", draft-wijnands-		A., and Q. Zhao, "mLDP Node Protection", draft-wijnands-
	mpls-mldp-node-protection-04 (work in progress), June		mpls-mldp-node-protection-04 (work in progress), June
	2013.		2013.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
			[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
			and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
			Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
			<http://www.rfc-editor.org/info/rfc3209>.
	Authors' Addresses		Authors' Addresses
	Alia Atlas		Alia Atlas
	Juniper Networks		Juniper Networks
	10 Technology Park Drive		10 Technology Park Drive
	Westford, MA 01886		Westford, MA 01886
	USA		USA
	Email: akatlas@juniper.net		Email: akatlas@juniper.net
End of changes. 28 change blocks.
	100 lines changed or deleted		100 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/