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/ |