draft-ietf-rtgwg-mrt-frr-architecture-01.txt   draft-ietf-rtgwg-mrt-frr-architecture-02.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 Juniper Networks Intended status: Standards Track Juniper Networks
Expires: September 13, 2012 G. Enyedi Expires: August 28, 2013 G. Enyedi
A. Csaszar A. Csaszar
J. Tantsura
Ericsson Ericsson
M. Konstantynowicz M. Konstantynowicz
R. White
Cisco Systems Cisco Systems
R. White
Verisign
M. Shand M. Shand
March 12, 2012 February 24, 2013
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-01 draft-ietf-rtgwg-mrt-frr-architecture-02
Abstract Abstract
As IP and LDP Fast-Reroute are increasingly deployed, the coverage As IP and LDP Fast-Reroute are increasingly deployed, the coverage
limitations of Loop-Free Alternates are seen as a problem that limitations of Loop-Free Alternates are seen as a problem that
requires a straightforward and consistent solution for IP and LDP, requires a straightforward and consistent solution for IP and LDP,
for unicast and multicast. This draft describes an architecture for unicast and multicast. This draft describes an architecture
based on redundant backup trees where a single failure can cut a based on redundant backup trees where a single failure can cut a
point-of-local-repair from the destination only on one of the pair of point-of-local-repair from the destination only on one of the pair of
redundant trees. redundant trees.
skipping to change at page 2, line 7 skipping to change at page 2, line 10
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 September 13, 2012. This Internet-Draft will expire on August 28, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals for Extending IP Fast-Reroute coverage beyond LFA . 4 1.1. Goals for Extending IP Fast-Reroute coverage beyond LFA . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . . 6 3. Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . . 6
4. Maximally Redundant Trees (MRT) and Fast-Reroute . . . . . . . 8 4. Maximally Redundant Trees (MRT) and Fast-Reroute . . . . . . . 8
5. Unicast Forwarding with MRT Fast-Reroute . . . . . . . . . . . 9 5. Unicast Forwarding with MRT Fast-Reroute . . . . . . . . . . . 9
5.1. LDP Unicast Forwarding - Avoid Tunneling . . . . . . . . . 10 5.1. LDP Unicast Forwarding - Avoid Tunneling . . . . . . . . . 10
5.2. IP Unicast Traffic . . . . . . . . . . . . . . . . . . . . 10 5.2. IP Unicast Traffic . . . . . . . . . . . . . . . . . . . . 10
6. Protocol Extensions and Considerations: OSPF and ISIS . . . . 12 6. Protocol Extensions and Considerations: OSPF and ISIS . . . . 12
7. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . . . . 14 7. Protocol Extensions and considerations: LDP . . . . . . . . . 14
8. Inter-Area and ABR Forwarding Behavior . . . . . . . . . . . . 15 8. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . . . . 15
9. Issues with Area Abstraction . . . . . . . . . . . . . . . . . 18 9. Inter-Area and ABR Forwarding Behavior . . . . . . . . . . . . 16
10. Partial Deployment and Islands of Compatible MRT FRR 10. Issues with Area Abstraction . . . . . . . . . . . . . . . . . 19
routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Partial Deployment and Islands of Compatible MRT FRR
11. Network Convergence and Preparing for the Next Failure . . . . 21 routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Micro-forwarding loop prevention and MRTs . . . . . . . . 21 12. Network Convergence and Preparing for the Next Failure . . . . 22
11.2. MRT Recalculation . . . . . . . . . . . . . . . . . . . . 22 12.1. Micro-forwarding loop prevention and MRTs . . . . . . . . 22
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 12.2. MRT Recalculation . . . . . . . . . . . . . . . . . . . . 23
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24
15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
15.2. Informative References . . . . . . . . . . . . . . . . . . 23 16.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 16.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
There is still work required to completely provide IP and LDP Fast- There is still work required to completely provide IP and LDP Fast-
Reroute[RFC5714] for unicast and multicast traffic. This draft Reroute[RFC5714] for unicast and multicast traffic. This draft
proposes an architecture to provide 100% coverage for unicast proposes an architecture to provide 100% coverage for unicast
traffic. The associated multicast architecture is described in traffic. The associated multicast architecture is described in
[I-D.atlas-rtgwg-mrt-mc-arch]. [I-D.atlas-rtgwg-mrt-mc-arch].
Loop-free alternates (LFAs)[RFC5286] provide a useful mechanism for Loop-free alternates (LFAs)[RFC5286] provide a useful mechanism for
skipping to change at page 8, line 40 skipping to change at page 8, line 40
In normal IGP routing, each router has its shortest-path-tree to all In normal IGP routing, each router has its shortest-path-tree to all
destinations. From the perspective of a particular destination, D, destinations. From the perspective of a particular destination, D,
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 blue and red MRTs. it; by convention these will be called the blue and red MRTs.
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 tunneling (e.g. well-known options are tunneling (e.g.
[I-D.ietf-rtgwg-ipfrr-notvia-addresses]), per-interface forwarding [I-D.ietf-rtgwg-ipfrr-notvia-addresses] or
(e.g. Loop-Free Failure Insensitive Routing in [EnyediThesis]), and [I-D.ietf-rtgwg-remote-lfa]), per-interface forwarding (e.g. Loop-
multi-topology forwarding. MRT is realized by using multi-topology Free Failure Insensitive Routing in [EnyediThesis]), and multi-
topology forwarding. MRT is realized by using multi-topology
forwarding. There is a Blue MRT forwarding topology and a Red MRT forwarding. There is a Blue MRT forwarding topology and a Red MRT
forwarding topology. forwarding topology.
MRTs are practical to maintain redundancy even after a single link or MRTs are practical to maintain redundancy even after a single link or
node failure. If a pair of MRTs is computed rooted at each node failure. If a pair of MRTs is computed rooted at each
destination, all the destinations remain reachable along one of the destination, all the destinations remain reachable along one of the
MRTs in the case of a single link or node failure. MRTs in the case of a single link or node failure.
When there is a link or node failure affecting the rSPT, each node When there is a link or node failure affecting the rSPT, each node
will still have at least one path via one of the MRTs to reach the will still have at least one path via one of the MRTs to reach the
skipping to change at page 9, line 36 skipping to change at page 9, line 36
available so that the micro-loop prevention mechanism, which requires available so that the micro-loop prevention mechanism, which requires
slower network convergence, can take the necessary time without slower network convergence, can take the necessary time without
impacting traffic badly. impacting traffic badly.
As described in [RFC5286], when a worse failure than is anticipated As described in [RFC5286], when a worse failure than is anticipated
happens, using LFAs that are not downstream neighbors can cause happens, using LFAs that are not downstream neighbors can cause
micro-looping. An example is given of link-protecting alternates micro-looping. An example is given of link-protecting alternates
causing a loop on node failure. Even if a worse failure than causing a loop on node failure. Even if a worse failure than
anticipated happened, the use of MRT alternates will not cause anticipated happened, the use of MRT alternates will not cause
looping. Therefore, while node-protecting LFAs may be prefered, an looping. Therefore, while node-protecting LFAs may be prefered, an
advantage to using MRT alternates when such a node-protecting LFA is the certainty that no alternate-induced looping will occur is an
not a downstream path is the certainty that no alternate-induced advantage of using MRT alternates when the available node-protecting
looping will occur. LFA is not a downstream path.
5. Unicast Forwarding with MRT Fast-Reroute 5. Unicast Forwarding with MRT Fast-Reroute
With LFA, there is no need to tunnel unicast traffic, whether IP or With LFA, there is no need to tunnel unicast traffic, whether IP or
LDP. The traffic is simply sent to an alternate. As mentioned LDP. The traffic is simply sent to an alternate. As mentioned
earlier in Section 4, MRT needs multi-topology forwarding. earlier in Section 4, MRT needs multi-topology forwarding.
Unfortunately, neither IP nor LDP provide extra bits for a packet to Unfortunately, neither IP nor LDP provide extra bits for a packet to
indicate its topology. indicate its topology.
Once the MRTs are computed, the two sets of MRTs are seen by the Once the MRTs are computed, the two sets of MRTs are seen by the
skipping to change at page 11, line 20 skipping to change at page 11, line 20
MRT it should be forwarded in. MRT it should be forwarded in.
1. Tunnel IP packets via an LDP LSP. This has the advantage that 1. Tunnel IP packets via an LDP LSP. This has the advantage that
more installed routers can do line-rate encapsulation and more installed routers can do line-rate encapsulation and
decapsulation. Also, no additional IP addresses would need to be decapsulation. Also, no additional IP addresses would need to be
allocated or signaled. allocated or signaled.
A. Option A - LDP Destination-Topology Label: Use a label that A. Option A - LDP Destination-Topology Label: Use a label that
indicates both destination and MRT. This method allows easy indicates both destination and MRT. This method allows easy
tunneling to the next-next-hop as well as to the IGP-area tunneling to the next-next-hop as well as to the IGP-area
destination. For multi-homed prefixes, this requires that destination. For a proxy-node, the destination to use is the
additional labels be advertised for each proxy-node. non-proxy-node immediately before the proxy-node on that
particular color MRT.
B. Option B - LDP Topology Label: Use a Topology-Identifier B. Option B - LDP Topology Label: Use a Topology-Identifier
label on top of the IP packet. This is very simple and label on top of the IP packet. This is very simple. If
doesn't require additional labels for proxy-nodes. If
tunneling to a next-next-hop is desired, then a two-deep tunneling to a next-next-hop is desired, then a two-deep
label stack can be used with [ Topology-ID label, Next-Next- label stack can be used with [ Topology-ID label, Next-Next-
Hop Label ]. Hop Label ].
2. Tunnel IP packets in IP. Each router supporting this option 2. Tunnel IP packets in IP. Each router supporting this option
would announce two additional loopback addresses and their would announce two additional loopback addresses and their
associated MRT color. Those addresses are used as destination associated MRT color. Those addresses are used as destination
addresses for MRT-blue and MRT-red IP tunnels respectively. They addresses for MRT-blue and MRT-red IP tunnels respectively. They
allow the transit nodes to identify the traffic as being allow the transit nodes to identify the traffic as being
forwarded along either MRT-blue or MRT-red tree topology to reach forwarded along either MRT-blue or MRT-red tree topology to reach
skipping to change at page 11, line 47 skipping to change at page 11, line 47
loopback addresses per router with their MRT color requires IGP loopback addresses per router with their MRT color requires IGP
extensions. extensions.
For greatest hardware compatibility and ease in removing the MRT- For greatest hardware compatibility and ease in removing the MRT-
topology marking at area/level boundaries, routers that support MPLS topology marking at area/level boundaries, routers that support MPLS
and implement IP MRT fast-reroute SHOULD support Option A - using an and implement IP MRT fast-reroute SHOULD support Option A - using an
LDP label that indicates the destination and MT-ID. LDP label that indicates the destination and MT-ID.
For proxy-nodes associated with one or more multi-homed prefixes, For proxy-nodes associated with one or more multi-homed prefixes,
there is no router associated with the proxy-node, so its loopbacks there is no router associated with the proxy-node, so its loopbacks
can't be known or used. Instead, the loopback addresses of the two can't be known or used. Instead, the loopback addresses of the
routers that are attached to the proxy-node can be used. One of routers that are attached to the proxy-node can be used. One of
those routers will be on the Red MRT and the other on the Blue MRT. those routers will be on the Red MRT and the other on the Blue MRT.
The MRT-red loopback of the first router would be used to reach the The MRT-red loopback of the first router would be used to reach the
router on the Red MRT and similarly the MRT-blue loopback of the router on the Red MRT and similarly the MRT-blue loopback of the
second router would be used. The routers connected to the proxy-node second router would be used. The routers connected to the proxy-node
are the end of the area/level and can decapsulate the traffic and are the end of the area/level and can decapsulate the traffic and
properly forward it into the next area. properly forward it into the next area.
6. Protocol Extensions and Considerations: OSPF and ISIS 6. Protocol Extensions and Considerations: OSPF and ISIS
This captures an initial understanding of what may need to be There are two possible approaches to what additional information to
specified. In cases of partial deployment, it is necessary for a distribute in the IGP. The first is to allow full flexibility in all
router to determine a consistent set of routers to include in the information and distribute whichever values and combinations are
island of MRT support. To facilitate this, each router can announce desired. The second is to simply distribute flags indicating a
both what its capabilities are and what it requires from other particular well-known profile is supported. Thus the MRT Island
routers to add them to the MRT island. Generally, there will be a Creation process is trivial. The profile approach is recommended,
set of information advertised about the MRT support. This with the added flexibility of being able to specify more specific
information has only area/level-wide scope. information if necessary and supported.
For example, a simple profile "metric-insensitive MRT unicast fast-
reroute via LDP" could specify:
MRT Island Creation: Only include other routers advertising this
profile.
MRT Algorithm ID: The MRT Lowpoint algorithm defined in
[I-D.enyedi-rtgwg-mrt-frr-algorithm].
Red MRT MT-ID: The Red MRT MT-ID is the single well-known value
allocated by IANA from the OSPF, ISIS, LDP and PIM MT-ID spaces.
Blue MRT MT-ID: The Blue MRT MT-ID is the single well-known value
allocated by IANA from the OSPF, ISIS, LDP and PIM MT-ID spaces.
GADAG Root Election Priority: Pick the router with the lowest
router ID to be the GADAG root.
Forwarding Mechanisms for IP: Use IP-in-LDP.
MRT Capabilities: Computes MRTs, IP Fast-Reroute, LDP Fast-Reroute
The following captures an initial understanding of the aspects that
must be considered to fully form a profile to advertise. For some
profiles, associated information may need to be distributed, such as
GADAG Root Election Priority, Red MRT Loopback Address, Blue MRT
Loopback Address, or MRT Algorithm ID.
MRT Island Creation ID: This identifies the process that the router MRT Island Creation ID: This identifies the process that the router
uses to form an MRT Island. By advertising an ID for the process, uses to form an MRT Island. By advertising an ID for the process,
it is possible to have different processes in the future. It may it is possible to have different processes in the future. It may
be desirable to advertise a list ordered by preference to allow be desirable to advertise a list ordered by preference to allow
transitions. transitions.
MRT Algorithm ID: This identifies the particular MRT algorithm used MRT Algorithm ID: This identifies the particular MRT algorithm used
by the router. By having an Algorithm ID, it is possible to by the router. By having an Algorithm ID, it is possible to
change the algorithm used or use different ones in different change the algorithm used or use different ones in different
skipping to change at page 13, line 4 skipping to change at page 13, line 37
root is elected from the set of routers with the highest priority; root is elected from the set of routers with the highest priority;
ties are broken based upon highest Router ID. The sensitivity of ties are broken based upon highest Router ID. The sensitivity of
the MRT Algorithms to GADAG root selection is still being the MRT Algorithms to GADAG root selection is still being
evaluated. This provides the network operator with a knob to evaluated. This provides the network operator with a knob to
force particular GADAG root selection. force particular GADAG root selection.
Forwarding Mechanism for IP: This specifies which forwarding Forwarding Mechanism for IP: This specifies which forwarding
mechanisms the router supports for IP traffic. An MRT island must mechanisms the router supports for IP traffic. An MRT island must
support a common set of forwarding mechanisms, which may be less support a common set of forwarding mechanisms, which may be less
than the full set advertised. Multiple forwarding mechanisms may than the full set advertised. Multiple forwarding mechanisms may
be specified, such as IP-in-IPv4, IP-in-IPv6 or IP-in-LDP- be specified, such as IP-in-IPv4, IP-in-IPv6 or IP-in-LDP Label.
Destination-Topology Label. None is also an option. None is also an option.
Forwarding Mechanism for LDP: This specifies which forwarding
mechanisms the router supports for LDP traffic. An MRT island
must support a common set of forwarding mechanisms, which may be
less than the full set advertised. The expected mechanisms are
"Encode MT-ID in Labels" or None.
Red MRT Loopback Address: This provides the router's loopback Red MRT Loopback Address: This provides the router's loopback
address to reach the router via the Red MRT forwarding topology. address to reach the router via the Red MRT forwarding topology.
It can, of course, be specified for both IPv4 and IPv6. It can, of course, be specified for both IPv4 and IPv6.
Blue MRT Loopback Address: This provides the router's loopback Blue MRT Loopback Address: This provides the router's loopback
address to reach the router via the Blue MRT forwarding topology. address to reach the router via the Blue MRT forwarding topology.
It can, of course, be specified for both IPv4 and IPv6. It can, of course, be specified for both IPv4 and IPv6.
MRT Capabilities Available: This is the set of capabilities that MRT Capabilities Available: This is the set of capabilities that
skipping to change at page 13, line 47 skipping to change at page 14, line 28
MRT Capability: mLDP Fast-Reroute: The router can use the computed MRT Capability: mLDP Fast-Reroute: The router can use the computed
MRTs for mLDP fast-reroute. MRTs for mLDP fast-reroute.
MRT Capability: PIM Global Protection: The router can use the MRT Capability: PIM Global Protection: The router can use the
computed MRTs for PIM Global Protection 1+1. computed MRTs for PIM Global Protection 1+1.
MRT Capability: mLDP Global Protection: The router can use the MRT Capability: mLDP Global Protection: The router can use the
computed MRTs for mLDP Global Protection 1+1. computed MRTs for mLDP Global Protection 1+1.
The assumption is that a router will form 1 MRT island, compute MRTs The assumption is that a router will form an MRT island, compute MRTs
within that island, and then use those MRTs for the different within that island, and then use those MRTs for the purposes
purposes. Including a router that, for instance, doesn't support specified in the profile. If multiple profiles are supported with
mLDP Global Protection would mean that the whole MRT island could not different purposes (e.g. mLDP Global Protection), then the router may
support it. In a fully deployed case, of course, the whole area/ use a different profile and associated MRT island to be used for the
level would support MRT and the complexities of MRT island formation purposes in that different profile. If a router wanted to form
would be minimal. multiple MRT islands for different application purposes, that could
be done by specifying different Red MRT MT-ID and Blue MRT MT-IDs.
If a router wanted to form multiple MRT islands for different
application purposes, that could be done by specifying different Red
MRT MT-ID and Blue MRT MT-IDs.
As with LFA, it is expected that OSPF Virtual Links will not be As with LFA, it is expected that OSPF Virtual Links will not be
supported. supported.
7. Multi-homed Prefixes 7. Protocol Extensions and considerations: LDP
Capability negotiation in LDP is needed to indicate support for MRT;
having this explicit allows the use of MRT-specific signaling
extensions. A router also needs to indicate, via FEC advertisement,
whether it supports LDP Destination-Topology Labels, LDP Topology
Labels, or both. Since the label or labels are swapped at each LSR,
consistency across the network is not required.
If both mechanisms are supported, then if a Destination-Topology
label is provided for a FEC, that should be used so that an ABR/LBR
can indicate the appropriate labels, as discussed in Section
Section 9.
8. Multi-homed Prefixes
One advantage of LFAs that is necessary to preserve is the ability to One advantage of LFAs that is necessary to preserve is the ability to
protect multi-homed prefixes against ABR failure. For instance, if a protect multi-homed prefixes against ABR failure. For instance, if a
prefix from the backbone is available via both ABR A and ABR B, if A prefix from the backbone is available via both ABR A and ABR B, if A
fails, then the traffic should be redirected to B. This can also be fails, then the traffic should be redirected to B. This can also be
done for backups via MRT. done for backups via MRT.
This generalizes to any multi-homed prefix. A multi-homed prefix This generalizes to any multi-homed prefix. A multi-homed prefix
could be: could be:
o An out-of-area prefix announced by more than one ABR, o An out-of-area prefix announced by more than one ABR,
o An AS-External route announced by 2 or more ASBRs, o An AS-External route announced by 2 or more ASBRs,
o A prefix with iBGP multipath to different ASBRs, o A prefix with iBGP multipath to different ASBRs,
o etc. o etc.
For each prefix, the two lowest total cost ABRs are selected and a For each prefix, the attached ABRs are selected and a proxy-node is
proxy-node is created connected to those two ABRs. If there exist created connected to those ABRs. If there exist multiple multi-homed
multiple multi-homed prefixes that share the same two best prefixes that share the same connectivity and costs to each of those
connectivity, then a single proxy-node can be used to represent the ABRs, then a single proxy-node can be used to represent the set. An
set. An example of this is shown in Figure 3. example of this is shown in Figure 3.
2 2 2 2 2 2 2 2
A----B----C A----B----C A----B----C A----B----C
2 | | 2 2 | | 2 2 | | 2 2 | | 2
| | | | | | | |
[ABR1] [ABR2] [ABR1] [ABR2] [ABR1] [ABR2] [ABR1] [ABR2]
| | | | | | | |
p,10 p,15 10 |---[P]---| 15 p,10 p,15 10 |---[P]---| 15
(a) Initial topology (b)with proxy-node (a) Initial topology (b)with proxy-node
skipping to change at page 15, line 43 skipping to change at page 16, line 24
Each ABR or attaching router must remove the MRT marking[see Each ABR or attaching router must remove the MRT marking[see
Section 5] and then forward the traffic outside of the area (or Section 5] and then forward the traffic outside of the area (or
island of MRT-fast-reroute-supporting routers). island of MRT-fast-reroute-supporting routers).
If ASBR protection is desired, this has additonal complexities if the If ASBR protection is desired, this has additonal complexities if the
ASBRs are in different areas. Similarly, protecting labeled BGP ASBRs are in different areas. Similarly, protecting labeled BGP
traffic in the event of an ASBR failure has additional complexities traffic in the event of an ASBR failure has additional complexities
due to the per-ASBR label spaces involved. due to the per-ASBR label spaces involved.
8. Inter-Area and ABR Forwarding Behavior 9. Inter-Area and ABR Forwarding Behavior
In regular forwarding, packets destined outside the area arrive at In regular forwarding, packets destined outside the area arrive at
the ABR and the ABR forwards them into the other area because the the ABR and the ABR forwards them into the other area because the
next-hops from the area with the best route (according to tie- next-hops from the area with the best route (according to tie-
breaking rules) are used by the ABR. The question is then what to do breaking rules) are used by the ABR. The question is then what to do
with packets marked with an MRT that are received by the ABR. with packets marked with an MRT that are received by the ABR.
For unicast fast-reroute, the need to stay on an MRT forwarding For unicast fast-reroute, the need to stay on an MRT forwarding
topology terminates at the ABR/LBR whose best route is via a topology terminates at the ABR/LBR whose best route is via a
different area/level. It is highly desirable to go back to the different area/level. It is highly desirable to go back to the
default forwarding topology when leaving an area/level. There are default forwarding topology when leaving an area/level. There are
three basic reasons for this. First, the default topology uses three basic reasons for this. First, the default topology uses
shortest paths; the packet will thus take the shortest possible route shortest paths; the packet will thus take the shortest possible route
to the destination. Second, this allows failures that might appear to the destination. Second, this allows failures that might appear
in multiple areas (e.g. ABR/LBR failures) to be separately in multiple areas (e.g. ABR/LBR failures) to be separately
identified and repaired around. Third, the packet can be fast- identified and repaired around. Third, the packet can be fast-
rerouted again, if necessary, due to a failure in a different area. rerouted again, if necessary, due to a failure in a different area.
An ABR/LBR that receives a packet marked with an MRT towards a An ABR/LBR that receives a packet marked with an MRT towards a
destination in another area should forward the MRT marked packet in destination in another area/level should forward the MRT marked
the area with the best route along its associated MRT. If the packet packet in the area/level with the best route along its associated
came from that area, this correctly avoids the failure. MRT. If the packet came from that area/level, this correctly avoids
the failure.
How does an ABR/LBR ensure that MRT-marked packets do not arrive at How does an ABR/LBR ensure that MRT-marked packets do not arrive at
the ABR/LBR? There are two different mechanisms depending upon the the ABR/LBR? There are two different mechanisms depending upon the
forwarding mechanism being used. forwarding mechanism being used.
If the LDP label encodes the MT-ID as well as the destination, then If the LDP label encodes the MT-ID as well as the destination, then
the ABR/LBR is responsible for advertising a particular label to each the ABR/LBR is responsible for advertising a particular label to each
neighbor. Additionally, an LDP label is associated with an MT-ID due neighbor. Additionally, an LDP label is associated with an MT-ID due
to the MT FEC that was used and not due to any intrisic particular to the MT FEC that was used and not due to any intrisic particular
value for the label. Assume that an ABR/LBR has allocated three value for the label. Assume that an ABR/LBR has allocated three
skipping to change at page 18, line 28 skipping to change at page 19, line 18
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 this is a realistic along the MRT in the other area would happen. If this is a realistic
deployment scenario, OSPF extensions could be considered. deployment scenario, OSPF extensions could be considered.
9. Issues with Area Abstraction 10. Issues with Area Abstraction
MRT fast-reroute provides complete coverage in a area that is MRT fast-reroute provides complete coverage in a area that is
2-connected. Where a failure would partition the network, of course, 2-connected. Where a failure would partition the network, of course,
no alternate can protect against that failure. Similarly, there are no alternate can protect against that failure. Similarly, there are
ways of connecting multi-homed prefixes that make it impractical to ways of connecting multi-homed prefixes that make it impractical to
protect them without excessive complexity. protect them without excessive complexity.
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
skipping to change at page 19, line 30 skipping to change at page 20, line 21
p ---[ASBR X]-X-[A]---[B]---[ABR 1]---[D]---[ASBR Y]--- p p ---[ASBR X]-X-[A]---[B]---[ABR 1]---[D]---[ASBR Y]--- p
BGP prefers ASBR X for prefix p BGP prefers ASBR X for prefix p
Figure 6: Failure of path towards ASBR preferred by BGP Figure 6: Failure of path towards ASBR preferred by BGP
The fine details of how to solve multi-area external prefix cases, or The fine details of how to solve multi-area external prefix cases, or
identifying certain cases as too unlikely and too complex to protect identifying certain cases as too unlikely and too complex to protect
is for further consideration. is for further consideration.
10. Partial Deployment and Islands of Compatible MRT FRR routers 11. Partial Deployment and Islands of Compatible MRT FRR routers
A natural concern with new functionality is how to have it be useful A natural concern with new functionality is how to have it be useful
when it is not deployed across an entire IGP area. In the case of when it is not deployed across an entire IGP area. In the case of
MRT FRR, where it provides alternates when appropriate LFAs aren't MRT FRR, where it provides alternates when appropriate LFAs aren't
available, there are also deployment scenarios where it may make available, there are also deployment scenarios where it may make
sense to only enable some routers in an area with MRT FRR. A simple sense to only enable some routers in an area with MRT FRR. A simple
example of such a scenario would be a ring of 6 or more routers that example of such a scenario would be a ring of 6 or more routers that
is connected via two routers to the rest of the area. is connected via two routers to the rest of the area.
First, a computing router S must determine its local island of First, a computing router S must determine its local island of
compatible MRT fast-reroute routers. A router that has common compatible MRT fast-reroute routers. A router that has a common
forwarding mechanisms and common algorithm and is connected to either profile flag and is connected either to S or to another router
to S or to another router already determined to be in S's local already determined to be in S's local island can be added to S's
island can be added to S's local island. local island.
Destinations inside the local island can obviously use MRT Destinations inside the local island can obviously use MRT
alternates. Destinations outside the local island can be treated alternates. Destinations outside the local island can be treated
like a multi-homed prefix with caveats to avoid looping. For LDP like a multi-homed prefix with caveats to avoid looping. For LDP
labels including both destination and topology, the routers at the labels including both destination and topology, the routers at the
borders of the local island need to originate labels for the original borders of the local island need to originate labels for the original
FEC and the associated MRT-specific labels. Packets sent to an LDP FEC and the associated MRT-specific labels. Packets sent to an LDP
label marked as blue or red MRT to a destination outside the local label marked as blue or red MRT to a destination outside the local
island will have the last router in the local island swap the label island will have the last router in the local island swap the label
to one for the destination and forward the packet along the outgoing to one for the destination and forward the packet along the outgoing
skipping to change at page 20, line 37 skipping to change at page 21, line 29
A key question is which routers outside the MRT island can packets be A key question is which routers outside the MRT island can packets be
forwarded to so that they are not forwarded back into the MRT island. forwarded to so that they are not forwarded back into the MRT island.
An example of the necessary network graph transformations are given An example of the necessary network graph transformations are given
in Figure 7. There are two parts to the computation. First, the MRT in Figure 7. There are two parts to the computation. First, the MRT
island is collapsed into a single node; this assumes that the cost of island is collapsed into a single node; this assumes that the cost of
transiting the MRT island is nothing and is pessimistic but allows transiting the MRT island is nothing and is pessimistic but allows
for simpler computation. Then, for each destination (other than the for simpler computation. Then, for each destination (other than the
MRT island), the routers adjacent to the MRT island are checked to MRT island), the routers adjacent to the MRT island are checked to
see if they are loop-free with respect to the MRT island and the see if they are loop-free with respect to the MRT island and the
destination. The two loop-free neighbors of the MRT island that are destination. The loop-free neighbors of the MRT island that are
closest to the destination are selected. Then, a graph of just the closest to the destination are selected. Then, a graph of just the
MRT island is augmented with proxy-nodes that are attached via the MRT island is augmented with proxy-nodes that are attached via the
outgoing interfaces to the selected loop-free neighbors. Finally, outgoing interfaces to the selected loop-free neighbors. Finally,
the MRTs rooted at each proxy-node are computed on that augmented MRT the MRTs rooted at each proxy-node are computed on that augmented MRT
island graph. Essentially, the MRT island must have a loop-free island graph. Essentially, the MRT island must have a loop-free
neighbor to be able to have an alternate. neighbor to be able to have an alternate.
[G]---[E]---(B)---(C)---(D) [G]---[E]---(B)---(C)---(D)
| \ | | | | \ | | |
| \ | | | | \ | | |
skipping to change at page 21, line 31 skipping to change at page 22, line 31
(2) Graph for determining (3) Graph for MRT computation (2) Graph for determining (3) Graph for MRT computation
loop-free neighbors loop-free neighbors
Figure 7: Computing alternates to destinations outside the MRT Island Figure 7: Computing alternates to destinations outside the MRT Island
Naturally, there are more complicated options to improve coverage, Naturally, there are more complicated options to improve coverage,
such as connecting multiple MRT islands across tunnels, but it is not such as connecting multiple MRT islands across tunnels, but it is not
clear that the additional complexity is necessary. clear that the additional complexity is necessary.
11. Network Convergence and Preparing for the Next Failure 12. Network Convergence and Preparing for the Next Failure
After a failure, MRT detours ensure that packets reach their intended After a failure, MRT detours ensure that packets reach their intended
destination while the IGP has not reconverged onto the new topology. destination while the IGP has not reconverged onto the new topology.
As link-state updates reach the routers, the IGP process calculates As link-state updates reach the routers, the IGP process calculates
the new shortest paths. Two things need attention: micro-loop the new shortest paths. Two things need attention: micro-loop
prevention and MRT re-calculation. prevention and MRT re-calculation.
11.1. Micro-forwarding loop prevention and MRTs 12.1. Micro-forwarding loop prevention and MRTs
As is well known[RFC5715], micro-loops can occur during IGP As is well known[RFC5715], micro-loops can occur during IGP
convergence; such loops can be local to the failure or remote from convergence; such loops can be local to the failure or remote from
the failure. Managing micro-loops is an orthogonal issue to having the failure. Managing micro-loops is an orthogonal issue to having
alternates for local repair, such as MRT fast-reroute provides. alternates for local repair, such as MRT fast-reroute provides.
There are two possible micro-loop prevention mechanism discussed in There are two possible micro-loop prevention mechanism discussed in
[RFC5715]. The first is Ordered FIB [I-D.ietf-rtgwg-ordered-fib]. [RFC5715]. The first is Ordered FIB [I-D.ietf-rtgwg-ordered-fib].
The second is Farside Tunneling which requires tunnels or an The second is Farside Tunneling which requires tunnels or an
alternate topology to reach routers on the farside of the failure. alternate topology to reach routers on the farside of the failure.
Since MRTs provide an alternate topology through which traffic can be Since MRTs provide an alternate topology through which traffic can be
sent and which can be manipulated separately from the SPT, it is sent and which can be manipulated separately from the SPT, it is
possible that MRTs could be used to support Farside Tunneling. possible that MRTs could be used to support Farside Tunneling.
Details of how to do so are outside of this document. Details of how to do so are outside of this document.
11.2. MRT Recalculation 12.2. MRT Recalculation
When a failure event happens, traffic is put by the PLRs onto the MRT When a failure event happens, traffic is put by the PLRs onto the MRT
topologies. After that, each router recomputes its shortest path topologies. After that, each router recomputes its shortest path
tree (SPT) and moves traffic over to that. Only after all the PLRs tree (SPT) and moves traffic over to that. Only after all the PLRs
have switched to using their SPTs and traffic has drained from the have switched to using their SPTs and traffic has drained from the
MRT topologies should each router install the recomputed MRTs into MRT topologies should each router install the recomputed MRTs into
the FIBs. the FIBs.
At each router, therefore, the sequence is as follows: At each router, therefore, the sequence is as follows:
skipping to change at page 22, line 36 skipping to change at page 23, line 36
4. Recompute MRTs 4. Recompute MRTs
5. Wait configured period for all routers to be using their SPTs and 5. Wait configured period for all routers to be using their SPTs and
traffic to drain from the MRTs. traffic to drain from the MRTs.
6. Install new MRTs. 6. Install new MRTs.
While the recomputed MRTs are not installed in the FIB, protection While the recomputed MRTs are not installed in the FIB, protection
coverage is lowered. Therefore, it is important to recalculate the coverage is lowered. Therefore, it is important to recalculate the
MRTs and install them as quickly as possible. MRTs and install them quickly.
The installation of the MRTs can be staged such that the affected or
broken MRTs are updated first and then the unbroken.
12. Acknowledgements 13. Acknowledgements
The authors would like to thank Hannes Gredler, Jeff Tantsura, Ted The authors would like to thank Hannes Gredler, Jeff Tantsura, Ted
Qian, Kishore Tiruveedhula, Santosh Esale, Nitin Bahadur, Harish Qian, Kishore Tiruveedhula, Santosh Esale, Nitin Bahadur, Harish
Sitaraman and Raveendra Torvi for their suggestions and review. Sitaraman and Raveendra Torvi for their suggestions and review.
13. IANA Considerations 14. IANA Considerations
This doument includes no request to IANA. This doument includes no request to IANA.
14. Security Considerations 15. Security Considerations
This architecture is not currently believed to introduce new security This architecture is not currently believed to introduce new security
concerns. concerns.
15. References 16. References
15.1. Normative References 16.1. Normative References
[I-D.enyedi-rtgwg-mrt-frr-algorithm] [I-D.enyedi-rtgwg-mrt-frr-algorithm]
Enyedi, G., Atlas, A. and A. Csaszar, "Algorithms for Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan,
computing Maximally Redundant Trees for IP/LDP Fast- "Algorithms for computing Maximally Redundant Trees for
Reroute", draft-enyedi-rtgwg-mrt-frr-algorithm-01 (work IP/LDP Fast- Reroute",
in progress), March 2012. draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in
progress), October 2012.
[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", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, January 2010. RFC 5714, January 2010.
15.2. Informative References 16.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-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", Maximally Redundant Trees",
draft-atlas-rtgwg-mrt-mc-arch-00 (work in progress), draft-atlas-rtgwg-mrt-mc-arch-00 (work in progress),
March 2012. March 2012.
[I-D.ietf-mpls-ldp-multi-topology] [I-D.ietf-mpls-ldp-multi-topology]
Zhao, Q., Fang, L., Zhou, C., Li, L., and N. So, "LDP Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP
Extensions for Multi Topology Routing", Extensions for Multi Topology Routing",
draft-ietf-mpls-ldp-multi-topology-03 (work in progress), draft-ietf-mpls-ldp-multi-topology-06 (work in progress),
March 2012. December 2012.
[I-D.ietf-rtgwg-ipfrr-notvia-addresses] [I-D.ietf-rtgwg-ipfrr-notvia-addresses]
Bryant, S., Previdi, S., and M. Shand, "IP Fast Reroute Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
Using Not-via Addresses", and MPLS Fast Reroute Using Not-via Addresses",
draft-ietf-rtgwg-ipfrr-notvia-addresses-08 (work in draft-ietf-rtgwg-ipfrr-notvia-addresses-10 (work in
progress), December 2011. progress), December 2012.
[I-D.ietf-rtgwg-lfa-applicability] [I-D.ietf-rtgwg-lfa-applicability]
Filsfils, C. and P. Francois, "LFA applicability in SP Filsfils, C. and P. Francois, "LFA applicability in SP
networks", draft-ietf-rtgwg-lfa-applicability-06 (work in networks", draft-ietf-rtgwg-lfa-applicability-06 (work in
progress), January 2012. progress), January 2012.
[I-D.ietf-rtgwg-ordered-fib] [I-D.ietf-rtgwg-ordered-fib]
Shand, M., Bryant, S., Previdi, S., and C. Filsfils, Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
"Loop-free convergence using oFIB", Francois, P., and O. Bonaventure, "Framework for Loop-free
draft-ietf-rtgwg-ordered-fib-05 (work in progress), convergence using oFIB", draft-ietf-rtgwg-ordered-fib-09
April 2011. (work in progress), January 2013.
[I-D.ietf-rtgwg-remote-lfa]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01
(work in progress), December 2012.
[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, <http://opti.tmit.bme.hu/ of IEEE INFOCOM , 2011, <http://opti.tmit.bme.hu/
~tapolcai/papers/retvari2011lfa_infocom.pdf>. ~tapolcai/papers/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
Fast ReRoute: Lightweight Not-Via without Additional Fast ReRoute: Lightweight Not-Via without Additional
skipping to change at page 25, line 20 skipping to change at page 26, line 28
Email: Gabor.Sandor.Enyedi@ericsson.com Email: Gabor.Sandor.Enyedi@ericsson.com
Andras Csaszar Andras Csaszar
Ericsson Ericsson
Konyves Kalman krt 11 Konyves Kalman krt 11
Budapest 1097 Budapest 1097
Hungary Hungary
Email: Andras.Csaszar@ericsson.com Email: Andras.Csaszar@ericsson.com
Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
USA
Email: jeff.tantsura@ericsson.com
Maciek Konstantynowicz Maciek Konstantynowicz
Cisco Systems Cisco Systems
Email: maciek@bgp.nu Email: maciek@bgp.nu
Russ White Russ White
Cisco Systems Verisign
12061 Bluemont Way
Reston, VA 20190
USA
Email: russwh@cisco.com Email: riwhite@verisign.com
Mike Shand Mike Shand
Email: mike@mshand.org.uk Email: mike@mshand.org.uk
 End of changes. 44 change blocks. 
107 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/