draft-ietf-rtgwg-mrt-frr-architecture-07.txt   draft-ietf-rtgwg-mrt-frr-architecture-08.txt 
Routing Area Working Group A. Atlas, Ed. Routing Area Working Group A. Atlas
Internet-Draft R. Kebler Internet-Draft C. Bowers
Intended status: Standards Track C. Bowers Intended status: Standards Track Juniper Networks
Expires: April 17, 2016 Juniper Networks Expires: June 23, 2016 G. Enyedi
G. Enyedi
A. Csaszar
J. Tantsura
Ericsson Ericsson
R. White December 21, 2015
VCE
October 15, 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-07 draft-ietf-rtgwg-mrt-frr-architecture-08
Abstract Abstract
With increasing deployment of Loop-Free Alternates (LFA) [RFC5286], This document defines the architecture for IP/LDP Fast-Reroute using
it is clear that a complete solution for IP and LDP Fast-Reroute is Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that
required. This specification provides that solution. IP/LDP Fast-
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.
MRT removes all need to engineer for coverage. MRT is also extremely MRT removes the need to engineer for coverage. MRT is also extremely
computationally efficient. For any router in the network, the MRT computationally efficient. For any router in the network, the MRT
computation is less than the LFA computation for a node with three or computation is less than the LFA computation for a node with three or
more neighbors. more neighbors.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 17, 2016. This Internet-Draft will expire on June 23, 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 30 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 12 6.1. MRT Forwarding Mechanisms . . . . . . . . . . . . . . . . 11
6.1.1. MRT LDP labels . . . . . . . . . . . . . . . . . . . 12 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) . . . . . . . . . . . . . . . . . . . 13 (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 . . 14 6.1.1.4. Mandatory support for MRT LDP Label option 1A . . 13
6.1.2. MRT IP tunnels (Options 2A and 2B) . . . . . . . . . 14 6.1.2. MRT IP tunnels (Options 2A and 2B) . . . . . . . . . 13
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) . . . . . . . . . . . . . . . . . . . . . . . . . 15 1A) . . . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . 16 6.3. Forwarding IP Unicast Traffic over MRT Paths . . . . . . 15
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) . . . . . . . . . . . . . . . . . . . . . . . 17 1B) . . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 20 8.1. MRT Profile Options . . . . . . . . . . . . . . . . . . . 20
8.2. Router-specific MRT paramaters . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . 23 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 . . . . . . 24 10.1.1. Motivation for Creating the Rainbow-FEC . . . . . . 24
skipping to change at page 3, line 28 skipping to change at page 3, line 21
9. LDP signaling extensions and considerations . . . . . . . . . 22 9. LDP signaling extensions and considerations . . . . . . . . . 22
10. Inter-area Forwarding Behavior . . . . . . . . . . . . . . . 23 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 . . . . . . 24 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 . . . . 25 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.3. MRT Alternates for Destinations Outside the MRT Island . 31
11.3. MRT Alternates for Destinations Outside the MRT Island . 33 12. Network Convergence and Preparing for the Next Failure . . . 31
12. Network Convergence and Preparing for the Next Failure . . . 34 12.1. Micro-forwarding loop prevention and MRTs . . . . . . . 32
12.1. Micro-forwarding loop prevention and MRTs . . . . . . . 34 12.2. MRT Recalculation for the Default MRT Profile . . . . . 32
12.2. MRT Recalculation . . . . . . . . . . . . . . . . . . . 34 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 33
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 35 14. Operations and Management Considerations . . . . . . . . . . 34
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 15. Applying Policy to Select from Multiple Possible Alternates
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 for FRR . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
16. Security Considerations . . . . . . . . . . . . . . . . . . . 37 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
17.1. Normative References . . . . . . . . . . . . . . . . . . 37 18. Security Considerations . . . . . . . . . . . . . . . . . . . 36
17.2. Informative References . . . . . . . . . . . . . . . . . 37 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
20.1. Normative References . . . . . . . . . . . . . . . . . . 36
20.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. General Issues with Area Abstraction . . . . . . . . 40 Appendix A. General Issues with Area Abstraction . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document gives a complete solution for IP/LDP fast-reroute This document describes a solution for IP/LDP fast-reroute [RFC5714].
[RFC5714]. MRT-FRR creates two alternate trees separate from the MRT-FRR creates two alternate trees separate from the primary next-
primary next-hop forwarding used during stable operation. These two hop forwarding used during stable operation. These two trees are
trees are maximally diverse from each other, providing link and node maximally diverse from each other, providing link and node protection
protection for 100% of paths and failures as long as the failure does for 100% of paths and failures as long as the failure does not cut
not cut the network into multiple pieces. This document defines the 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.ietf-ospf-mrt] and protocol extensions are defined in [I-D.ietf-ospf-mrt] and
[I-D.ietf-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.
skipping to change at page 5, line 20 skipping to change at page 5, line 17
Remote LFA: Remote LFAs [RFC7490] improve coverage over LFAs for Remote LFA: Remote LFAs [RFC7490] improve coverage over LFAs for
link protection but still cannot guarantee complete coverage. The link protection but still cannot guarantee complete coverage. The
trade-off of looping traffic to improve coverage is still made. trade-off of looping traffic to improve coverage is still made.
Remote LFAs can provide node-protection Remote LFAs can provide node-protection
[I-D.ietf-rtgwg-rlfa-node-protection] but not guaranteed coverage [I-D.ietf-rtgwg-rlfa-node-protection] but not guaranteed coverage
and the computation required is quite high (an SPF for each PQ- and the computation required is quite high (an SPF for each PQ-
node evaluated). [I-D.bryant-ipfrr-tunnels] describes additional node evaluated). [I-D.bryant-ipfrr-tunnels] describes additional
mechanisms to further improve coverage, at the cost of added mechanisms to further improve coverage, at the cost of added
complexity. complexity.
Not-Via: Not-Via [I-D.ietf-rtgwg-ipfrr-notvia-addresses] is the Not-Via: Not-Via [RFC6981] is the only other solution that provides
only other solution that provides 100% coverage for link and node 100% coverage for link and node failures and does not have
failures and does not have potential looping. However, the potential looping. However, the computation is very high (an SPF
computation is very high (an SPF per failure point) and academic per failure point) and academic implementations
implementations [LightweightNotVia] have found the address [LightweightNotVia] have found the address management complexity
management complexity to be high. to be high.
TI-LFA: Topology Independent Loop-free Alternate Fast Re-route (TI- TI-LFA: Topology Independent Loop-free Alternate Fast Re-route (TI-
LFA) [I-D.francois-spring-segment-routing-ti-lfa] aims to provide LFA) [I-D.francois-rtgwg-segment-routing-ti-lfa] aims to provide
link and node protection of node and adjacency segments within the link and node protection of node and adjacency segments within the
Segment Routing (SR) framework. It guarantees complete coverage. Segment Routing (SR) framework. It guarantees complete coverage.
The TI-LFA computation for link-protection is fairly The TI-LFA computation for link-protection is fairly
straightforward, while the computation for node-protection is more straightforward, while the computation for node-protection is more
complex. For link-protection with symmetric link costs, TI-LFA complex. For link-protection with symmetric link costs, TI-LFA
can provide complete coverage by pushing up to two additional can provide complete coverage by pushing up to two additional
labels. For node protection on arbitrary topologies, the label labels. For node protection on arbitrary topologies, the label
stack size can grow significantly based on repair path. Note that stack size can grow significantly based on repair path. Note that
TI-LFA requires shortest path forwarding based on SR Node-SIDs, as TI-LFA requires shortest path forwarding based on SR Node-SIDs, as
opposed to LDP labels, in order to construct label stacks for opposed to LDP labels, in order to construct label stacks for
skipping to change at page 6, line 23 skipping to change at page 6, line 18
topology-sensitive methods such as LFA and Remote LFA. If fast- topology-sensitive methods such as LFA and Remote LFA. If fast-
reroute is important for the network services provided, then a method reroute is important for the network services provided, then a method
that guarantees 100% coverage is important to accomodate natural that guarantees 100% coverage is important to accomodate natural
network topology changes. network topology changes.
Asymmetric link costs are also a common aspect of networks. There Asymmetric link costs are also a common aspect of networks. There
are at least three common causes for them. First, any broadcast are at least three common causes for them. First, any broadcast
interface is represented by a pseudo-node and has asymmetric link interface is represented by a pseudo-node and has asymmetric link
costs to and from that pseudo-node. Second, when routers come up or costs to and from that pseudo-node. Second, when routers come up or
a link with LDP comes up, it is recommended in [RFC5443] and a link with LDP comes up, it is recommended in [RFC5443] and
[RFC3137] that the link metric be raised to the maximum cost; this [RFC6987] that the link metric be raised to the maximum cost; this
may not be symmetric and for [RFC3137] is not expected to be. Third, may not be symmetric and for [RFC6987] is not expected to be. Third,
techniques such as IGP metric tuning for traffic-engineering can techniques such as IGP metric tuning for traffic-engineering can
result in asymmetric link costs. A fast-reroute solution needs to result in asymmetric link costs. A fast-reroute solution needs to
handle network topologies with asymmetric link costs. handle network topologies with asymmetric link costs.
When a network needs to use a micro-loop prevention mechanism When a network needs to use a micro-loop prevention mechanism
[RFC5715] such as Ordered FIB[I-D.ietf-rtgwg-ordered-fib] or Farside [RFC5715] such as Ordered FIB[RFC6976] or Farside Tunneling[RFC5715],
Tunneling[RFC5715], then the whole IGP area needs to have alternates then the whole IGP area needs to have alternates available so that
available so that the micro-loop prevention mechanism, which requires the micro-loop prevention mechanism, which requires slower network
slower network convergence, can take the necessary time without convergence, can take the necessary time without adversely impacting
adversely impacting traffic. Without complete coverage, traffic to traffic. Without complete coverage, traffic to the unprotected
the unprotected destinations will be dropped for significantly longer destinations will be dropped for significantly longer than with
than with current convergence - where routers individually converge current convergence - where routers individually converge as fast as
as fast as possible. possible.
1.2. Partial Deployment and Backwards Compatibility 1.2. Partial Deployment and Backwards Compatibility
MRT-FRR supports partial deployment. As with many new features, the MRT-FRR supports partial deployment. As with many new features, the
protocols (OSPF, LDP, ISIS) indicate their capability to support MRT. protocols (OSPF, LDP, ISIS) indicate their capability to support MRT.
Inside the MRT-capable connected group of routers (referred to as an Inside the MRT-capable connected group of routers (referred to as an
MRT Island), the MRTs are computed. Alternates to destinations MRT Island), the MRTs are computed. Alternates to destinations
outside the MRT Island are computed and depend upon the existence of outside the MRT Island are computed and depend upon the existence of
a loop-free neighbor of the MRT Island for that destination. a loop-free neighbor of the MRT Island for that destination.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
network graph: A graph that reflects the network topology where all network graph: A graph that reflects the network topology where all
links connect exactly two nodes and broadcast links have been links connect exactly two nodes and broadcast links have been
transformed into the standard pseudo-node representation. transformed into the standard pseudo-node representation.
Redundant Trees (RT): A pair of trees where the path from any node Redundant Trees (RT): A pair of trees where the path from any node
X to the root R along the first tree is node-disjoint with the X to the root R along the first tree is node-disjoint with the
path from the same node X to the root along the second tree. path from the same node X to the root along the second tree.
skipping to change at page 7, line 38 skipping to change at page 7, line 38
MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is
used to described the associated forwarding topology and MPLS MT- used to described the associated forwarding topology and MPLS MT-
ID. Specifically, MRT-Blue is the increasing MRT where links in ID. Specifically, MRT-Blue is the increasing MRT where links in
the GADAG are taken in the direction from a lower topologically the GADAG are taken in the direction from a lower topologically
ordered node to a higher one. ordered node to a higher one.
Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the
multiple MRT topologies and to the default topology. This is multiple MRT topologies and to the default topology. This is
referred to as the Rainbow MRT MPLS MT-ID and is used by LDP to referred to as the Rainbow MRT MPLS MT-ID and is used by LDP to
reduce signalling and permit the same label to always be reduce signaling and permit the same label to always be advertised
advertised to all peers for the same (MT-ID, Prefix). to all peers for the same (MT-ID, Prefix).
MRT Island: The set of routers that support a particular MRT MRT Island: The set of routers that support a particular MRT
profile and the links connecting them that support MRT. profile and the links connecting them that support MRT.
Island Border Router (IBR): A router in the MRT Island that is Island Border Router (IBR): A router in the MRT Island that is
connected to a router not in the MRT Island and both routers are connected to a router not in the MRT Island and both routers are
in a common area or level. in a common area or level.
Island Neighbor (IN): A router that is not in the MRT Island but is Island Neighbor (IN): A router that is not in the MRT Island but is
adjacent to an IBR and in the same area/level as the IBR. adjacent to an IBR and in the same area/level as the IBR.
skipping to change at page 10, line 42 skipping to change at page 10, line 42
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 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. [RFC6981] or [RFC7490]), and per-interface
[RFC7490]), and per-interface forwarding (e.g. Loop-Free Failure forwarding (e.g. Loop-Free Failure Insensitive Routing in
Insensitive Routing in [EnyediThesis]). [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 11, line 29 skipping to change at page 11, line 29
micro-looping. Section 1.1 of [RFC5286] gives an example of link- micro-looping. Section 1.1 of [RFC5286] gives an example of link-
protecting alternates causing a loop on node failure. Even if a protecting alternates causing a loop on node failure. Even if a
worse failure than anticipated happens, the use of MRT alternates worse failure than anticipated happens, the use of MRT alternates
will not cause looping. Therefore, while node-protecting LFAs may be will not cause looping. Therefore, while node-protecting LFAs may be
preferred, the certainty that no alternate-induced looping will occur preferred, the certainty that no alternate-induced looping will occur
is an advantage of using MRT alternates when the available node- is an advantage of using MRT alternates when the available node-
protecting LFA is not a downstream path. protecting LFA is not a downstream path.
6. Unicast Forwarding with MRT Fast-Reroute 6. Unicast Forwarding with MRT Fast-Reroute
As mentioned before, MRT FRR needs multi-topology forwarding.
Unfortunately, neither IP nor LDP provides extra bits for a packet to
indicate its topology. Once the MRTs are computed, the two sets of
MRTs can be used as two additional forwarding topologies. The same
considerations apply for forwarding along the MRTs as for handling
multiple topologies.
There are three possible types of routers involved in forwarding a There are three possible types of routers involved in forwarding a
packet along an MRT path. At the MRT ingress router, the packet packet along an MRT path. At the MRT ingress router, the packet
leaves the shortest path to the destination and follows an MRT path leaves the shortest path to the destination and follows an MRT path
to the destination. In a FRR application, the MRT ingress router is to the destination. In a FRR application, the MRT ingress router is
the PLR. An MRT transit router takes a packet that arrives already the PLR. An MRT transit router takes a packet that arrives already
associated with the particular MRT, and forwards it on that same MRT. associated with the particular MRT, and forwards it on that same MRT.
In some situations (to be discussed later), the packet will need to In some situations (to be discussed later), the packet will need to
leave the MRT path and return to the shortest path. This takes place leave the MRT path and return to the shortest path. This takes place
at the MRT egress router. The MRT ingress and egress functionality at the MRT egress router. The MRT ingress and egress functionality
may depend on the underlying type of packet being forwarded (LDP or may depend on the underlying type of packet being forwarded (LDP or
skipping to change at page 13, line 38 skipping to change at page 13, line 29
As with Option 1A, this forwarding mechanism also has the useful As with Option 1A, this forwarding mechanism also has the useful
property that the FEC associated with the packet is maintained in the property that the FEC associated with the packet is maintained in the
labels at each hop along the MRT. labels at each hop along the MRT.
This forwarding mechanism has minimal usage of additional labels, This forwarding mechanism has minimal usage of additional labels,
memory and LDP communication. It does increase the size of packets memory and LDP communication. It does increase the size of packets
and the complexity of the required label operations and look-ups. and the complexity of the required label operations and look-ups.
This forwarding option is consistent with context-specific label This forwarding option is consistent with context-specific label
spaces, as described in [RFC 5331]. However, the precise LDP spaces, as described in [RFC5331]. However, the precise LDP behavior
behavior required to support this option for MRT has not been required to support this option for MRT has not been specified.
specified.
6.1.1.3. Compatibility of Option 1A and 1B 6.1.1.3. Compatibility of Option 1A and 1B
In principle, MRT transit forwarding mechanisms 1A and 1B can coexist In principle, MRT transit forwarding mechanisms 1A and 1B can coexist
in the same network, with a packet being forwarding along a single in the same network, with a packet being forwarding along a single
MRT path using the single label of option 1A for some hops and the MRT path using the single label of option 1A for some hops and the
two label stack of option 1B for other hops. two label stack of option 1B for other hops.
6.1.1.4. Mandatory support for MRT LDP Label option 1A 6.1.1.4. Mandatory support for MRT LDP Label option 1A
skipping to change at page 14, line 20 skipping to change at page 14, line 5
6.1.2. MRT IP tunnels (Options 2A and 2B) 6.1.2. MRT IP tunnels (Options 2A and 2B)
IP tunneling can also be used as an MRT transit forwarding mechanism. IP tunneling can also be used as an MRT transit forwarding mechanism.
Each router supporting this MRT transit forwarding mechanism Each router supporting this MRT transit forwarding mechanism
announces two additional loopback addresses and their associated MRT announces two additional loopback addresses and their associated MRT
color. Those addresses are used as destination addresses for MRT- color. Those addresses are used as destination addresses for MRT-
blue and MRT-red IP tunnels respectively. The special loopback blue and MRT-red IP tunnels respectively. The special loopback
addresses allow the transit nodes to identify the traffic as being addresses allow the transit nodes to identify the traffic as being
forwarded along either the MRT-blue or MRT-red topology to reach the forwarded along either the MRT-blue or MRT-red topology to reach the
tunnel destination. Announcements of these two additional loopback tunnel destination. For example, an MRT ingress router can cause a
addresses per router with their MRT color requires IGP extensions, packet to be tunneled along the MRT-red path to router X by
which have not been defined. encapsulating the packet using the MRT-red loopback address
advertised by router X. Upon receiving the packet, router X would
remove the encapsulation header and forward the packet based on the
original destination address.
Announcements of these two additional loopback addresses per router
with their MRT color requires IGP extensions, which have not been
defined.
Either IPv4 (option 2A) or IPv6 (option 2B) can be used as the Either IPv4 (option 2A) or IPv6 (option 2B) can be used as the
tunneling mechanism. tunneling mechanism.
Note that the two forwarding mechanisms using LDP Label options do Note that the two forwarding mechanisms using LDP Label options do
not require additional loopbacks per router, as is required by the IP not require additional loopbacks per router, as is required by the IP
tunneling mechanism. This is because LDP labels are used on a hop- tunneling mechanism. This is because LDP labels are used on a hop-
by-hop basis to identify MRT-blue and MRT-red forwarding topologies. by-hop basis to identify MRT-blue and MRT-red forwarding topologies.
6.2. Forwarding LDP Unicast Traffic over MRT Paths 6.2. Forwarding LDP Unicast Traffic over MRT Paths
skipping to change at page 14, line 46 skipping to change at page 14, line 38
type of traffic being carried. We now look at the MRT ingress type of traffic being carried. We now look at the MRT ingress
functionality, which will depend on the type of traffic being carried functionality, which will depend on the type of traffic being carried
(IP or LDP). We start by considering LDP traffic. (IP or LDP). We start by considering LDP traffic.
We also simplify the initial discussion by assuming that the network We also simplify the initial discussion by assuming that the network
consists of a single IGP area, and that all routers in the network consists of a single IGP area, and that all routers in the network
participate in MRT. Other deployment scenarios that require MRT participate in MRT. Other deployment scenarios that require MRT
egress functionality are considered later in this document. egress functionality are considered later in this document.
In principle, it is possible to carry LDP traffic in MRT IP tunnels. In principle, it is possible to carry LDP traffic in MRT IP tunnels.
However, for LDP traffic, it is very desirable to avoid tunneling. However, for LDP traffic, it is desirable to avoid tunneling.
Tunneling LDP traffic to a remote node requires knowledge of remote Tunneling LDP traffic to a remote node requires knowledge of remote
FEC-label bindings so that the LDP traffic can continue to be FEC-label bindings so that the LDP traffic can continue to be
forwarded properly when it leaves the tunnel. This requires targeted forwarded properly when it leaves the tunnel. This requires targeted
LDP sessions which can add management complexity. The two MRT LDP LDP sessions which can add management complexity. As described
Label forwarding mechanisms have the useful property that the FEC below, the two MRT forwarding mechanisms that use LDP labels do not
associated with the packet is maintained in the labels at each hop require targeted LDP sessions.
along the MRT, as long as an MRT to the originator of the FEC is
used. The MRT IP tunneling mechanism does not have this useful
property. Therefore, this document only considers the two MRT LDP
Label forwarding mechanisms for protecting LDP traffic with MRT fast-
reroute.
6.2.1. Forwarding LDP traffic using MRT LDP Labels (Option 1A) 6.2.1. Forwarding LDP traffic using MRT LDP Labels (Option 1A)
The MRT LDP Label option 1A forwarding mechanism uses topology-scoped The MRT LDP Label option 1A forwarding mechanism uses topology-scoped
FECs encoded using a single label as described in section FECs encoded using a single label as described in section
Section 6.1.1.1. When a PLR receives an LDP packet that needs to be Section 6.1.1.1. When a PLR receives an LDP packet that needs to be
forwarded on the Red MRT (for example), it does a label swap forwarded on the Red MRT (for example), it does a label swap
operation, replacing the usual LDP label for the FEC with the Red MRT operation, replacing the usual LDP label for the FEC with the Red MRT
label for that FEC received from the next-hop router in the Red MRT label for that FEC received from the next-hop router in the Red MRT
computed by the PLR. When the next-hop router in the Red MRT computed by the PLR. When the next-hop router in the Red MRT
skipping to change at page 15, line 43 skipping to change at page 15, line 31
label associated with the Red MRT, and forward the packet to the label associated with the Red MRT, and forward the packet to the
appropriate next-hop on the Red MRT. When the next-hop router in the appropriate next-hop on the Red MRT. When the next-hop router in the
Red MRT receives the packet with the Red MRT label for the FEC, the Red MRT receives the packet with the Red MRT label for the FEC, the
MRT transit forwarding functionality continues as described in MRT transit forwarding functionality continues as described in
Section 6.1.1.2. As with option 1A, the original FEC associated with Section 6.1.1.2. As with option 1A, the original FEC associated with
the packet is maintained at each hop along the MRT. the packet is maintained at each hop along the MRT.
6.2.3. Other considerations for forwarding LDP traffic using MRT LDP 6.2.3. Other considerations for forwarding LDP traffic using MRT LDP
Labels Labels
Note that forwarding LDP traffic using MRT LDP Labels requires that Note that forwarding LDP traffic using MRT LDP Labels can be done
an MRT to the originator of the FEC be used. For example, one might without the use of targeted LDP sessions when an MRT path to the
find it desirable to have the PLR use an MRT to reach the primary destination FEC is used. The alternates selected in
next-next-hop for the FEC, and then continue forwarding the LDP [I-D.ietf-rtgwg-mrt-frr-algorithm] use the MRT path to the
packet along the shortest path tree from the primary next-next-hop. destination FEC, so targeted LDP sessions are not needed. If instead
However, this would require tunneling to the primary next-next-hop one found it desirable to have the PLR use an MRT to reach the
and a targeted LDP session for the PLR to learn the FEC-label binding primary next-next-hop for the FEC, and then continue forwarding the
for primary next-next-hop to correctly forward the packet. LDP packet along the shortest path tree from the primary next-next-
hop, this would require tunneling to the primary next-next-hop and a
targeted LDP session for the PLR to learn the FEC-label binding for
primary next-next-hop to correctly forward the packet.
For greatest hardware compatibility, routers implementing MRT fast- For greatest hardware compatibility, routers implementing MRT fast-
reroute of LDP traffic MUST support Option 1A of encoding the MT-ID reroute of LDP traffic MUST support Option 1A of encoding the MT-ID
in the labels (See Section 9). in the labels (See Section 9).
6.3. Forwarding IP Unicast Traffic over MRT Paths 6.3. Forwarding IP Unicast Traffic over MRT Paths
For IP traffic, there is no currently practical alternative except For IPv4 traffic, there is no currently practical alternative except
tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red
forwarding topology. The choice of tunnel egress MAY be flexible forwarding topology. For IPv6 traffic, in principle one could define
since any router closer to the destination than the next-hop can bits in the IPv6 options header to indicate the MRT-Blue or MRT-Red
work. This architecture assumes that the original destination in the forwarding topology. However, in this document, we have chosen not
area is selected (see Section 11 for handling of multi-homed to define a solution that would work for IPv6 traffic but not for
prefixes); another possible choice is the next-next-hop towards the IPv4 traffic.
destination. As discussed in the previous section, for LDP traffic,
using the MRT to the original destination simplifies MRT-FRR by The choice of tunnel egress MAY be flexible since any router closer
avoiding the need for targeted LDP sessions to the next-next-hop. to the destination than the next-hop can work. This architecture
For IP, that consideration doesn't apply. However, consistency with assumes that the original destination in the area is selected (see
LDP is RECOMMENDED. Section 11 for handling of multi-homed prefixes); another possible
choice is the next-next-hop towards the destination. As discussed in
the previous section, for LDP traffic, using the MRT to the original
destination simplifies MRT-FRR by avoiding the need for targeted LDP
sessions to the next-next-hop. For IP, that consideration doesn't
apply. However, consistency with LDP is RECOMMENDED.
Some situations require tunneling IP traffic along an MRT to a tunnel Some situations require tunneling IP traffic along an MRT to a tunnel
endpoint that is not the destination of the IP traffic. These endpoint that is not the destination of the IP traffic. These
situations will be discussed in detail later. We note here that an situations will be discussed in detail later. We note here that an
IP packet with a destination in a different IGP area/level from the IP packet with a destination in a different IGP area/level from the
PLR should be tunneled on the MRT to the ABR/LBR on the shortest path PLR should be tunneled on the MRT to the ABR/LBR on the shortest path
to the destination. For a destination outside of the PLR's MRT to the destination. For a destination outside of the PLR's MRT
Island, the packet should be tunneled on the MRT to a non-proxy-node Island, the packet should be tunneled on the MRT to a non-proxy-node
immediately before the named proxy-node on that particular color MRT. immediately before the named proxy-node on that particular color MRT.
skipping to change at page 17, line 16 skipping to change at page 17, line 10
The MRT LDP Label option 1B forwarding mechanism encodes the topology The MRT LDP Label option 1B forwarding mechanism encodes the topology
and the FEC using a two label stack as described in Section 6.1.1.2. and the FEC using a two label stack as described in Section 6.1.1.2.
When a PLR receives an IP packet that needs to be forwarded on the When a PLR receives an IP packet that needs to be forwarded on the
Red MRT to a particular tunnel endpoint, the PLR pushes two labels on Red MRT to a particular tunnel endpoint, the PLR pushes two labels on
the IP packet. The first (inner) label is the normal LDP label the IP packet. The first (inner) label is the normal LDP label
learned from the next-hop on the Red MRT, associated with a FEC learned from the next-hop on the Red MRT, associated with a FEC
originated by the tunnel endpoint. The second (outer) label is the originated by the tunnel endpoint. The second (outer) label is the
topology-identification label associated with the Red MRT. topology-identification label associated with the Red MRT.
For completeness, we note here a potential optimization. In order to For completeness, we note here a potential variation that uses a
tunnel an IP packet over an MRT to the destination of the IP packet single label as opposed to two labels. In order to tunnel an IP
(as opposed to an arbitrary tunnel endpoint), then we could just push packet over an MRT to the destination of the IP packet (as opposed to
a topology-identification label directly onto the packet. An MRT an arbitrary tunnel endpoint), then we could just push a topology-
transit router would need to pop the topology-id label, do an IP identification label directly onto the packet. An MRT transit router
route lookup in the context of that topology-id , and push the would need to pop the topology-id label, do an IP route lookup in the
topology-id label. context of that topology-id , and push the topology-id label.
6.3.2. Tunneling IP traffic using MRT IP Tunnels 6.3.2. Tunneling IP traffic using MRT IP Tunnels
In order to tunnel over the MRT to a particular tunnel endpoint, the In order to tunnel over the MRT to a particular tunnel endpoint, the
PLR encapsulates the original IP packet with an additional IP header PLR encapsulates the original IP packet with an additional IP header
using the MRT-Blue or MRT-Red loopack address of the tunnel endpoint. using the MRT-Blue or MRT-Red loopack address of the tunnel endpoint.
6.3.3. Required support 6.3.3. Required support
For greatest hardware compatibility and ease in removing the MRT- For greatest hardware compatibility and ease in removing the MRT-
skipping to change at page 19, line 4 skipping to change at page 18, line 49
with a metric of 2^24-2 (0xFFFFFE) will only be used as a last with a metric of 2^24-2 (0xFFFFFE) will only be used as a last
resort. (An interface configured with a metric of 2^24-1 (0xFFFFFF) resort. (An interface configured with a metric of 2^24-1 (0xFFFFFF)
will not be advertised into the topology.) In OSPF, an interface will not be advertised into the topology.) In OSPF, an interface
configured with a metric of 2^16-1 (0xFFFF) will only be used as a configured with a metric of 2^16-1 (0xFFFF) will only be used as a
last resort. These metrics can be configured manually to enforce last resort. These metrics can be configured manually to enforce
administrative policy, or they can be set in an automated manner as administrative policy, or they can be set in an automated manner as
with LDP IGP synchronization [RFC5443]. with LDP IGP synchronization [RFC5443].
Mechanisms also exist in ISIS and OSPF to prevent transit traffic Mechanisms also exist in ISIS and OSPF to prevent transit traffic
from using a particular router. In ISIS, the overload bit is used from using a particular router. In ISIS, the overload bit is used
for this purpose. In OSPF, [RFC3137] specifies setting all outgoing for this purpose. In OSPF, [RFC6987] specifies setting all outgoing
interface metrics to 0xFFFF to accomplish this. interface metrics to 0xFFFF to accomplish this.
The following rules for MRT Island formation ensure that MRT FRR The following rules for MRT Island formation ensure that MRT FRR
protection traffic does not use a link or router that is discouraged protection traffic does not use a link or router that is discouraged
from carrying traffic by existing IGP mechanisms. from carrying traffic by existing IGP mechanisms.
1. A bidirectional link MUST be excluded from an MRT Island if 1. A bidirectional link MUST be excluded from an MRT Island if
either the forward or reverse cost on the link is 0xFFFFFE (for either the forward or reverse cost on the link is 0xFFFFFE (for
ISIS) or 0xFFFF for OSPF. ISIS) or 0xFFFF for OSPF.
skipping to change at page 19, line 41 skipping to change at page 19, line 39
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.
7.5. Example algorithm 7.5. Example algorithm
An algorithm that allows a computing router to identify the routers An algorithm that allows a computing router to identify the routers
and links in the local MRT Island satisfying the above rules is given and links in the local MRT Island satisfying the above rules is given
in section 5.1 of [I-D.ietf-rtgwg-mrt-frr-algorithm]. in section 5.2 of [I-D.ietf-rtgwg-mrt-frr-algorithm].
8. MRT Profile 8. MRT Profile
An MRT Profile is a set of values and options related to MRT An MRT Profile is a set of values and options related to MRT
behavior. The complete set of options is designated by the behavior. The complete set of options is designated by the
corresponding 8-bit Profile ID value. corresponding 8-bit Profile ID value.
This document specifies the values and options that correspond to the
Default MRT Profile (Profile ID = 0). Future documents may define
other MRT Profiles by specifying the MRT Profile Options below.
8.1. MRT Profile Options 8.1. MRT Profile Options
Below is a description of the values and options that define an MRT Below is a description of the values and options that define an MRT
Profile. Profile.
MRT Algorithm: This identifies the particular MRT algorithm used by MRT Algorithm: This identifies the particular MRT algorithm used by
the router for this profile. Algorithm transitions can be managed the router for this profile. Algorithm transitions can be managed
by advertising multiple MRT profiles. by advertising multiple MRT profiles.
MRT-Red MT-ID: This specifies the MT-ID to be associated with the MRT-Red MT-ID: This specifies the MT-ID to be associated with the
skipping to change at page 20, line 44 skipping to change at page 20, line 44
program appropriate next-hops into the forwarding plane. The program appropriate next-hops into the forwarding plane. The
current options are MRT LDP Labels, IPv4 Tunneling, IPv6 current options are MRT LDP Labels, IPv4 Tunneling, IPv6
Tunneling, and None. If the MRT LDP Labels option is supported, Tunneling, and None. If the MRT LDP Labels option is supported,
then option 1A and the appropriate signaling extensions MUST be then option 1A and the appropriate signaling extensions MUST be
supported. If IPv4 is supported, then both MRT-Red and MRT-Blue supported. If IPv4 is supported, then both MRT-Red and MRT-Blue
IPv4 Loopback Addresses SHOULD be specified. If IPv6 is IPv4 Loopback Addresses SHOULD be specified. If IPv6 is
supported, both MRT-Red and MRT-Blue IPv6 Loopback Addresses supported, both MRT-Red and MRT-Blue IPv6 Loopback Addresses
SHOULD be specified. The None option in may be useful for SHOULD be specified. The None option in may be useful for
multicast global protection. multicast global protection.
Recalculation: As part of what process and timing should the new Recalculation: Recalculation specifies the process and timing by
MRTs be computed on a modified topology? Section 12.2 describes which new MRTs are computed after the topology has been modified.
the minimum behavior required to support fast-reroute.
Area/Level Border Behavior: Should inter-area traffic on the MRT- Area/Level Border Behavior: Should inter-area traffic on the MRT-
Blue or MRT-Red be put back onto the shortest path tree? Should Blue or MRT-Red be put back onto the shortest path tree? Should
it be swapped from MRT-Blue or MRT-Red in one area/level to MRT- it be swapped from MRT-Blue or MRT-Red in one area/level to MRT-
Red or MRT-Blue in the next area/level to avoid the potential Red or MRT-Blue in the next area/level to avoid the potential
failure of an ABR? (See [I-D.atlas-rtgwg-mrt-mc-arch] for use- failure of an ABR? (See [I-D.atlas-rtgwg-mrt-mc-arch] for use-
case details. case details.
Other Profile-Specific Behavior: Depending upon the use-case for Other Profile-Specific Behavior: Depending upon the use-case for
the profile, there may be additional profile-specific behavior. the profile, there may be additional profile-specific behavior.
skipping to change at page 22, line 47 skipping to change at page 22, line 44
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 to
same FEC. Because the Rainbow MRT MT-ID is used only by ABRs/LBRs or different LDP neighbors for the same FEC. Because the Rainbow MRT
an LDP egress router, it is not MRT profile specific. MT-ID is used only by ABRs/LBRs or an LDP egress router, it is not
MRT profile specific.
[I-D.ietf-mpls-ldp-mrt] contains the IANA request for the Rainbow MRT [I-D.ietf-mpls-ldp-mrt] contains the IANA request for the Rainbow MRT
MPLS MT-ID. MPLS 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.
skipping to change at page 30, line 22 skipping to change at page 30, line 22
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
example, how OSPFv2 [[RFC2328] Section 16.5] does incremental updates example, how OSPFv2 (see [RFC2328] Section 16.5) does incremental
for new summary-LSAs. updates for new summary-LSAs.
The key question is how to attach the named proxy-node to the MRT The remaining question is how to attach the named proxy-node to the
Island; all the routers in the MRT Island MUST do this consistently. MRT Island; all the routers in the MRT Island MUST do this
No more than 2 routers in the MRT Island can be selected; one should consistently. No more than 2 routers in the MRT Island can be
only be selected if there are no others that meet the necessary selected; one should only be selected if there are no others that
criteria. The named proxy-node is logically part of the area/level. meet the necessary criteria. The named proxy-node is logically part
of the area/level.
There are two sources for candidate routers in the MRT Island to There are two sources for candidate routers in the MRT Island to
connect to the named proxy-node. The first set are those routers connect to the named proxy-node. The first set are those routers in
that are advertising the prefix; the named-proxy-cost assigned to the MRT Island that are advertising the prefix; the named-proxy-cost
each prefix-advertising router is the announced cost to the prefix. assigned to each prefix-advertising router is the announced cost to
The second set are those routers in the MRT Island that are connected the prefix. The second set are those routers in the MRT Island that
to routers not in the MRT Island but in the same area/level; such are connected to routers not in the MRT Island but in the same area/
routers will be defined as Island Border Routers (IBRs). The routers level; such routers will be defined as Island Border Routers (IBRs).
connected to the IBRs that are not in the MRT Island and are in the The routers connected to the IBRs that are not in the MRT Island and
same area/level as the MRT island are Island Neighbors(INs). are in the same area/level as the MRT island are Island
Neighbors(INs).
Since packets sent to the named proxy-node along MRT-Red or MRT-Blue Since packets sent to the named proxy-node along MRT-Red or MRT-Blue
may come from any router inside the MRT Island, it is necessary that may come from any router inside the MRT Island, it is necessary that
whatever router to which an IBR forwards the packet be loop-free with whatever router to which an IBR forwards the packet be loop-free with
respect to the whole MRT Island for the destination. Thus, an IBR is respect to the whole MRT Island for the destination. Thus, an IBR is
a candidate router only if it possesses at least one IN whose a candidate router only if it possesses at least one IN whose
shortest path to the prefix does not enter the MRT Island. A method shortest path to the prefix does not enter the MRT Island. A method
for identifying loop-free Island Neighbors(LFINs) is discussed below. for identifying loop-free Island Neighbors(LFINs) is given in
The named-proxy-cost assigned to each (IBR, IN) pair is cost(IBR, IN) [I-D.ietf-rtgwg-mrt-frr-algorithm]. The named-proxy-cost assigned to
+ D_opt(IN, prefix). each (IBR, IN) pair is cost(IBR, IN) + D_opt(IN, prefix).
From the set of prefix-advertising routers and the set of IBRs with From the set of prefix-advertising routers and the set of IBRs with
at least one LFIN, the two routers with the lowest named-proxy-cost at least one LFIN, the two routers with the lowest named-proxy-cost
are selected. Ties are broken based upon the lowest Router ID. For are selected. Ties are broken based upon the lowest Router ID. For
ease of discussion, the two selected routers will be referred to as ease of discussion, the two selected routers will be referred to as
proxy-node attachment routers. proxy-node attachment routers.
A proxy-node attachment router has a special forwarding role. When a A proxy-node attachment router has a special forwarding role. When a
packet is received destined to (MRT-Red, prefix) or (MRT-Blue, packet is received destined to (MRT-Red, prefix) or (MRT-Blue,
prefix), if the proxy-node attachment router is an IBR, it MUST swap prefix), if the proxy-node attachment router is an IBR, it MUST swap
to the shortest path forwarding topology (e.g. swap to the label for to the shortest path forwarding topology (e.g. swap to the label for
(MT-ID 0, prefix) or remove the outer IP encapsulation) and forward (MT-ID 0, prefix) or remove the outer IP encapsulation) and forward
the packet to the IN whose cost was used in the selection. If the the packet to the IN whose cost was used in the selection. If the
proxy-node attachment router is not an IBR, then the packet MUST be proxy-node attachment router is not an IBR, then the packet MUST be
removed from the MRT forwarding topology and sent along the removed from the MRT forwarding topology and sent along the
interface(s) that caused the router to advertise the prefix; this interface(s) that caused the router to advertise the prefix; this
interface might be out of the area/level/AS. interface might be out of the area/level/AS.
11.2.1. Computing if an Island Neighbor (IN) is loop-free
As discussed above, the Island Neighbor needs to be loop-free with
respect to the whole MRT Island for the destination. This can be
accomplished by running the usual SPF algorithm while keeping track
of which shortest paths have passed through the MRT island. Pseudo-
code for this is shown in Figure 4. The Island_Marking_SPF() is run
for each IN that needs to be evaluated for the loop-free condition,
with the IN as the spf_root. Whether or not an IN is loop-free with
respect to the MRT island can then be determined by evaluating
node.PATH_HITS_ISLAND for each destination of interest.
Island_Marking_SPF(spf_root)
Initialize spf_heap to empty
Initialize nodes' spf_metric to infinity and next_hops to empty
and PATH_HITS_ISLAND to false
spf_root.spf_metric = 0
insert(spf_heap, spf_root)
while (spf_heap is not empty)
min_node = remove_lowest(spf_heap)
foreach interface intf of min_node
path_metric = min_node.spf_metric + intf.metric
if path_metric < intf.remote_node.spf_metric
intf.remote_node.spf_metric = path_metric
if min_node is spf_root
intf.remote_node.next_hops = make_list(intf)
else
intf.remote_node.next_hops = min_node.next_hops
if intf.remote_node.IN_MRT_ISLAND
intf.remote_node.PATH_HITS_ISLAND = true
else
intf.remote_node.PATH_HITS_ISLAND =
min_node.PATH_HITS_ISLAND
insert_or_update(spf_heap, intf.remote_node)
else if path_metric == intf.remote_node.spf_metric
if min_node is spf_root
add_to_list(intf.remote_node.next_hops, intf)
else
add_list_to_list(intf.remote_node.next_hops,
min_node.next_hops)
if intf.remote_node.IN_MRT_ISLAND
intf.remote_node.PATH_HITS_ISLAND = true
else
intf.remote_node.PATH_HITS_ISLAND =
min_node.PATH_HITS_ISLAND
Figure 4
It is also possible that a given prefix is originated by a
combination of non-island routers and island routers. The results of
the Island_Marking_SPF computation can be used to determine if the
shortest path from an IN to reach that prefix hits the MRT island.
The shortest path for the IN to reach prefix P is determined by the
total cost to reach prefix P, which is the sum of the cost for the IN
to reach a prefix-advertising node and the cost with which that node
advertises the prefix. The path with the minimum total cost to
prefix P is chosen. If the prefix-advertising node for that minimum
total cost path has PATH_HITS_ISLAND set to True, then the IN is not
loop-free with respect to the MRT Island for reaching prefix P. If
there multiple minimum total cost paths to reach prefix P, then all
of the prefix-advertising routers involved in the minimum total cost
paths MUST have PATH_HITS_ISLAND set to False for the IN to be
considered loop-free to reach P.
Note that there are other computations that could be used to
determine if paths from a given IN _might_ pass through the MRT
Island for a given prefix or destination. For example, a previous
version of this draft specified running the SPF algorithm on modified
topology which treats the MRT island as a single node (with intra-
island links set to zero cost) in order to provide input to
computations to determine if the path from IN to non-island
destination hits the MRT island in this modified topology. This
computation is enough to guarantee that a path will not hit the MRT
island in the original topology. However, it is possible that a path
which is disqualified for hitting the MRT island in the modified
topology will not actually hit the MRT Island in the original
topology. The algorithm described in Island_Marking_SPF() above does
not modify the original topology, and will only disqualify a path if
the actual path does in fact hit the MRT island.
Since all routers need to come to the same conclusion about which
routers qualify as LFINs, this specification requires that all
routers computing LFINs MUST use an algorithm whose result is
identical to that of the Island_Marking_SPF() in Figure 4.
11.3. MRT Alternates for Destinations Outside the MRT Island 11.3. MRT Alternates for Destinations Outside the MRT Island
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.
skipping to change at page 34, line 21 skipping to change at page 32, line 13
prevention and MRT re-calculation. prevention and MRT re-calculation.
12.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 mechanisms discussed in There are two possible micro-loop prevention mechanisms discussed in
[RFC5715]. The first is Ordered FIB [I-D.ietf-rtgwg-ordered-fib]. [RFC5715]. The first is Ordered FIB [RFC6976]. The second is
The second is Farside Tunneling which requires tunnels or an Farside Tunneling which requires tunnels or an alternate topology to
alternate topology to reach routers on the farside of the failure. 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 the scope of this document. Details of how to do so are outside the scope of this document.
Micro-loop mitigation mechanisms can also work when combined with Micro-loop mitigation mechanisms can also work when combined with
MRT. MRT.
12.2. MRT Recalculation 12.2. MRT Recalculation for the Default MRT Profile
This section describes how the MRT recalculation SHOULD be performed
for the Default MRT Profile. This is intended to support FRR
applications. Other approaches are possible, but they are not
specified in this document.
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 37, line 5 skipping to change at page 34, line 47
o Licensing: proprietary o Licensing: proprietary
o Implementation experience: It is important produce a second o Implementation experience: It is important produce a second
implementation to verify the algorithm is implemented correctly implementation to verify the algorithm is implemented correctly
without looping. It is important to verify the ISIS extensions without looping. It is important to verify the ISIS extensions
work for MRT-FRR. work for MRT-FRR.
o Contact information: lizhenbin@huawei.com, eric.wu@huawei.com o Contact information: lizhenbin@huawei.com, eric.wu@huawei.com
14. Acknowledgements 14. Operations and Management Considerations
An implementation SHOULD provide an operator with the ability to test
MRT paths with OAM traffic. For example, when MRT paths are realized
using LDP labels distributed for topology-scoped FECs, an
implementation can use the MPLS ping and traceroute as defined in
[RFC4379] and extended in [RFC7307] for topology-scoped FECs.
15. Applying Policy to Select from Multiple Possible Alternates for FRR
For a given topology, GADAG root, and profile, MRT will provide a
node-protecting alternate path from each PLR to each destination for
any single link or node failure, if such a path exists. Therefore,
an implementation may choose to only use the alternates determined by
MRT to provide 100% FRR coverage.
However, it may be desirable to allow an operator to use MRT
alternates together with alternates provided by other FRR
technologies. A policy-based alternate selection process can allow
an operator to select the best alternate from those provided by MRT
and other FRR technologies. As an example, it may be desirable to
implement a policy where a node-protecting LFA (if it exists for a
given failure mode and destination) is preferred over a given MRT
alternate. [I-D.ietf-rtgwg-lfa-manageability] discusses many of the
potential criteria that one might take into account when evaluating
different alternates for selection.
Note that future documents may define MRT profiles in addition to the
default profile defined here. Different MRT profiles will generally
produce alternate paths with different properties. An implementation
may allow an operator to use different MRT profiles instead of or in
addition to the default profile.
16. 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, Raveendra Torvi, Anil Kumar SN, Bruno Bahadur, Harish Sitaraman, Raveendra Torvi, Anil Kumar SN, Bruno
Decraene, Eric Wu, and Janos Farkas for their suggestions and review. Decraene, Eric Wu, and Janos Farkas for their suggestions and review.
15. IANA Considerations 17. 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.
16. Security Considerations 18. Security Considerations
This architecture is not currently believed to introduce new security In general, MRT forwarding paths do not follow shortest paths. The
concerns. transit forwarding state corresponding to the MRT paths is created
during normal operations (before a failure occurs). Therefore, a
malicious packet with an appropriate header injected into the network
from a compromised location would be forwarded to a destination along
a non-shortest path. When this technology is deployed, a network
security design should not rely on assumptions about potentially
malicious traffic only following shortest paths.
17. References It should be noted that the creation of non-shortest forwarding paths
is not unique to MRT.
17.1. Normative References 19. Contributors
Robert Kebler
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rkebler@juniper.net
Andras Csaszar
Ericsson
Konyves Kalman krt 11
Budapest 1097
Hungary
Email: Andras.Csaszar@ericsson.com
Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
USA
Email: jeff.tantsura@ericsson.com
Russ White
VCE
Email: russw@riw.us
20. References
20.1. Normative References
[I-D.ietf-rtgwg-mrt-frr-algorithm] [I-D.ietf-rtgwg-mrt-frr-algorithm]
Envedi, 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-ietf-rtgwg-mrt-frr- Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
algorithm-05 (work in progress), July 2015. algorithm-06 (work in progress), October 2015.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<http://www.rfc-editor.org/info/rfc5286>. <http://www.rfc-editor.org/info/rfc5286>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 20.2. Informative References
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<http://www.rfc-editor.org/info/rfc5714>.
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-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] [I-D.francois-rtgwg-segment-routing-ti-lfa]
Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,
"Topology Independent Fast Reroute using Segment Routing", "Topology Independent Fast Reroute using Segment Routing",
draft-francois-spring-segment-routing-ti-lfa-01 (work in draft-francois-rtgwg-segment-routing-ti-lfa-00 (work in
progress), October 2014. progress), August 2015.
[I-D.ietf-isis-mrt] [I-D.ietf-isis-mrt]
Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J. Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J.
Tantsura, "Intermediate System to Intermediate System (IS- Tantsura, "Intermediate System to Intermediate System (IS-
IS) Extensions for Maximally Redundant Trees (MRT)", IS) Extensions for Maximally Redundant Trees (MRT)",
draft-ietf-isis-mrt-00 (work in progress), February 2015. draft-ietf-isis-mrt-01 (work in progress), October 2015.
[I-D.ietf-mpls-ldp-mrt] [I-D.ietf-mpls-ldp-mrt]
Atlas, A., Tiruveedhula, K., Bowers, C., Tantsura, J., and Atlas, A., Tiruveedhula, K., Bowers, C., Tantsura, J., and
I. Wijnands, "LDP Extensions to Support Maximally I. Wijnands, "LDP Extensions to Support Maximally
Redundant Trees", draft-ietf-mpls-ldp-mrt-00 (work in Redundant Trees", draft-ietf-mpls-ldp-mrt-02 (work in
progress), January 2015. progress), September 2015.
[I-D.ietf-ospf-mrt] [I-D.ietf-ospf-mrt]
Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
"OSPF Extensions to Support Maximally Redundant Trees", "OSPF Extensions to Support Maximally Redundant Trees",
draft-ietf-ospf-mrt-00 (work in progress), January 2015. draft-ietf-ospf-mrt-01 (work in progress), October 2015.
[I-D.ietf-rtgwg-ipfrr-notvia-addresses]
Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
and MPLS Fast Reroute Using Not-via Addresses", draft-
ietf-rtgwg-ipfrr-notvia-addresses-11 (work in progress),
May 2013.
[I-D.ietf-rtgwg-ordered-fib] [I-D.ietf-rtgwg-lfa-manageability]
Shand, M., Bryant, S., Previdi, S., Filsfils, C., Litkowski, S., Decraene, B., Filsfils, C., Raza, K.,
Francois, P., and O. Bonaventure, "Framework for Loop-free Horneffer, M., and P. Sarkar, "Operational management of
convergence using oFIB", draft-ietf-rtgwg-ordered-fib-12 Loop Free Alternates", draft-ietf-rtgwg-lfa-
(work in progress), May 2013. manageability-11 (work in progress), June 2015.
[I-D.ietf-rtgwg-rlfa-node-protection] [I-D.ietf-rtgwg-rlfa-node-protection]
Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, Sarkar, P., Hegde, S., Bowers, C., Gredler, H., and S.
S., and H. Raghuveer, "Remote-LFA Node Protection and Litkowski, "Remote-LFA Node Protection and Manageability",
Manageability", draft-ietf-rtgwg-rlfa-node-protection-02 draft-ietf-rtgwg-rlfa-node-protection-05 (work in
(work in progress), June 2015. progress), December 2015.
[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 39 skipping to change at page 38, line 44
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
McPherson, "OSPF Stub Router Advertisement", RFC 3137, Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC3137, June 2001, DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc3137>. <http://www.rfc-editor.org/info/rfc4379>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<http://www.rfc-editor.org/info/rfc5331>.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, DOI 10.17487/RFC5443, March Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
2009, <http://www.rfc-editor.org/info/rfc5443>. 2009, <http://www.rfc-editor.org/info/rfc5443>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<http://www.rfc-editor.org/info/rfc5714>.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <http://www.rfc-editor.org/info/rfc5715>. 2010, <http://www.rfc-editor.org/info/rfc5715>.
[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene,
B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free B., 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, DOI 10.17487/RFC6571, June 2012, Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012,
<http://www.rfc-editor.org/info/rfc6571>. <http://www.rfc-editor.org/info/rfc6571>.
[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
Francois, P., and O. Bonaventure, "Framework for Loop-Free
Convergence Using the Ordered Forwarding Information Base
(oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July
2013, <http://www.rfc-editor.org/info/rfc6976>.
[RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981,
DOI 10.17487/RFC6981, August 2013,
<http://www.rfc-editor.org/info/rfc6981>.
[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, Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 6987,
DOI 10.17487/RFC6987, September 2013,
<http://www.rfc-editor.org/info/rfc6987>.
[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi-Topology", RFC 7307, King, "LDP Extensions for Multi-Topology", RFC 7307,
DOI 10.17487/RFC7307, July 2014, DOI 10.17487/RFC7307, July 2014,
<http://www.rfc-editor.org/info/rfc7307>. <http://www.rfc-editor.org/info/rfc7307>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<http://www.rfc-editor.org/info/rfc7490>. <http://www.rfc-editor.org/info/rfc7490>.
skipping to change at page 40, line 41 skipping to change at page 40, line 20
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
| | | |
| | Area 20: A, ASBR X | | Area 20: A, ASBR X
| | | |
p ---[ASBR X]---[A]---[ABR 1]---[D] Area 10: B, ASBR Y p ---[ASBR X]---[A]---[ABR 1]---[D] Area 10: B, ASBR Y
5 p is a Type 1 AS-external 5 p is a Type 1 AS-external
Figure 5: AS external prefixes in different areas Figure 4: AS external prefixes in different areas
Consider the network in Figure 5 and assume there is a richer Consider the network in Figure 4 and assume there is a richer
connective topology that isn't shown, where the same prefix is connective topology that isn't shown, where the same prefix is
announced by ASBR X and ASBR Y which are in different non-backbone announced by ASBR X and ASBR Y which are in different non-backbone
areas. If the link from A to ASBR X fails, then an MRT alternate areas. If the link from A to ASBR X fails, then an MRT alternate
could forward the packet to ABR 1 and ABR 1 could forward it to D, could forward the packet to ABR 1 and ABR 1 could forward it to D,
but then D would find the shortest route is back via ABR 1 to Area but then D would find the shortest route is back via ABR 1 to Area
20. This problem occurs because the routers, including the ABR, in 20. This problem occurs because the routers, including the ABR, in
one area are not yet aware of the failure in a different area. one area are not yet aware of the failure in a different area.
The only way to get it from A to ASBR Y is to explicitly tunnel it to The only way to get it from A to ASBR Y is to explicitly tunnel it to
ASBR Y. If the traffic is unlabeled or the appropriate MPLS labels ASBR Y. If the traffic is unlabeled or the appropriate MPLS labels
are known, then explicit tunneling MAY be used as long as the are known, then explicit tunneling MAY be used as long as the
shortest-path of the tunnel avoids the failure point. In that case, shortest-path of the tunnel avoids the failure point. In that case,
A must determine that it should use an explicit tunnel instead of an A must determine that it should use an explicit tunnel instead of an
MRT alternate. MRT alternate.
Authors' Addresses Authors' Addresses
Alia Atlas (editor) Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
Robert Kebler
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rkebler@juniper.net
Chris Bowers Chris Bowers
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: cbowers@juniper.net Email: cbowers@juniper.net
Gabor Sandor Enyedi Gabor Sandor Enyedi
Ericsson Ericsson
Konyves Kalman krt 11. Konyves Kalman krt 11.
Budapest 1097 Budapest 1097
Hungary Hungary
Email: Gabor.Sandor.Enyedi@ericsson.com Email: Gabor.Sandor.Enyedi@ericsson.com
Andras Csaszar
Ericsson
Konyves Kalman krt 11
Budapest 1097
Hungary
Email: Andras.Csaszar@ericsson.com
Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
USA
Email: jeff.tantsura@ericsson.com
Russ White
VCE
Email: russw@riw.us
 End of changes. 68 change blocks. 
280 lines changed or deleted 280 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/