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/