draft-ietf-rtgwg-mrt-frr-architecture-05.txt		draft-ietf-rtgwg-mrt-frr-architecture-06.txt
	Routing Area Working Group A. Atlas, Ed.		Routing Area Working Group A. Atlas, Ed.
	Internet-Draft R. Kebler		Internet-Draft R. Kebler
	Intended status: Standards Track C. Bowers		Intended status: Standards Track C. Bowers
	Expires: July 23, 2015 Juniper Networks		Expires: January 4, 2016 Juniper Networks
	G. Enyedi		G. Enyedi
	A. Csaszar		A. Csaszar
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	R. White		R. White
	VCE		VCE
	January 19, 2015		July 3, 2015
	An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees		An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees
	draft-ietf-rtgwg-mrt-frr-architecture-05		draft-ietf-rtgwg-mrt-frr-architecture-06
	Abstract		Abstract
	With increasing deployment of Loop-Free Alternates (LFA) [RFC5286],		With increasing deployment of Loop-Free Alternates (LFA) [RFC5286],
	it is clear that a complete solution for IP and LDP Fast-Reroute is		it is clear that a complete solution for IP and LDP Fast-Reroute is
	required. This specification provides that solution. IP/LDP Fast-		required. This specification provides that solution. IP/LDP Fast-
	Reroute with Maximally Redundant Trees (MRT-FRR) is a technology that		Reroute with Maximally Redundant Trees (MRT-FRR) is a technology that
	gives link-protection and node-protection with 100% coverage in any		gives link-protection and node-protection with 100% coverage in any
	network topology that is still connected after the failure.		network topology that is still connected after the failure.
	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 July 23, 2015.		This Internet-Draft will expire on January 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 2, line 26		skipping to change at page 2, line 26
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Importance of 100% Coverage . . . . . . . . . . . . . . . 5		1.1. Importance of 100% Coverage . . . . . . . . . . . . . . . 5
	1.2. Partial Deployment and Backwards Compatibility . . . . . 6		1.2. Partial Deployment and Backwards Compatibility . . . . . 6
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . . 8		4. Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . . 8
	5. Maximally Redundant Trees (MRT) and Fast-Reroute . . . . . . 10		5. Maximally Redundant Trees (MRT) and Fast-Reroute . . . . . . 10
	6. Unicast Forwarding with MRT Fast-Reroute . . . . . . . . . . 11		6. Unicast Forwarding with MRT Fast-Reroute . . . . . . . . . . 11
	6.1. MRT Forwarding Mechanisms . . . . . . . . . . . . . . . . 11		6.1. MRT Forwarding Mechanisms . . . . . . . . . . . . . . . . 12
	6.1.1. MRT LDP labels . . . . . . . . . . . . . . . . . . . 11		6.1.1. MRT LDP labels . . . . . . . . . . . . . . . . . . . 12
	6.1.1.1. Topology-scoped FEC encoded using a single label		6.1.1.1. Topology-scoped FEC encoded using a single label
	(Option 1A) . . . . . . . . . . . . . . . . . . . 12		(Option 1A) . . . . . . . . . . . . . . . . . . . 12
	6.1.1.2. Topology and FEC encoded using a two label stack		6.1.1.2. Topology and FEC encoded using a two label stack
	(Option 1B) . . . . . . . . . . . . . . . . . . . 12		(Option 1B) . . . . . . . . . . . . . . . . . . . 13
	6.1.1.3. Compatibility of Option 1A and 1B . . . . . . . . 13		6.1.1.3. Compatibility of Option 1A and 1B . . . . . . . . 13
	6.1.1.4. Mandatory support for MRT LDP Label option 1A . . 13		6.1.1.4. Mandatory support for MRT LDP Label option 1A . . 14
	6.1.2. MRT IP tunnels (Options 2A and 2B) . . . . . . . . . 13		6.1.2. MRT IP tunnels (Options 2A and 2B) . . . . . . . . . 14
	6.2. Forwarding LDP Unicast Traffic over MRT Paths . . . . . . 14		6.2. Forwarding LDP Unicast Traffic over MRT Paths . . . . . . 14
	6.2.1. Forwarding LDP traffic using MRT LDP Labels (Option		6.2.1. Forwarding LDP traffic using MRT LDP Labels (Option
	1A) . . . . . . . . . . . . . . . . . . . . . . . . . 14		1A) . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.2.2. Forwarding LDP traffic using MRT LDP Labels (Option		6.2.2. Forwarding LDP traffic using MRT LDP Labels (Option
	1B) . . . . . . . . . . . . . . . . . . . . . . . . . 15		1B) . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.2.3. Other considerations for forwarding LDP traffic using		6.2.3. Other considerations for forwarding LDP traffic using
	MRT LDP Labels . . . . . . . . . . . . . . . . . . . 15		MRT LDP Labels . . . . . . . . . . . . . . . . . . . 15
	6.3. Forwarding IP Unicast Traffic over MRT Paths . . . . . . 15		6.3. Forwarding IP Unicast Traffic over MRT Paths . . . . . . 16
	6.3.1. Tunneling IP traffic using MRT LDP Labels . . . . . . 16		6.3.1. Tunneling IP traffic using MRT LDP Labels . . . . . . 16
	6.3.1.1. Tunneling IP traffic using MRT LDP Labels (Option		6.3.1.1. Tunneling IP traffic using MRT LDP Labels (Option
	1A) . . . . . . . . . . . . . . . . . . . . . . . 16		1A) . . . . . . . . . . . . . . . . . . . . . . . 16
	6.3.1.2. Tunneling IP traffic using MRT LDP Labels (Option		6.3.1.2. Tunneling IP traffic using MRT LDP Labels (Option
	1B) . . . . . . . . . . . . . . . . . . . . . . . 16		1B) . . . . . . . . . . . . . . . . . . . . . . . 17
	6.3.2. Tunneling IP traffic using MRT IP Tunnels . . . . . . 17		6.3.2. Tunneling IP traffic using MRT IP Tunnels . . . . . . 17
	6.3.3. Required support . . . . . . . . . . . . . . . . . . 17		6.3.3. Required support . . . . . . . . . . . . . . . . . . 17
	7. MRT Island Formation . . . . . . . . . . . . . . . . . . . . 17		7. MRT Island Formation . . . . . . . . . . . . . . . . . . . . 17
	7.1. IGP Area or Level . . . . . . . . . . . . . . . . . . . . 17		7.1. IGP Area or Level . . . . . . . . . . . . . . . . . . . . 18
	7.2. Support for a specific MRT profile . . . . . . . . . . . 18		7.2. Support for a specific MRT profile . . . . . . . . . . . 18
	7.3. Excluding additional routers and interfaces from the MRT		7.3. Excluding additional routers and interfaces from the MRT
	Island . . . . . . . . . . . . . . . . . . . . . . . . . 18		Island . . . . . . . . . . . . . . . . . . . . . . . . . 18
	7.3.1. Existing IGP exclusion mechanisms . . . . . . . . . . 18		7.3.1. Existing IGP exclusion mechanisms . . . . . . . . . . 18
	7.3.2. MRT-specific exclusion mechanism . . . . . . . . . . 19		7.3.2. MRT-specific exclusion mechanism . . . . . . . . . . 19
	7.4. Connectivity . . . . . . . . . . . . . . . . . . . . . . 19		7.4. Connectivity . . . . . . . . . . . . . . . . . . . . . . 19
	7.5. Example algorithm . . . . . . . . . . . . . . . . . . . . 19		7.5. Example algorithm . . . . . . . . . . . . . . . . . . . . 19
	8. MRT Profile . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. MRT Profile . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. MRT Profile Options . . . . . . . . . . . . . . . . . . . 19		8.1. MRT Profile Options . . . . . . . . . . . . . . . . . . . 20
	8.2. Router-specific MRT paramaters . . . . . . . . . . . . . 20		8.2. Router-specific MRT paramaters . . . . . . . . . . . . . 21
	8.3. Default MRT profile . . . . . . . . . . . . . . . . . . . 21		8.3. Default MRT profile . . . . . . . . . . . . . . . . . . . 21
	9. LDP signaling extensions and considerations . . . . . . . . . 22		9. LDP signaling extensions and considerations . . . . . . . . . 22
	10. Inter-area Forwarding Behavior . . . . . . . . . . . . . . . 22		10. Inter-area Forwarding Behavior . . . . . . . . . . . . . . . 23
	10.1. ABR Forwarding Behavior with MRT LDP Label Option 1A . . 23		10.1. ABR Forwarding Behavior with MRT LDP Label Option 1A . . 23
	10.1.1. Motivation for Creating the Rainbow-FEC . . . . . . 23		10.1.1. Motivation for Creating the Rainbow-FEC . . . . . . 24
	10.2. ABR Forwarding Behavior with IP Tunneling (option 2) . . 24		10.2. ABR Forwarding Behavior with IP Tunneling (option 2) . . 24
	10.3. ABR Forwarding Behavior with LDP Label option 1B . . . . 24		10.3. ABR Forwarding Behavior with LDP Label option 1B . . . . 25
	11. Prefixes Multiply Attached to the MRT Island . . . . . . . . 26		11. Prefixes Multiply Attached to the MRT Island . . . . . . . . 26
	11.1. Protecting Multi-Homed Prefixes using Tunnel Endpoint		11.1. Protecting Multi-Homed Prefixes using Tunnel Endpoint
	Selection . . . . . . . . . . . . . . . . . . . . . . . 28		Selection . . . . . . . . . . . . . . . . . . . . . . . 28
	11.2. Protecting Multi-Homed Prefixes using Named Proxy-Nodes 29		11.2. Protecting Multi-Homed Prefixes using Named Proxy-Nodes 29
	11.2.1. Computing if an Island Neighbor (IN) is loop-free . 31		11.2.1. Computing if an Island Neighbor (IN) is loop-free . 31
	11.3. MRT Alternates for Destinations Outside the MRT Island . 32		11.3. MRT Alternates for Destinations Outside the MRT Island . 32
	12. Network Convergence and Preparing for the Next Failure . . . 33		12. Network Convergence and Preparing for the Next Failure . . . 33
	12.1. Micro-forwarding loop prevention and MRTs . . . . . . . 33		12.1. Micro-forwarding loop prevention and MRTs . . . . . . . 33
	12.2. MRT Recalculation . . . . . . . . . . . . . . . . . . . 33		12.2. MRT Recalculation . . . . . . . . . . . . . . . . . . . 33
	13. Implementation Status . . . . . . . . . . . . . . . . . . . . 34		13. Implementation Status . . . . . . . . . . . . . . . . . . . . 34
	skipping to change at page 4, line 4		skipping to change at page 4, line 4
	1. Introduction		1. Introduction
	This document gives a complete solution for IP/LDP fast-reroute		This document gives a complete solution for IP/LDP fast-reroute
	[RFC5714]. MRT-FRR creates two alternate trees separate from the		[RFC5714]. MRT-FRR creates two alternate trees separate from the
	primary next-hop forwarding used during stable operation. These two		primary next-hop forwarding used during stable operation. These two
	trees are maximally diverse from each other, providing link and node		trees are maximally diverse from each other, providing link and node
	protection for 100% of paths and failures as long as the failure does		protection for 100% of paths and failures as long as the failure does
	not cut the network into multiple pieces. This document defines the		not cut the network into multiple pieces. This document defines the
	architecture for IP/LDP fast-reroute with MRT. The associated		architecture for IP/LDP fast-reroute with MRT. The associated
	protocol extensions are defined in [I-D.atlas-ospf-mrt] and		protocol extensions are defined in [I-D.ietf-ospf-mrt] and
	[I-D.atlas-mpls-ldp-mrt]. The exact MRT algorithm is defined in		[I-D.ietf-mpls-ldp-mrt]. The exact MRT algorithm is defined in
	[I-D.ietf-rtgwg-mrt-frr-algorithm].		[I-D.ietf-rtgwg-mrt-frr-algorithm].
	IP/LDP Fast-Reroute with MRT (MRT-FRR) uses two maximally diverse		IP/LDP Fast-Reroute with MRT (MRT-FRR) uses two maximally diverse
	forwarding topologies to provide alternates. A primary next-hop		forwarding topologies to provide alternates. A primary next-hop
	should be on only one of the diverse forwarding topologies; thus, the		should be on only one of the diverse forwarding topologies; thus, the
	other can be used to provide an alternate. Once traffic has been		other can be used to provide an alternate. Once traffic has been
	moved to one of MRTs, it is not subject to further repair actions.		moved to one of MRTs, it is not subject to further repair actions.
	Thus, the traffic will not loop even if a worse failure (e.g. node)		Thus, the traffic will not loop even if a worse failure (e.g. node)
	occurs when protection was only available for a simpler failure (e.g.		occurs when protection was only available for a simpler failure (e.g.
	link).		link).
	skipping to change at page 4, line 42		skipping to change at page 4, line 42
	| | Link/Node | | |		| | Link/Node | | |
	| | | | |		| | | | |
	| LFA | Partial | Possible | per neighbor |		| LFA | Partial | Possible | per neighbor |
	| | Link/Node | | |		| | Link/Node | | |
	| | | | |		| | | | |
	| Remote | Partial | Possible | per neighbor (link) or |		| Remote | Partial | Possible | per neighbor (link) or |
	| LFA | Link/Node | | neighbor's neighbor (node) |		| LFA | Link/Node | | neighbor's neighbor (node) |
	| | | | |		| | | | |
	| Not-Via | 100% | None | per link and node |		| Not-Via | 100% | None | per link and node |
	| | Link/Node | | |		| | Link/Node | | |
			| | | | |
			| TI-LFA | 100% | Possible | per neighbor (link) or |
			| | Link/Node | | neighbor's neighbor (node) |
	+---------+-------------+-------------+-----------------------------+		+---------+-------------+-------------+-----------------------------+
	Table 1		Table 1
	Loop-Free Alternates (LFA): LFAs [RFC5286] provide limited		Loop-Free Alternates (LFA): LFAs [RFC5286] provide limited
	topology-dependent coverage for link and node protection.		topology-dependent coverage for link and node protection.
	Restrictions on choice of alternates can be relaxed to improve		Restrictions on choice of alternates can be relaxed to improve
	coverage, but this can cause forwarding loops if a worse failure		coverage, but this can cause forwarding loops if a worse failure
	is experienced than protected against. Augmenting a network to		is experienced than protected against. Augmenting a network to
	provide better coverage is NP-hard [LFARevisited]. [RFC6571]		provide better coverage is NP-hard [LFARevisited]. [RFC6571]
	discusses the applicability of LFA to different topologies with a		discusses the applicability of LFA to different topologies with a
	focus on common PoP architectures.		focus on common PoP architectures.
	Remote LFA: Remote LFAs [I-D.ietf-rtgwg-remote-lfa] improve		Remote LFA: Remote LFAs [RFC7490] improve coverage over LFAs for
	coverage over LFAs for link protection but still cannot guarantee		link protection but still cannot guarantee complete coverage. The
	complete coverage. The trade-off of looping traffic to improve		trade-off of looping traffic to improve coverage is still made.
	coverage is still made. Remote LFAs can provide node-protection		Remote LFAs can provide node-protection
	[I-D.psarkar-rtgwg-rlfa-node-protection] but not guaranteed		[I-D.ietf-rtgwg-rlfa-node-protection] but not guaranteed coverage
	coverage and the computation required is quite high (an SPF for		and the computation required is quite high (an SPF for each PQ-
	each PQ-node evaluated). [I-D.bryant-ipfrr-tunnels] describes		node evaluated). [I-D.bryant-ipfrr-tunnels] describes additional
	additional mechanisms to further improve coverage, at the cost of		mechanisms to further improve coverage, at the cost of added
	added complexity.		complexity.
	Not-Via: Not-Via [I-D.ietf-rtgwg-ipfrr-notvia-addresses] is the		Not-Via: Not-Via [I-D.ietf-rtgwg-ipfrr-notvia-addresses] is the
	only other solution that provides 100% coverage for link and node		only other solution that provides 100% coverage for link and node
	failures and does not have potential looping. However, the		failures and does not have potential looping. However, the
	computation is very high (an SPF per failure point) and academic		computation is very high (an SPF per failure point) and academic
	implementations [LightweightNotVia] have found the address		implementations [LightweightNotVia] have found the address
	management complexity to be high.		management complexity to be high.
			TI-LFA: Topology Independent Loop-free Alternate Fast Re-route (TI-
			LFA) [I-D.francois-spring-segment-routing-ti-lfa] aims to provide
			link and node protection of node and adjacency segments within the
			Segment Routing (SR) framework. It guarantees complete coverage.
			The TI-LFA computation for link-protection is fairly
			straightforward, while the computation for node-protection is more
			complex. For link-protection with symmetric link costs, TI-LFA
			can provide complete coverage by pushing up to two additional
			labels. For node protection on arbitrary topologies, the label
			stack size can grow significantly based on repair path. Note that
			TI-LFA requires shortest path forwarding based on SR Node-SIDs, as
			opposed to LDP labels, in order to construct label stacks for
			backups paths without relying on a large number of targeted LDP
			sessions to learn remote FEC-label bindings. It also requires the
			use of Adj-SIDs to achieve 100% coverage.
	1.1. Importance of 100% Coverage		1.1. Importance of 100% Coverage
	Fast-reroute is based upon the single failure assumption - that the		Fast-reroute is based upon the single failure assumption - that the
	time between single failures is long enough for a network to		time between single failures is long enough for a network to
	reconverge and start forwarding on the new shortest paths. That does		reconverge and start forwarding on the new shortest paths. That does
	not imply that the network will only experience one failure or		not imply that the network will only experience one failure or
	change.		change.
	It is straightforward to analyze a particular network topology for		It is straightforward to analyze a particular network topology for
	coverage. However, a real network does not always have the same		coverage. However, a real network does not always have the same
	skipping to change at page 10, line 19		skipping to change at page 10, line 43
	this looks like a reverse SPT (rSPT). To use maximally redundant		this looks like a reverse SPT (rSPT). To use maximally redundant
	trees, in addition, each destination D has two MRTs associated with		trees, in addition, each destination D has two MRTs associated with
	it; by convention these will be called the MRT-Blue and MRT-Red.		it; by convention these will be called the MRT-Blue and MRT-Red.
	MRT-FRR is realized by using multi-topology forwarding. There is a		MRT-FRR is realized by using multi-topology forwarding. There is a
	MRT-Blue forwarding topology and a MRT-Red forwarding topology.		MRT-Blue forwarding topology and a MRT-Red forwarding topology.
	Any IP/LDP fast-reroute technique beyond LFA requires an additional		Any IP/LDP fast-reroute technique beyond LFA requires an additional
	dataplane procedure, such as an additional forwarding mechanism. The		dataplane procedure, such as an additional forwarding mechanism. The
	well-known options are multi-topology forwarding (used by MRT-FRR),		well-known options are multi-topology forwarding (used by MRT-FRR),
	tunneling (e.g. [I-D.ietf-rtgwg-ipfrr-notvia-addresses] or		tunneling (e.g. [I-D.ietf-rtgwg-ipfrr-notvia-addresses] or
	[I-D.ietf-rtgwg-remote-lfa]), and per-interface forwarding (e.g.		[RFC7490]), and per-interface forwarding (e.g. Loop-Free Failure
	Loop-Free Failure Insensitive Routing in [EnyediThesis]).		Insensitive Routing in [EnyediThesis]).
	When there is a link or node failure affecting, but not partitioning,		When there is a link or node failure affecting, but not partitioning,
	the network, each node will still have at least one path via one of		the network, each node will still have at least one path via one of
	the MRTs to reach the destination D. For example, in Figure 2, C		the MRTs to reach the destination D. For example, in Figure 2, C
	would normally forward traffic to R across the C<->R link. If that		would normally forward traffic to R across the C<->R link. If that
	C<->R link fails, then C could use the Blue MRT path C->D->E->R.		C<->R link fails, then C could use the Blue MRT path C->D->E->R.
	As is always the case with fast-reroute technologies, forwarding does		As is always the case with fast-reroute technologies, forwarding does
	not change until a local failure is detected. Packets are forwarded		not change until a local failure is detected. Packets are forwarded
	along the shortest path. The appropriate alternate to use is pre-		along the shortest path. The appropriate alternate to use is pre-
	skipping to change at page 12, line 41		skipping to change at page 13, line 13
	LDP labels.		LDP labels.
	This approach is very simple for hardware to support. However, it		This approach is very simple for hardware to support. However, it
	reduces the label space for other uses, and it increases the memory		reduces the label space for other uses, and it increases the memory
	needed to store the labels and the communication required by LDP to		needed to store the labels and the communication required by LDP to
	distribute FEC-label bindings.		distribute FEC-label bindings.
	This forwarding option uses the LDP signaling extensions described in		This forwarding option uses the LDP signaling extensions described in
	[I-D.ietf-mpls-ldp-multi-topology]. The MRT-specific LDP extensions		[I-D.ietf-mpls-ldp-multi-topology]. The MRT-specific LDP extensions
	required to support this option are described in		required to support this option are described in
	[I-D.atlas-mpls-ldp-mrt].		[I-D.ietf-mpls-ldp-mrt].
	6.1.1.2. Topology and FEC encoded using a two label stack (Option 1B)		6.1.1.2. Topology and FEC encoded using a two label stack (Option 1B)
	With this forwarding mechanism, a two label stack is used to encode		With this forwarding mechanism, a two label stack is used to encode
	the topology and the FEC of the packet. The top label (topology-id		the topology and the FEC of the packet. The top label (topology-id
	label) identifies the MRT forwarding topology, while the second label		label) identifies the MRT forwarding topology, while the second label
	(FEC label) identifies the FEC. The top label would be a new FEC		(FEC label) identifies the FEC. The top label would be a new FEC
	type with two values corresponding to MRT Red and Blue topologies.		type with two values corresponding to MRT Red and Blue topologies.
	When an MRT transit router receives a packet with a topology-id		When an MRT transit router receives a packet with a topology-id
	skipping to change at page 17, line 33		skipping to change at page 17, line 52
	created for transit traffic. The MRT architecture allows for		created for transit traffic. The MRT architecture allows for
	different, potentially incompatible options. In order to create		different, potentially incompatible options. In order to create
	constistent MRT forwarding topologies, the routers participating in a		constistent MRT forwarding topologies, the routers participating in a
	particular MRT Island need to use the same set of options. These		particular MRT Island need to use the same set of options. These
	options are grouped into MRT profiles. In addition, the routers in		options are grouped into MRT profiles. In addition, the routers in
	an MRT Island all need to use the same set of nodes and links within		an MRT Island all need to use the same set of nodes and links within
	the Island when computing the MRT forwarding topologies. This		the Island when computing the MRT forwarding topologies. This
	section describes the information used by a router to determine the		section describes the information used by a router to determine the
	nodes and links to include in a particular MRT Island. Some of this		nodes and links to include in a particular MRT Island. Some of this
	information is shared among routers using the newly-defined IGP		information is shared among routers using the newly-defined IGP
	signaling extensions for MRT described in [I-D.atlas-ospf-mrt] and		signaling extensions for MRT described in [I-D.ietf-ospf-mrt] and
	[I-D.li-isis-mrt]. Other information already exists in the IGPs and
	can be used by MRT in Island formation, subject to the interpretation		[I-D.ietf-isis-mrt]. Other information already exists in the IGPs
	defined here.		and can be used by MRT in Island formation, subject to the
			interpretation defined here.
	Deployment scenarios using multi-topology OSPF or IS-IS, or running		Deployment scenarios using multi-topology OSPF or IS-IS, or running
	both ISIS and OSPF on the same routers is out of scope for this		both ISIS and OSPF on the same routers is out of scope for this
	specification. As with LFA, it is expected that OSPF Virtual Links		specification. As with LFA, it is expected that OSPF Virtual Links
	will not be supported.		will not be supported.
	7.1. IGP Area or Level		7.1. IGP Area or Level
	All links in an MRT Island MUST be bidirectional and belong to the		All links in an MRT Island MUST be bidirectional and belong to the
	same IGP area or level. For ISIS, a link belonging to both level 1		same IGP area or level. For ISIS, a link belonging to both level 1
	and level 2 would qualify to be in multiple MRT Islands. A given ABR		and level 2 would qualify to be in multiple MRT Islands. A given ABR
	or LBR can belong to multiple MRT Islands, corresponding to the areas		or LBR can belong to multiple MRT Islands, corresponding to the areas
	or levels in which it participates. Inter-area forwarding behavior		or levels in which it participates. Inter-area forwarding behavior
	is discussed in Section 10.		is discussed in Section 10.
	7.2. Support for a specific MRT profile		7.2. Support for a specific MRT profile
	All routers in an MRT Island MUST support the same MRT profile. A		All routers in an MRT Island MUST support the same MRT profile. A
	router advertises support for a given MRT profile using the IGP		router advertises support for a given MRT profile using the IGP
	extensions defined in [I-D.atlas-ospf-mrt] and [I-D.li-isis-mrt]		extensions defined in [I-D.ietf-ospf-mrt] and [I-D.ietf-isis-mrt]
	using an 8-bit Profile ID value. A given router can support multiple		using an 8-bit Profile ID value. A given router can support multiple
	MRT profiles and participate in multiple MRT Islands. The options		MRT profiles and participate in multiple MRT Islands. The options
	that make up an MRT profile, as well as the default MRT profile, are		that make up an MRT profile, as well as the default MRT profile, are
	defined in Section 8.		defined in Section 8.
	7.3. Excluding additional routers and interfaces from the MRT Island		7.3. Excluding additional routers and interfaces from the MRT Island
	MRT takes into account existing IGP mechanisms for discouraging		MRT takes into account existing IGP mechanisms for discouraging
	traffic from using particular links and routers, and it introduces an		traffic from using particular links and routers, and it introduces an
	MRT-specific exclusion mechanism for links.		MRT-specific exclusion mechanism for links.
	skipping to change at page 19, line 8		skipping to change at page 19, line 23
	ISIS) or 0xFFFF for OSPF.		ISIS) or 0xFFFF for OSPF.
	2. A router MUST be excluded from an MRT Island if it is advertised		2. A router MUST be excluded from an MRT Island if it is advertised
	with the overload bit set (for ISIS), or it is advertised with		with the overload bit set (for ISIS), or it is advertised with
	metric values of 0xFFFF on all of its outgoing interfaces (for		metric values of 0xFFFF on all of its outgoing interfaces (for
	OSPF).		OSPF).
	7.3.2. MRT-specific exclusion mechanism		7.3.2. MRT-specific exclusion mechanism
	This architecture also defines a means of excluding an otherwise		This architecture also defines a means of excluding an otherwise
	usable link from MRT Islands. [I-D.atlas-ospf-mrt] and		usable link from MRT Islands. [I-D.ietf-ospf-mrt] and
	[I-D.li-isis-mrt] define the IGP extensions for OSPF and ISIS used to		[I-D.ietf-isis-mrt] define the IGP extensions for OSPF and ISIS used
	advertise that a link is MRT-Ineligible. A link with either		to advertise that a link is MRT-Ineligible. A link with either
	interface advertised as MRT-Ineligible MUST be excluded from an MRT		interface advertised as MRT-Ineligible MUST be excluded from an MRT
	Island. Note that an interface advertised as MRT-Ineligigle by a		Island. Note that an interface advertised as MRT-Ineligigle by a
	router is ineligible with respect to all profiles advertised by that		router is ineligible with respect to all profiles advertised by that
	router.		router.
	7.4. Connectivity		7.4. Connectivity
	All of the routers in an MRT Island MUST be connected by		All of the routers in an MRT Island MUST be connected by
	bidirectional links with other routers in the MRT Island.		bidirectional links with other routers in the MRT Island.
	Disconnected MRT Islands will operate independently of one another.		Disconnected MRT Islands will operate independently of one another.
	skipping to change at page 21, line 23		skipping to change at page 21, line 43
	MRT-Red Loopback Address: This provides the router's loopback		MRT-Red Loopback Address: This provides the router's loopback
	address to reach the router via the MRT-Red forwarding topology.		address to reach the router via the MRT-Red forwarding topology.
	It can be specified for either IPv4 and IPv6.		It can be specified for either IPv4 and IPv6.
	MRT-Blue Loopback Address: This provides the router's loopback		MRT-Blue Loopback Address: This provides the router's loopback
	address to reach the router via the MRT-Blue forwarding topology.		address to reach the router via the MRT-Blue forwarding topology.
	It can be specified for either IPv4 and IPv6.		It can be specified for either IPv4 and IPv6.
	The extensions to OSPF and ISIS for advertising a router's GADAG Root		The extensions to OSPF and ISIS for advertising a router's GADAG Root
	Selection Priority value are defined in [I-D.atlas-ospf-mrt] and		Selection Priority value are defined in [I-D.ietf-ospf-mrt] and
	[I-D.li-isis-mrt]. IGP extensions for the advertising a router's		[I-D.ietf-isis-mrt]. IGP extensions for the advertising a router's
	MRT-Red and MRT-Blue Loopback Addresses have not been defined.		MRT-Red and MRT-Blue Loopback Addresses have not been defined.
	8.3. Default MRT profile		8.3. Default MRT profile
	The following set of options defines the default MRT Profile. The		The following set of options defines the default MRT Profile. The
	default MRT profile is indicated by the MRT Profile ID value of 0.		default MRT profile is indicated by the MRT Profile ID value of 0.
	MRT Algorithm: MRT Lowpoint algorithm defined in		MRT Algorithm: MRT Lowpoint algorithm defined in
	[I-D.ietf-rtgwg-mrt-frr-algorithm].		[I-D.ietf-rtgwg-mrt-frr-algorithm].
	skipping to change at page 22, line 12		skipping to change at page 22, line 33
	Section 12.2. This allows the MRT forwarding topologies to		Section 12.2. This allows the MRT forwarding topologies to
	support IP/LDP fast-reroute traffic.		support IP/LDP fast-reroute traffic.
	Area/Level Border Behavior: As described in Section 10, ABRs/LBRs		Area/Level Border Behavior: As described in Section 10, ABRs/LBRs
	SHOULD ensure that traffic leaving the area also exits the MRT-Red		SHOULD ensure that traffic leaving the area also exits the MRT-Red
	or MRT-Blue forwarding topology.		or MRT-Blue forwarding topology.
	9. LDP signaling extensions and considerations		9. LDP signaling extensions and considerations
	The protocol extensions for LDP are defined in		The protocol extensions for LDP are defined in
	[I-D.atlas-mpls-ldp-mrt]. A router must indicate that it has the		[I-D.ietf-mpls-ldp-mrt]. A router must indicate that it has the
	ability to support MRT; having this explicit allows the use of MRT-		ability to support MRT; having this explicit allows the use of MRT-
	specific processing, such as special handling of FECs sent with the		specific processing, such as special handling of FECs sent with the
	Rainbow MRT MT-ID.		Rainbow MRT MT-ID.
	A FEC sent with the Rainbow MRT MT-ID indicates that the FEC applies		A FEC sent with the Rainbow MRT MT-ID indicates that the FEC applies
	to all the MRT-Blue and MRT-Red MT-IDs in supported MRT profiles.		to all the MRT-Blue and MRT-Red MT-IDs in supported MRT profiles.
	The FEC-label bindings for the default shortest-path based MT-ID 0		The FEC-label bindings for the default shortest-path based MT-ID 0
	MUST still be sent (even though it could be inferred from the Rainbow		MUST still be sent (even though it could be inferred from the Rainbow
	FEC-label bindings) to ensure continuous operation of normal LDP		FEC-label bindings) to ensure continuous operation of normal LDP
	forwarding. The Rainbow MRT MT-ID is defined to provide an easy way		forwarding. The Rainbow MRT MT-ID is defined to provide an easy way
	to handle the special signaling that is needed at ABRs or LBRs. It		to handle the special signaling that is needed at ABRs or LBRs. It
	avoids the problem of needing to signal different MPLS labels for the		avoids the problem of needing to signal different MPLS labels for the
	same FEC. Because the Rainbow MRT MT-ID is used only by ABRs/LBRs or		same FEC. Because the Rainbow MRT MT-ID is used only by ABRs/LBRs or
	an LDP egress router, it is not MRT profile specific.		an LDP egress router, it is not MRT profile specific.
	[I-D.atlas-mpls-ldp-mrt] contains the IANA request for the Rainbow		[I-D.ietf-mpls-ldp-mrt] contains the IANA request for the Rainbow MRT
	MRT MT-ID.		MT-ID.
	10. Inter-area Forwarding Behavior		10. Inter-area Forwarding Behavior
	Unless otherwise specified, in this section we will use the terms		Unless otherwise specified, in this section we will use the terms
	area and ABR to indicate either an OSPF area and OSPF ABR or ISIS		area and ABR to indicate either an OSPF area and OSPF ABR or ISIS
	level and ISIS LBR.		level and ISIS LBR.
	An ABR/LBR has two forwarding roles. First, it forwards traffic		An ABR/LBR has two forwarding roles. First, it forwards traffic
	within areas. Second, it forwards traffic from one area into		within areas. Second, it forwards traffic from one area into
	another. These same two roles apply for MRT transit traffic.		another. These same two roles apply for MRT transit traffic.
	skipping to change at page 25, line 18		skipping to change at page 25, line 40
	In all cases for ISIS and most cases for OSPF, the penultimate router		In all cases for ISIS and most cases for OSPF, the penultimate router
	can determine what decision the adjacent ABR will make. The one case		can determine what decision the adjacent ABR will make. The one case
	where it can't be determined is when two ASBRs are in different non-		where it can't be determined is when two ASBRs are in different non-
	backbone areas attached to the same ABR, then the ASBR's Area ID may		backbone areas attached to the same ABR, then the ASBR's Area ID may
	be needed for tie-breaking (prefer the route with the largest OPSF		be needed for tie-breaking (prefer the route with the largest OPSF
	area ID) and the Area ID isn't announced as part of the ASBR link-		area ID) and the Area ID isn't announced as part of the ASBR link-
	state advertisement (LSA). In this one case, suboptimal forwarding		state advertisement (LSA). In this one case, suboptimal forwarding
	along the MRT in the other area would happen. If that becomes a		along the MRT in the other area would happen. If that becomes a
	realistic deployment scenario, OSPF extensions could be considered.		realistic deployment scenario, OSPF extensions could be considered.
	This is not covered in [I-D.atlas-ospf-mrt].		This is not covered in [I-D.ietf-ospf-mrt].
	+----[C]---- --[D]--[E] --[D]--[E]		+----[C]---- --[D]--[E] --[D]--[E]
	| \ / \ / \		| \ / \ / \
	p--[A] Area 10 [ABR1] Area 0 [H]--p +-[ABR1] Area 0 [H]-+		p--[A] Area 10 [ABR1] Area 0 [H]--p +-[ABR1] Area 0 [H]-+
	| / \ / | \ / |		| / \ / | \ / |
	+----[B]---- --[F]--[G] | --[F]--[G] |		+----[B]---- --[F]--[G] | --[F]--[G] |
	| |		| |
	| other |		| other |
	+----------[p]-------+		+----------[p]-------+
	area		area
	skipping to change at page 30, line 10		skipping to change at page 30, line 10
	A named proxy-node represents one or more destinations and, for LDP		A named proxy-node represents one or more destinations and, for LDP
	forwarding, has a FEC associated with it that is signaled into the		forwarding, has a FEC associated with it that is signaled into the
	MRT Island. Therefore, it is possible to explicitly label packets to		MRT Island. Therefore, it is possible to explicitly label packets to
	go to (MRT-Red, FEC) or (MRT-Blue, FEC); at the border of the MRT		go to (MRT-Red, FEC) or (MRT-Blue, FEC); at the border of the MRT
	Island, the label will swap to meaning (MT-ID 0, FEC). It would be		Island, the label will swap to meaning (MT-ID 0, FEC). It would be
	possible to have named proxy-nodes for IP forwarding, but this would		possible to have named proxy-nodes for IP forwarding, but this would
	require extensions to signal two IP addresses to be associated with		require extensions to signal two IP addresses to be associated with
	MRT-Red and MRT-Blue for the proxy-node. A named proxy-node can be		MRT-Red and MRT-Blue for the proxy-node. A named proxy-node can be
	uniquely represented by the two routers in the MRT Island to which it		uniquely represented by the two routers in the MRT Island to which it
	is connected. The extensions to signal such IP addresses are not		is connected. The extensions to signal such IP addresses are not
	defined in [I-D.atlas-ospf-mrt]. The details of what label-bindings		defined in [I-D.ietf-ospf-mrt]. The details of what label-bindings
	must be originated are described in [I-D.atlas-mpls-ldp-mrt].		must be originated are described in [I-D.ietf-mpls-ldp-mrt].
	Computing the MRT next-hops to a named proxy-node and the MRT		Computing the MRT next-hops to a named proxy-node and the MRT
	alternate for the computing router S to avoid a particular failure		alternate for the computing router S to avoid a particular failure
	node F is straightforward. The details of the simple constant-time		node F is straightforward. The details of the simple constant-time
	functions, Select_Proxy_Node_NHs() and		functions, Select_Proxy_Node_NHs() and
	Select_Alternates_Proxy_Node(), are given in		Select_Alternates_Proxy_Node(), are given in
	[I-D.ietf-rtgwg-mrt-frr-algorithm]. A key point is that computing		[I-D.ietf-rtgwg-mrt-frr-algorithm]. A key point is that computing
	these MRT next-hops and alternates can be done as new named proxy-		these MRT next-hops and alternates can be done as new named proxy-
	nodes are added or removed without requiring a new MRT computation or		nodes are added or removed without requiring a new MRT computation or
	impacting other existing MRT paths. This maps very well to, for		impacting other existing MRT paths. This maps very well to, for
	skipping to change at page 36, line 18		skipping to change at page 36, line 18
	o Contact information: lizhenbin@huawei.com, eric.wu@huawei.com		o Contact information: lizhenbin@huawei.com, eric.wu@huawei.com
	14. Acknowledgements		14. Acknowledgements
	The authors would like to thank Mike Shand for his valuable review		The authors would like to thank Mike Shand for his valuable review
	and contributions.		and contributions.
	The authors would like to thank Joel Halpern, Hannes Gredler, Ted		The authors would like to thank Joel Halpern, Hannes Gredler, Ted
	Qian, Kishore Tiruveedhula, Shraddha Hegde, Santosh Esale, Nitin		Qian, Kishore Tiruveedhula, Shraddha Hegde, Santosh Esale, Nitin
	Bahadur, Harish Sitaraman, and Raveendra Torvi for their suggestions		Bahadur, Harish Sitaraman, Raveendra Torvi, Anil Kumar SN, and Bruno
	and review.		Decraene for their suggestions and review.
	15. IANA Considerations		15. IANA Considerations
	Please create an MRT Profile registry for the MRT Profile TLV. The		Please create an MRT Profile registry for the MRT Profile TLV. The
	range is 0 to 255. The default MRT Profile has value 0. Values		range is 0 to 255. The default MRT Profile has value 0. Values
	1-200 are by Standards Action. Values 201-220 are for		1-200 are by Standards Action. Values 201-220 are for
	experimentation. Values 221-255 are for vendor private use.		experimentation. Values 221-255 are for vendor private use.
	Please allocate values from the LDP Multi-Topology (MT) ID Name Space		Please allocate values from the LDP Multi-Topology (MT) ID Name Space
	[I-D.ietf-mpls-ldp-multi-topology] for the following: Default Profile		[I-D.ietf-mpls-ldp-multi-topology] for the following: Default Profile
	skipping to change at page 36, line 44		skipping to change at page 36, line 44
	16. Security Considerations		16. Security Considerations
	This architecture is not currently believed to introduce new security		This architecture is not currently believed to introduce new security
	concerns.		concerns.
	17. References		17. References
	17.1. Normative References		17.1. Normative References
	[I-D.ietf-rtgwg-mrt-frr-algorithm]		[I-D.ietf-rtgwg-mrt-frr-algorithm]
	Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.		Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
	Gopalan, "Algorithms for computing Maximally Redundant		Gopalan, "Algorithms for computing Maximally Redundant
	Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr-		Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
	algorithm-01 (work in progress), July 2014.		algorithm-05 (work in progress), July 2015.
	[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast		[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
	Reroute: Loop-Free Alternates", RFC 5286, September 2008.		Reroute: Loop-Free Alternates", RFC 5286, September 2008.
	[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC		[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
	5714, January 2010.		5714, January 2010.
	17.2. Informative References		17.2. Informative References
	[EnyediThesis]		[EnyediThesis]
	Enyedi, G., "Novel Algorithms for IP Fast Reroute",		Enyedi, G., "Novel Algorithms for IP Fast Reroute",
	Department of Telecommunications and Media Informatics,		Department of Telecommunications and Media Informatics,
	Budapest University of Technology and Economics Ph.D.		Budapest University of Technology and Economics Ph.D.
	Thesis, February 2011,		Thesis, February 2011,
	<http://timon.tmit.bme.hu/theses/thesis_book.pdf>.		<http://timon.tmit.bme.hu/theses/thesis_book.pdf>.
	[I-D.atlas-mpls-ldp-mrt]
	Atlas, A., Tiruveedhula, K., Tantsura, J., and IJ.
	Wijnands, "LDP Extensions to Support Maximally Redundant
	Trees", draft-atlas-mpls-ldp-mrt-01 (work in progress),
	July 2014.
	[I-D.atlas-ospf-mrt]
	Atlas, A., Hegde, S., Bowers, C., and J. Tantsura, "OSPF
	Extensions to Support Maximally Redundant Trees", draft-
	atlas-ospf-mrt-02 (work in progress), July 2014.
	[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.bryant-ipfrr-tunnels]		[I-D.bryant-ipfrr-tunnels]
	Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP		Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
	Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03		Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03
	(work in progress), November 2007.		(work in progress), November 2007.
			[I-D.francois-spring-segment-routing-ti-lfa]
			Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,
			"Topology Independent Fast Reroute using Segment Routing",
			draft-francois-spring-segment-routing-ti-lfa-01 (work in
			progress), October 2014.
			[I-D.ietf-isis-mrt]
			Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J.
			Tantsura, "Intermediate System to Intermediate System (IS-
			IS) Extensions for Maximally Redundant Trees (MRT)",
			draft-ietf-isis-mrt-00 (work in progress), February 2015.
			[I-D.ietf-mpls-ldp-mrt]
			Atlas, A., Tiruveedhula, K., Bowers, C., Tantsura, J., and
			I. Wijnands, "LDP Extensions to Support Maximally
			Redundant Trees", draft-ietf-mpls-ldp-mrt-00 (work in
			progress), January 2015.
	[I-D.ietf-mpls-ldp-multi-topology]		[I-D.ietf-mpls-ldp-multi-topology]
	Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.		Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
	King, "LDP Extensions for Multi Topology", draft-ietf-		King, "LDP Extensions for Multi Topology", draft-ietf-
	mpls-ldp-multi-topology-12 (work in progress), April 2014.		mpls-ldp-multi-topology-12 (work in progress), April 2014.
			[I-D.ietf-ospf-mrt]
			Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
			"OSPF Extensions to Support Maximally Redundant Trees",
			draft-ietf-ospf-mrt-00 (work in progress), January 2015.
	[I-D.ietf-rtgwg-ipfrr-notvia-addresses]		[I-D.ietf-rtgwg-ipfrr-notvia-addresses]
	Bryant, S., Previdi, S., and M. Shand, "A Framework for IP		Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
	and MPLS Fast Reroute Using Not-via Addresses", draft-		and MPLS Fast Reroute Using Not-via Addresses", draft-
	ietf-rtgwg-ipfrr-notvia-addresses-11 (work in progress),		ietf-rtgwg-ipfrr-notvia-addresses-11 (work in progress),
	May 2013.		May 2013.
	[I-D.ietf-rtgwg-ordered-fib]		[I-D.ietf-rtgwg-ordered-fib]
	Shand, M., Bryant, S., Previdi, S., Filsfils, C.,		Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
	Francois, P., and O. Bonaventure, "Framework for Loop-free		Francois, P., and O. Bonaventure, "Framework for Loop-free
	convergence using oFIB", draft-ietf-rtgwg-ordered-fib-12		convergence using oFIB", draft-ietf-rtgwg-ordered-fib-12
	(work in progress), May 2013.		(work in progress), May 2013.
	[I-D.ietf-rtgwg-remote-lfa]		[I-D.ietf-rtgwg-rlfa-node-protection]
	Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.		Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski,
	So, "Remote Loop-Free Alternate Fast Re-Route", draft-		S., and H. Raghuveer, "Remote-LFA Node Protection and
	ietf-rtgwg-remote-lfa-10 (work in progress), January 2015.		Manageability", draft-ietf-rtgwg-rlfa-node-protection-02
			(work in progress), June 2015.
	[I-D.li-isis-mrt]
	Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J.
	Tantsura, "Intermediate System to Intermediate System (IS-
	IS) Extensions for Maximally Redundant Trees(MRT)", draft-
	li-isis-mrt-01 (work in progress), July 2014.
	[I-D.psarkar-rtgwg-rlfa-node-protection]
	psarkar@juniper.net, p., Gredler, H., Hegde, S.,
	Raghuveer, H., Bowers, C., and S. Litkowski, "Remote-LFA
	Node Protection and Manageability", draft-psarkar-rtgwg-
	rlfa-node-protection-04 (work in progress), April 2014.
	[LFARevisited]		[LFARevisited]
	Retvari, G., Tapolcai, J., Enyedi, G., and A. Csaszar, "IP		Retvari, G., Tapolcai, J., Enyedi, G., and A. Csaszar, "IP
	Fast ReRoute: Loop Free Alternates Revisited", Proceedings		Fast ReRoute: Loop Free Alternates Revisited", Proceedings
	of IEEE INFOCOM , 2011,		of IEEE INFOCOM , 2011,
	<http://opti.tmit.bme.hu/~tapolcai/papers/		<http://opti.tmit.bme.hu/~tapolcai/papers/
	retvari2011lfa_infocom.pdf>.		retvari2011lfa_infocom.pdf>.
	[LightweightNotVia]		[LightweightNotVia]
	Enyedi, G., Retvari, G., Szilagyi, P., and A. Csaszar, "IP		Enyedi, G., Retvari, G., Szilagyi, P., and A. Csaszar, "IP
	skipping to change at page 39, line 17		skipping to change at page 39, line 17
	[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,		[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,
	Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free		Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
	Alternate (LFA) Applicability in Service Provider (SP)		Alternate (LFA) Applicability in Service Provider (SP)
	Networks", RFC 6571, June 2012.		Networks", RFC 6571, June 2012.
	[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", RFC 6982, July		Code: The Implementation Status Section", RFC 6982, July
	2013.		2013.
			[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
			So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
			RFC 7490, April 2015.
	Appendix A. General Issues with Area Abstraction		Appendix A. General Issues with Area Abstraction
	When a multi-homed prefix is connected in two different areas, it may		When a multi-homed prefix is connected in two different areas, it may
	be impractical to protect them without adding the complexity of		be impractical to protect them without adding the complexity of
	explicit tunneling. This is also a problem for LFA and Remote-LFA.		explicit tunneling. This is also a problem for LFA and Remote-LFA.
	50		50
	|----[ASBR Y]---[B]---[ABR 2]---[C] Backbone Area 0:		|----[ASBR Y]---[B]---[ABR 2]---[C] Backbone Area 0:
	| | ABR 1, ABR 2, C, D		| | ABR 1, ABR 2, C, D
	| |		| |
End of changes. 38 change blocks.
	81 lines changed or deleted		106 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/