One document matched: draft-ietf-rtgwg-mrt-frr-architecture-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC3137 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3137.xml">
<!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY RFC5443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5443.xml">
<!ENTITY RFC5714 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5714.xml">
<!ENTITY RFC5715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5715.xml">
<!ENTITY RFC6571 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6571.xml">
<!ENTITY I-D.ietf-mpls-ldp-multi-topology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-multi-topology.xml">
<!ENTITY I-D.ietf-rtgwg-ipfrr-notvia-addresses SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-ipfrr-notvia-addresses.xml">
<!ENTITY I-D.ietf-rtgwg-ordered-fib SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-ordered-fib.xml">
<!ENTITY I-D.ietf-rtgwg-remote-lfa SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-remote-lfa.xml">
<!ENTITY I-D.bryant-ipfrr-tunnels SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryant-ipfrr-tunnels.xml">
<!ENTITY I-D.litkowski-rtgwg-node-protect-remote-lfa SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.litkowski-rtgwg-node-protect-remote-lfa.xml">
<!ENTITY I-D.enyedi-rtgwg-mrt-frr-algorithm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.enyedi-rtgwg-mrt-frr-algorithm.xml">
<!ENTITY I-D.atlas-rtgwg-mrt-mc-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-rtgwg-mrt-mc-arch.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-rtgwg-mrt-frr-architecture-03" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="MRT Unicast FRR Architecture">An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alia Atlas" initials="A.K.A." role="editor" surname="Atlas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>akatlas@juniper.net</email>
</address>
</author>
<author fullname="Robert Kebler" initials="R.K." surname="Kebler">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>rkebler@juniper.net</email>
</address>
</author>
<author fullname="Gábor Sándor Enyedi" initials="G.S.E." surname="Enyedi">
<organization>Ericsson</organization>
<address>
<postal>
<street>Konyves Kalman krt 11.</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1097</code>
</postal>
<email>Gabor.Sandor.Enyedi@ericsson.com</email>
</address>
</author>
<author fullname="András Császár" initials="A.C." surname="Császár">
<organization>Ericsson</organization>
<address>
<postal>
<street>Konyves Kalman krt 11</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1097</code>
</postal>
<email>Andras.Csaszar@ericsson.com</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>jeff.tantsura@ericsson.com</email>
</address>
</author>
<author fullname="Maciek Konstantynowicz" initials="M.K." surname="Konstantynowicz">
<organization>Cisco Systems</organization>
<address>
<email>maciek@bgp.nu</email>
</address>
</author>
<author fullname="Russ White" initials="R.W." surname="White">
<organization>VCE</organization>
<address>
<email>russw@riw.us</email>
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<abstract>
<t>With increasing deployment of Loop-Free Alternates (LFA)
<xref target="RFC5286"/>, it is clear that a complete solution
for IP and LDP Fast-Reroute is 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
network topology that is still connected after the failure.</t>
<t>MRT removes all need to engineer for coverage. MRT is also
extremely computationally efficient. For any router in the
network, the MRT computation is less than the LFA computation
for a node with three or more neighbors.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document gives a complete solution for IP/LDP
fast-reroute <xref target="RFC5714"/>. MRT-FRR creates two
alternate trees separate from the primary next-hop forwarding
used during stable operation. These two trees are maximally
diverse from each other, providing link and node protection for
100% of paths and failures as long as the failure does not cut
the network into multiple pieces. This document defines the
architecture for IP/LDP fast-reroute with MRT. The associated
protocol extensions are defined in <xref
target="I-D.atlas-ospf-mrt"/> and <xref
target="I-D.atlas-mpls-ldp-mrt"/>. The exact MRT algorithm is
defined in <xref
target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>.</t>
<t>IP/LDP Fast-Reroute with MRT (MRT-FRR) uses two maximally
diverse forwarding topologies to provide alternates. A primary
next-hop should be on only one of the diverse forwarding
topologies; thus, the 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. 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. link).</t>
<t>In addition to supporting IP and LDP unicast fast-reroute, the
diverse forwarding topologies and guarantee of 100% coverage
permit fast-reroute technology to be applied to multicast traffic
as described in <xref target="I-D.atlas-rtgwg-mrt-mc-arch"/>.</t>
<t>Other existing or proposed solutions are partial solutions
or have significant issues, as described below.</t>
<texttable anchor="table_comparison">
<preamble>Summary Comparison of IP/LDP FRR Methods</preamble>
<ttcol align='center'>Method</ttcol>
<ttcol align='center'>Coverage</ttcol>
<ttcol align='center'>Alternate Looping?</ttcol>
<ttcol align='center'>Computation (in SPFs)</ttcol>
<c>MRT-FRR</c><c>100% Link/Node</c> <c>None</c> <c> less than 3</c>
<c/><c/><c/><c/>
<c>LFA</c> <c>Partial Link/Node</c> <c>Possible</c> <c>per neighbor</c>
<c/><c/><c/><c/>
<c>Remote LFA</c> <c>Partial Link/Node</c> <c> Possible</c>
<c> per neighbor (link) or neighbor's neighbor (node) </c>
<c/><c/><c/><c/>
<c>Not-Via</c><c>100% Link/Node</c> <c>None</c> <c>per link and node</c>
</texttable>
<t><list style="hanging">
<t hangText="Loop-Free Alternates (LFA): "> LFAs <xref
target="RFC5286"/> provide limited topology-dependent coverage
for link and node protection. Restrictions on choice of
alternates can be relaxed to improve coverage, but this can
cause forwarding loops if a worse failure is experienced than
protected against. Augmenting a network to provide better
coverage is NP-hard <xref target="LFARevisited"/>. <xref
target="RFC6571"/> discusses the applicability of LFA to
different topologies with a focus on common PoP
architectures.</t>
<t hangText="Remote LFA: " > Remote LFAs <xref
target="I-D.ietf-rtgwg-remote-lfa"/> improve coverage over
LFAs for link protection but still cannot guarantee complete
coverage. The trade-off of looping traffic to improve
coverage is still made. Remote LFAs can provide
node-protection <xref
target="I-D.litkowski-rtgwg-node-protect-remote-lfa"/> but not
guaranteed coverage and the computation required is quite high
(an SPF per neighbor's neighbor). <xref
target="I-D.bryant-ipfrr-tunnels"/> describes additional
mechanisms to further improve coverage, at the cost of added
complexity.</t>
<t hangText="Not-Via: ">Not-Via <xref
target="I-D.ietf-rtgwg-ipfrr-notvia-addresses"/> is the only
other solution that provides 100% coverage for link and node
failures and does not have potential looping. However, the
computation is very high (an SPF per failure point) and
academic implementations <xref target="LightweightNotVia"/>
have found the address management complexity to be high.</t>
</list></t>
<section title="Importance of 100% Coverage">
<t>Fast-reroute is based upon the single failure assumption - that the
time between single failures is long enough for a network to
reconverge and start forwarding on the new shortest paths. That does
not imply that the network will only experience one failure or change.</t>
<t>It is straightforward to analyze a particular network topology for
coverage. However, a real network does not always have the same
topology. For instance, maintenance events will take links or nodes
out of use. Simply costing out a link can have a significant effect
on what LFAs are available. Similarly, after a single failure has
happened, the topology is changed and its associated coverage.
Finally, many networks have new routers or links added and removed;
each of those changes can have an effect on the coverage for
topology-sensitive methods such as LFA and Remote LFA. If
fast-reroute is important for the network services provided, then a
method that guarantees 100% coverage is important to accomodate
natural network topology changes.</t>
<t>Asymmetric link costs are also a common aspect of networks. There
are at least three common causes for them. First, any broadcast
interface is represented by a pseudo-node and has asymmetric link
costs to and from that pseudo-node. Second, when routers come up or a
link with LDP comes up, it is recommended in <xref target="RFC5443"/>
and <xref target="RFC3137"/> that the link metric be raised to the
maximum cost; this may not be symmetric and for <xref
target="RFC3137"/> is not expected to be. Third, techniques such as
IGP metric tuning for traffic-engineering can result in asymmetric
link costs. A fast-reroute solution needs to handle network
topologies with asymmetric link costs.</t>
<t>When a network needs to use a micro-loop prevention mechanism <xref
target="RFC5715"/> such as Ordered FIB<xref
target="I-D.ietf-rtgwg-ordered-fib"/> or Farside Tunneling<xref
target="RFC5715"/>, then the whole IGP area needs to have alternates
available so that the micro-loop prevention mechanism, which requires
slower network convergence, can take the necessary time without
impacting traffic badly. Without complete coverage, traffic to the
unprotected destinations will be dropped for significantly longer than
with current convergence - where routers individually converge as fast
as possible.</t>
</section>
<section title="Partial Deployment and Backwards Compatibility">
<t>MRT-FRR supports partial deployment. As with many new features,
the protocols (OSPF, LDP, ISIS) indicate their capability to support
MRT. Inside the MRT-capable connected group of routers (referred to
as an MRT Island), the MRTs are computed. Alternates to destinations
outside the MRT Island are computed and depend upon the existence of a
loop-free neighbor of the MRT Island for that destination.</t>
</section>
</section><!-- End of Introduction !-->
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/></t>
</section>
<section title="Terminology">
<t><list style="hanging">
<t hangText="network graph: ">A graph that reflects the network
topology where all links connect exactly two nodes and broadcast
links have been transformed into the standard pseudo-node
representation.</t>
<t hangText="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 path from the same node X to the root
along the second tree. These can be computed in 2-connected
graphs.</t>
<t hangText="Maximally Redundant Trees (MRT): ">A pair of trees
where the path from any node X to the root R along the first tree
and the path from the same node X to the root along the second
tree share the minimum number of nodes and the minimum number of
links. Each such shared node is a cut-vertex. Any shared links
are cut-links. Any RT is an MRT but many MRTs are not RTs.</t>
<t hangText="MRT-Red: "> MRT-Red is used to describe one of the
two MRTs; it is used to described the associated forwarding
topology and MT-ID. Specifically, MRT-Red is the decreasing MRT
where links in the GADAG are taken in the direction from a higher
topologically ordered node to a lower one.</t>
<t hangText="MRT-Blue: "> MRT-Blue is used to describe one of the
two MRTs; it is used to described the associated forwarding
topology and MT-ID. Specifically, MRT-Blue is the increasing MRT
where links in the GADAG are taken in the direction from a lower
topologically ordered node to a higher one.</t>
<t hangText="Rainbow MRT: "> It is useful to have an MT-ID that
refers to the multiple MRT topologies and to the default
topology. This is referred to as the Rainbow MRT MT-ID and is
used by LDP to reduce signaling and permit the same label to
always be advertised to all peers for the same (MT-ID, Prefix).</t>
<t hangText="MRT Island: "> From the computing router, the set of
routers that support a particular MRT profile and are connected.</t>
<t hangText="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 in a common area or level.</t>
<t hangText="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.</t>
<t hangText="cut-link: ">A link whose removal partitions the
network. A cut-link by definition must be connected between two
cut-vertices. If there are multiple parallel links, then they
are referred to as cut-links in this document if removing the set
of parallel links would partition the network graph. </t>
<t hangText="cut-vertex: ">A vertex whose removal partitions the
network graph.</t>
<t hangText="2-connected: ">A graph that has no cut-vertices.
This is a graph that requires two nodes to be removed before the
network is partitioned.</t>
<t hangText="2-connected cluster: ">A maximal set of nodes that
are 2-connected.</t>
<t hangText="2-edge-connected: ">A network graph where at least
two links must be removed to partition the network.</t>
<t hangText="block: ">Either a 2-connected cluster, a cut-edge,
or an isolated vertex.</t>
<t hangText="DAG: ">Directed Acyclic Graph - a graph where all
links are directed and there are no cycles in it.</t>
<t hangText="ADAG: ">Almost Directed Acyclic Graph - a graph
that, if all links incoming to the root were removed, would be a
DAG.</t>
<t hangText="GADAG: ">Generalized ADAG - a graph that is
the combination of the ADAGs of all blocks.</t>
<t hangText="named proxy-node: ">A proxy-node can represent a
destination prefix that can be attached to the MRT Island via at
least two routers. It is named if there is a way that traffic
can be encapsulated to reach specifically that proxy node; this
could be because there is an LDP FEC for the associated prefix or
because MRT-Red and MRT-Blue IP addresses are advertised in an
undefined fashion for that proxy-node.</t>
</list></t>
</section>
<section title="Maximally Redundant Trees (MRT)">
<t>A pair of Maximally Redundant Trees are directed spanning trees
that provide maximally disjoint paths towards their common root. Only
links or nodes whose failure would partition the network
(i.e. cut-links and cut-vertices) are shared between the trees. The
algorithm to compute MRTs is given in <xref
target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>. This algorithm can be
computed in O(e + n log n); it is less than three SPFs. Modeling
results comparing MRT alternates to the optimal are described in <xref
target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>. This document
describes how the MRTs can be used and not how to compute them.</t>
<t>MRT provides destination-based trees for each destination. Each
router stores its normal primary next-hop(s) as well as MRT-Blue
next-hop(s) and MRT-Red next-hop(s) toward each destination. The
alternate will be selected between the MRT-Blue and MRT-Red.</t>
<t>The most important thing to understand about MRTs is that for each
pair of destination-routed MRTs, there is a path from every node X to
the destination D on the Blue MRT that is as disjoint as possible from
the path on the Red MRT.</t>
<t>For example, in <xref target="fig_example_2_connected"/>, there is
a network graph that is 2-connected in (a) and associated MRTs in (b)
and (c). One can consider the paths from B to R; on the Blue MRT, the
paths are B->F->D->E->R or B->C->D->E->R. On
the Red MRT, the path is B->A->R. These are clearly link and
node-disjoint. These MRTs are redundant trees because the paths are
disjoint.</t>
<figure anchor="fig_example_2_connected" title="A 2-connected Network" align="center">
<artwork align="center"><![CDATA[
[E]---[D]---| [E]<--[D]<--| [E]-->[D]---|
| | | | ^ | | |
| | | V | | V V
[R] [F] [C] [R] [F] [C] [R] [F] [C]
| | | ^ ^ ^ | |
| | | | | | V |
[A]---[B]---| [A]-->[B]---| [A]<--[B]<--|
(a) (b) (c)
a 2-connected graph Blue MRT towards R Red MRT towards R
]]></artwork>
</figure>
<t>By contrast, in <xref target="Non-2-connected_Network_Example"/>,
the network in (a) is not 2-connected. If F, G or the link F<->G
failed, then the network would be partitioned. It is clearly
impossible to have two link-disjoint or node-disjoint paths from G, I
or J to R. The MRTs given in (b) and (c) offer paths that are as
disjoint as possible. For instance, the paths from B to R are the
same as in <xref target="fig_example_2_connected"/> and the path from
G to R on the Blue MRT is G->F->D->E->R and on the Red MRT
is G->F->B->A->R.</t>
<figure anchor="Non-2-connected_Network_Example"
title="A non-2-connected network" align="center">
<artwork align="center"><![CDATA[
[E]---[D]---|
| | | |----[I]
| | | | |
[R]---[C] [F]---[G] |
| | | | |
| | | |----[J]
[A]---[B]---|
(a)
a non-2-connected graph
[E]<--[D]<--| [E]-->[D]
| ^ | [I] | |----[I]
V | | | V V ^
[R] [C] [F]<--[G] | [R]<--[C] [F]<--[G] |
^ ^ ^ V ^ | |
| | |----[J] | | [J]
[A]-->[B]---| [A]<--[B]<--|
(b) (c)
Blue MRT towards R Red MRT towards R
]]></artwork>
</figure>
</section>
<section anchor="mrt_and_frr" title="Maximally Redundant Trees (MRT) and Fast-Reroute">
<t>In normal IGP routing, each router has its shortest-path-tree to
all destinations. From the perspective of a particular destination,
D, this looks like a reverse SPT (rSPT). To use maximally redundant
trees, in addition, each destination D has two MRTs associated with
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-Blue forwarding topology and a MRT-Red forwarding topology.</t>
<t>Any IP/LDP fast-reroute technique beyond LFA requires an additional
dataplane procedure, such as an additional forwarding mechanism. The
well-known options are multi-topology forwarding (used by MRT-FRR),
tunneling (e.g. <xref target="I-D.ietf-rtgwg-ipfrr-notvia-addresses"/>
or <xref target="I-D.ietf-rtgwg-remote-lfa"/>), and per-interface
forwarding (e.g. Loop-Free Failure Insensitive Routing in <xref
target="EnyediThesis"/>).</t>
<t>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 MRTs to reach the destination D. For example, in <xref
target="Non-2-connected_Network_Example"/>, C 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.</t>
<t>As is always the case with fast-reroute technologies, forwarding
does not change until a local failure is detected. Packets are
forwarded along the shortest path. The appropriate alternate to use
is pre-computed. <xref target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>
describes exactly how to determine whether the MRT-Blue next-hops or
the MRT-Red next-hops should be the MRT alternate next-hops for a
particular primary next-hop N to a particular destination D.</t>
<t>MRT alternates are always available to use. It is a local decision
whether to use an MRT alternate, a Loop-Free Alternate or some other
type of alternate.</t>
<t>As described in <xref target="RFC5286"/>, when a worse failure than
is anticipated happens, using LFAs that are not downstream neighbors
can cause micro-looping. Section 1.1 of <xref target="RFC5286"/>
gives an example of link-protecting alternates causing a loop on node
failure. Even if a worse failure than anticipated happens, the use of
MRT alternates will not cause looping. Therefore, while
node-protecting LFAs may be preferred, the certainty that no
alternate-induced looping will occur is an advantage of using MRT
alternates when the available node-protecting LFA is not a downstream
path.</t>
</section>
<section anchor="sec_uni_forwarding" title="Unicast Forwarding with MRT Fast-Reroute">
<t>With LFA, there is no need to tunnel unicast traffic, whether IP or
LDP. The traffic is simply sent to an alternate. As mentioned
earlier in <xref target="mrt_and_frr"/>, MRT needs multi-topology
forwarding. Unfortunately, neither IP nor LDP provides extra bits for
a packet to indicate its topology.</t>
<t>Once the MRTs are computed, the two sets of MRTs are seen by the
forwarding plane as essentially two additional topologies. The same
considerations apply for forwarding along the MRTs as for handling
multiple topologies.</t>
<section anchor="sec_ldp_uni_forward" title="LDP Unicast Forwarding - Avoid Tunneling">
<t>For LDP, it is very desirable to avoid tunneling because, for at
least node protection, tunneling requires knowledge of remote LDP
label mappings and thus requires targeted LDP sessions and the
associated management complexity. There are two different mechanisms
that can be used; Option A MUST be supported.</t>
<t><list style="numbers">
<t> Option A - Encode MT-ID in Labels: In addition to sending a
single label for a FEC, a router would provide two additional
labels with the MT-IDs associated with the Blue MRT or Red MRT
forwarding topologies. This is very simple for hardware
support. It does reduce the label space for other uses. It also
increases the memory to store the labels and the communication
required by LDP.</t>
<t>Option B - Create Topology-Identification Labels: Use the
label-stacking ability of MPLS and specify only two additional
labels - one for each associated MRT color - by a new FEC type.
When sending a packet onto an MRT, first swap the LDP label and
then push the topology-identification label for that MRT color.
When receiving a packet with a topology-identification label, pop
it and use it to guide the next-hop selection in combination with
the next label in the stack; then swap the remaining label, if
appropriate, and push the topology-identification label for the
next-hop. This has minimal usage of additional labels, memory and
LDP communication. It does increase the size of packets and the
complexity of the required label operations and look-ups. This can
use the same mechanisms as are needed for context-aware label
spaces.</t> </list></t>
<t>Note that with LDP unicast forwarding, regardless of whether
topology-identification label or encoding topology in label is used,
no additional loopbacks per router are required. This is because LDP
labels are used on a hop-by-hop basis to identify MRT-blue and MRT-red
forwading topologies.</t>
<t>For greatest hardware compatibility, routers implementing MRT LDP
fast-reroute MUST support Option A of encoding the MT-ID in the
labels. The extensions to indicate an MT-ID for a FEC are described
in Section 3.2.1 of <xref target="I-D.ietf-mpls-ldp-multi-topology"/>.
</t>
</section>
<section title="IP Unicast Traffic">
<t>For IP, there is no currently practical alternative except
tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red
forwarding topology. The choice of tunnel egress MAY be flexible
since any router closer to the destination than the next-hop can work.
This architecture assumes that the original destination in the area is
selected (see <xref target="sec_multi_homed_prefixes"/> for handling
of multi-homed prefixes); another possible choice is the next-next-hop
towards the destination. For LDP traffic, using 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 but consistency with LDP is RECOMMENDED. If the tunnel egress
is the original destination router, then the traffic remains on the
redundant tree with sub-optimal routing. Selection of the tunnel
egress is a router-local decision.</t>
<t>There are three options available for marking IP packets with which
MRT it should be forwarded in. For greatest hardware compatibility
and ease in removing the MRT-topology marking at area/level
boundaries, routers that support MPLS and implement IP MRT
fast-reroute MUST support Option A - using an LDP label that indicates
the destination and MT-ID.</t>
<t><list style="numbers">
<t>Tunnel IP packets via an LDP LSP. This has the advantage that more
installed routers can do line-rate encapsulation and decapsulation.
Also, no additional IP addresses would need to be allocated or
signaled.
<list style="letters">
<t>Option A - LDP Destination-Topology Label: Use a label that
indicates both destination and MRT. This method allows easy tunneling
to the next-next-hop as well as to the IGP-area destination. For a
proxy-node, the destination to use is the non-proxy-node immediately
before the proxy-node on that particular color MRT.</t>
<t>Option B - LDP Topology Label: Use a Topology-Identifier label on
top of the IP packet. This is very simple. If tunneling to a
next-next-hop is desired, then a two-deep label stack can be used with
[ Topology-ID label, Next-Next-Hop Label ].</t> </list></t>
<t>Tunnel IP packets in IP. Each router supporting this option would
announce two additional loopback addresses and their associated MRT
color. Those addresses are used as destination addresses for MRT-blue
and MRT-red IP tunnels respectively. They allow the transit nodes to
identify the traffic as being forwarded along either MRT-blue or
MRT-red tree topology to reach the tunnel destination. Announcements
of these two additional loopback addresses per router with their MRT
color requires IGP extensions.</t>
</list></t>
</section>
</section>
<section anchor="sec_igp" title="Protocol Extensions and Considerations: OSPF and ISIS">
<t>For simplicity, the approach of defining a well-known profile is
taken in <xref target="I-D.atlas-ospf-mrt"/>. The purpose of
communicating support for MRT in the IGP is to indicate thatqq the
MRT-Blue and MRT-Red forwarding topologies are created for transit
traffic. This section describes the various options to be selected.
The default MRT profile is described here and the signaling extensions
for OSPF are given in <xref target="I-D.atlas-ospf-mrt"/>. </t>
<t>For any MRT profile, the MRT Island is created by starting from the
computing router. If the computing router supports the default MRT
profile, add it to the MRT Island. Add a router to the MRT Island if
the router supports the default MRT profile and is connected to the
MRT Island via bidirectional links eligible for MRT.</t>
<t>If a router advertises support for multiple MRT profiles, then it
MUST create the transit forwarding topologies for each of those,
unless the profile specifies No Forwarding Mechanism (e.g. as might be
done for a profile used only for multicast global protection). A
router MUST NOT advertise multiple MRT profiles that overlap in their
MRT-Red MT-ID or MRT-Blue MT-ID.</t>
<t>The MRT Profile also defines different behaviors such as how MRT
recomputation is handled and how area/level boundaries are dealt with.</t>
<t><list style="hanging">
<t hangText="MRT Algorithm: ">MRT Lowpoint algorithm defined in <xref
target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>.</t>
<t hangText="MRT-Red MT-ID: "> experimental 3997, final value assigned
by IANA allocated from the LDP MT-ID space</t>
<t hangText="MRT-Blue MT-ID: "> experimental 3998, final value
assigned by IANA allocated from the LDP MT-ID space</t>
<t hangText="GADAG Root Selection Priority: ">Among the routers in the
MRT Island and with the highest priority advertised, an implementation
MUST pick the router with the highest Router ID to be the GADAG
root.</t>
<t hangText="Forwarding Mechanisms: ">LDP</t>
<t hangText="Recalculation: ">Recalculation of MRTs SHOULD occur as
described in <xref target="sec_recalculation"/>. This allows the MRT
forwarding topologies to support IP/LDP fast-reroute traffic.</t>
<t hangText="Area/Level Border Behavior: ">As described in <xref
target="sec_abr_forwarding"/>, ABRs/LBRs SHOULD ensure that traffic
leaving the area also exits the MRT-Red or MRT-Blue forwarding
topology.</t>
</list></t>
<t>The following describes the aspects to be considered to define a
profile to advertise. For some profiles, associated information may
need to be distributed, such as GADAG Root Selection Priority, Red MRT
Loopback Address, Blue MRT Loopback Address.</t>
<t><list style="hanging">
<t hangText="MRT Algorithm: ">This identifies the particular MRT
algorithm used by the router for this profile. Algorithm
transitions can be managed by advertising multiple MRT profiles.</t>
<t hangText="MRT-Red MT-ID: ">This specifies the MT-ID to be
associated with the MRT-Red forwarding topology. It is needed for
use in LDP signaling. All routers in the MRT Island MUST agree on a
value.</t>
<t hangText="MRT-Blue MT-ID: ">This specifies the MT-ID to be
associated with the MRT-Blue forwarding topology. It is needed for
use in LDP signaling. All routers in the MRT Island MUST agree on a
value.</t>
<t hangText="GADAG Root Selection Priority: ">A MRT profile might
specify this to provide the network operator with a knob to force a
particular GADAG root selection. If not specified in the MRT
profile, the highest Router ID in the profile's MRT Island will be
elected the GADAG Root. If a GADAG Root Selection Priority is
specified, then the MRT profile must also specify how the GADAG Root
is elected.</t>
<t hangText="Forwarding Mechanism: ">This specifies which forwarding
mechanisms the router supports for transit traffic. An MRT island
must program appropriate next-hops into the forwarding plane. The
known options are IPv4, IPv6, LDP, and None. If IPv4 is supported,
then both MRT-Red and MRT-Blue IPv4 Loopback Addresses SHOULD be
specified. If IPv6 is supported, both MRT-Red and MRT-Blue IPv6
Loopback Addresses SHOULD be specified. If LDP is supported, then
LDP support and signaling extensions MUST be supported.</t>
<t hangText="MRT-Red Loopback Address: ">This provides the router's
loopback address to reach the router via the MRT-Red forwarding
topology. It can, of course, be specified for both IPv4 and
IPv6.</t>
<t hangText="MRT-Blue Loopback Address: ">This provides the router's
loopback address to reach the router via the MRT-Blue forwarding
topology. It can, of course, be specified for both IPv4 and IPv6.</t>
<t hangText="Recalculation: ">As part of what process and timing
should the new MRTs be computed on a modified topology? <xref
target="sec_recalculation"/> describes the minimum behavior required
to support fast-reroute.</t>
<t hangText="Area/Level Border Behavior: ">Should inter-area traffic
on the MRT-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-Red or MRT-Blue in the next area/level to avoid the potential
failure of an ABR? (See <xref target="I-D.atlas-rtgwg-mrt-mc-arch"/>
for use-case details.</t>
<t hangText="Other Profile-Specific Behavior: "> Depending upon the
use-case for the profile, there may be additional profile-specific
behavior.</t>
</list></t>
<t>As with LFA, it is expected that OSPF Virtual Links will not be supported.</t>
</section>
<section title="Protocol Extensions and considerations: LDP">
<t>The protocol extensions for LDP are defined in <xref
target="I-D.atlas-mpls-ldp-mrt"/>. A router must indicate that it
has the ability to support MRT; having this explicit allows the use of
MRT-specific processing, such as special handling of FECs sent with
the Rainbow MRT MT-ID.</t>
<t>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 as well as to the default shortest-path based MT-ID 0. 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 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 the LDP
egress, it is not MRT profile specific.
The proposed experimental value is 3999 and the final value will be
assigned by IANA and allocated from the LDP MT-ID space. The
authoritative values are given in <xref
target="I-D.atlas-mpls-ldp-mrt"/>.</t>
</section>
<section anchor= "sec_abr_forwarding" title="Inter-Area and ABR Forwarding Behavior">
<t>An ABR/LBR has two forwarding roles. First, it forwards traffic
inside its area. Second, it forwards traffic from one area into
another. These same two roles apply for MRT transit traffic. Traffic
on MRT-Red or MRT-Blue destined inside the area needs to stay on
MRT-Red or MRT-Blue in that area. However, it is desirable for
traffic leaving the area to also exit MRT-Red or MRT-Blue back to the
shortest-path forwarding.</t>
<t>For unicast MRT-FRR, the need to stay on an MRT forwarding topology
terminates at the ABR/LBR whose best route is via a different
area/level. It is highly desirable to go back to the default
forwarding topology when leaving an area/level. There are three basic
reasons for this. First, the default topology uses shortest paths;
the packet will thus take the shortest possible route to the
destination. Second, this allows failures that might appear in
multiple areas (e.g. ABR/LBR failures) to be separately identified and
repaired around. Third, the packet can be fast-rerouted again, if
necessary, due to a failure in a different area.</t>
<t>An ABR/LBR that receives a packet on MRT-Red or MRT-Blue towards a
destination in another area/level should forward the packet in the
area/level with the best route along MRT-Red or MRT-Blue. If the
packet came from that area/level, this correctly avoids the failure.
However, if the traffic came from a different area/level, the packet
should be removed from MRT-Red or MRT-Blue and forwarded on the
shortest-path default forwarding topology.</t>
<t>To avoid per-interface forwarding state for MRT-Red and MRT-Blue,
the ABR/LBR needs to arrange that packets destined to a different area
arrive at the ABR/LBR already not marked as MRT-Red or MRT-Blue.</t>
<t>For LDP forwarding where the MPLS label specifies (MT-ID, FEC), the
ABR/LBR is responsible for advertising the proper label to each
neighbor. Assume that an ABR/LBR has allocated three labels for a
particular destination; those labels are L_primary, L_blue, and L_red.
When the ABR/LBR advertises label bindings to routers in the area with
the best route to the destination, the ABR/LBR provides L_primary for
the default topology, L_blue for the MRT-Blue MT-ID and L_red for the
MRT-Red MT-ID, exactly as expected. However, when the ABR/LBR
advertises label bindings to routers in other areas, the ABR/LBR
advertises L_primary for the Rainbow MRT MT-ID, which is then used for
the default topology, for the MRT-Blue MT-ID and for the MRT-Red MT-ID.</t>
<t>The ABR/LBR installs all next-hops from the best area: primary
next-hops for L_primary, MRT-Blue next-hops for L_blue, and MRT-Red
next-hops for L_red. Because the ABR/LBR advertised (Rainbow MRT
MT-ID, FEC) with L_primary to neighbors not in the best area, packets
from those neighbors will arrive at the ABR/LBR with a label L_primary
and will be forwarded into the best area along the default topology.
By controlling what labels are advertised, the ABR/LBR can thus
enforce that packets exiting the area do so on the shortest-path
default topology.</t>
<t>If IP forwarding is used, then the ABR/LBR behavior is dependent
upon the outermost IP address. If the outermost IP address is an MRT
loopback address of the ABR/LBR, then the packet is decapsulated and
forwarded based upon the inner IP address, which should go on the
default SPT topology. If the outermost IP address is not an MRT
loopback address of the ABR/LBR, then the packet is simply forwarded
along the associated forwarding topology. A PLR sending traffic to a
destination outside its local area/level will pick the MRT and use the
associated MRT loopback address of the selected ABR/LBR connected to
the external destination.</t>
<t>Thus, regardless of which of these two forwarding mechanisms are
used, there is no need for additional computation or per-area
forwarding state.</t>
<figure anchor="fig_abr_mrt" title="ABR Forwarding Behavior and MRTs"
align="center">
<artwork align="center"><![CDATA[
+----[C]---- --[D]--[E] --[D]--[E]
| \ / \ / \
p--[A] Area 10 [ABR1] Area 0 [H]--p +-[ABR1] Area 0 [H]-+
| / \ / | \ / |
+----[B]---- --[F]--[G] | --[F]--[G] |
| |
| other |
+----------[p]-------+
area
(a) Example topology (b) Proxy node view in Area 0 nodes
+----[C]<--- [D]->[E]
V \ \
+-[A] Area 10 [ABR1] Area 0 [H]-+
| ^ / / |
| +----[B]<--- [F]->[G] V
| |
+------------->[p]<--------------+
(c) rSPT towards destination p
->[D]->[E] -<[D]<-[E]
/ \ / \
[ABR1] Area 0 [H]-+ +-[ABR1] [H]
/ | | \
[F]->[G] V V -<[F]<-[G]
| |
| |
[p]<------+ +--------->[p]
(d) Blue MRT in Area 0 (e) Red MRT in Area 0
]]></artwork>
</figure>
<t>The other forwarding mechanism described in <xref
target="sec_uni_forwarding"/> is using Topology-Identification Labels.
This mechanism would require that any router whose MRT-Red or MRT-Blue
next-hop is an ABR/LBR would need to determine whether the ABR/LBR
would forward the packet out of the area/level. If so, then that
router should pop off the topology-identification label before
forwarding the packet to the ABR/LBR.</t>
<t> For example, in <xref target="fig_abr_mrt"/>, if node H fails,
node E has to put traffic towards prefix p onto MRT-Red. But since
node D knows that ABR1 will use a best from another area, it is safe
for D to pop the Topology-Identification Label and just forward the
packet to ABR1 along the MRT-Red next-hop. ABR1 will use the shortest
path in Area 10.
</t>
<t>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 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 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-state advertisement (LSA). In this one case, suboptimal
forwarding along the MRT in the other area would happen. If that
becomes a realistic deployment scenario, OSPF extensions could be
considered. This is not covered in <xref
target="I-D.atlas-ospf-mrt"/>.</t>
</section>
<section anchor="sec_multi_homed_prefixes" title="Prefixes Multiply Attached to the MRT Island">
<t>How a computing router S determines its local MRT Island for each
supported MRT profile is already discussed in <xref
target="sec_igp"/>.</t>
<t>There are two types of prefixes or FECs that may be multiply
attached to an MRT Island. The first type are multi-homed prefixes
that usually connect at a domain or protocol boundary. The second
type represent routers that do not support the profile for the MRT
Island. The key difference is whether the traffic, once out of the
MRT Island, remains in the same area/level and might reenter the MRT
Island if a loop-free exit point is not selected.</t>
<t>One property of LFAs that is necessary to preserve is the ability
to protect multi-homed prefixes against ABR failure. For instance, if
a prefix from the backbone is available via both ABR A and ABR B, if A
fails, then the traffic should be redirected to B. This can also be
done for backups via MRT.</t>
<t>If ASBR protection is desired, this has additonal complexities if
the ASBRs are in different areas. Similarly, protecting labeled BGP
traffic in the event of an ASBR failure has additional complexities
due to the per-ASBR label spaces involved.</t>
<t>As discussed in <xref target="RFC5286"/>, a multi-homed prefix could be:
<list style="symbols">
<t>An out-of-area prefix announced by more than one ABR,</t>
<t>An AS-External route announced by 2 or more ASBRs,</t>
<t>A prefix with iBGP multipath to different ASBRs,</t>
<t>etc.</t>
</list></t>
<t>There are also two different approaches to protection. The first
is to do endpoint selection to pick a router to tunnel to where that
router is loop-free with respect to the failure-point. Conceptually,
the set of candidate routers to provide LFAs expands to all routers,
with an MRT alternate, attached to the prefix.</t>
<t>The second is to use a proxy-node, that can be named via MPLS label
or IP address, and pick the appropriate label or IP address to reach
it on either MRT-Blue or MRT-Red as appropriate to avoid the failure
point. A proxy-node can represent a destination prefix that can be
attached to the MRT Island via at least two routers. It is termed a
named proxy-node if there is a way that traffic can be encapsulated to
reach specifically that proxy-node; this could be because there is an
LDP FEC for the associated prefix or because MRT-Red and MRT-Blue IP
addresses are advertised in an as-yet undefined fashion for that
proxy-node. Traffic to a named proxy-node may take a different path
than traffic to the attaching router; traffic is also explicitly
forwarded from the attaching router along a predetermined interface
towards the relevant prefixes.</t>
<t>For IP traffic, multi-homed prefixes can use endpoint selection.
For IP traffic that is destined to a router outside the MRT Island, if
that router is the egress for a FEC advertised into the MRT Island,
then the named proxy-node approach can be used.</t>
<t>For LDP traffic, there is always a FEC advertised into the MRT
Island. The named proxy-node approach should be used, unless the computing
router S knows the label for the FEC at the selected endpoint.</t>
<t>If a FEC is advertised from outside the MRT Island into the MRT
Island and the forwarding mechanism specified in the profile includes
LDP, then the routers learning that FEC MUST also advertise labels for
(MRT-Red, FEC) and (MRT-Blue, FEC) to neighbors inside the MRT Island.
If the forwarding mechanism includes LDP, any router receiving a FEC
corresponding to a router outside the MRT Island or to a multi-homed
prefix MUST compute and install the transit MRT-Blue and MRT-Red
next-hops for that FEC; the associated FECs ( (MT-ID 0, FEC),
(MRT-Red, FEC), and (MRT-Blue, FEC)) MUST also be provided via LDP to
neighbors inside the MRT Island.</t>
<section title="Endpoint Selection">
<t>Endpoint Selection is a local matter for a router in the MRT Island
since it pertains to selecting and using an alternate and does not
affect the transit MRT-Red and MRT-Blue forwarding topologies. </t>
<t>Let the computing router be S and the next-hop F be the node whose
failure is to be avoided. Let the destination be prefix p. Have A be
the router to which the prefix p is attached for S's shortest path to
p. </t>
<t>The candidates for endpoint selection are those to which the
destination prefix is attached in the area/level. For a particular
candidate B, it is necessary to determine if B is loop-free to reach p
with respect to S and F for node-protection or at least with respect
to S and the link (S, F) for link-protection. If B will always prefer
to send traffic to p via a different area/level, then this is
definitional. Otherwise, distance-based computations are necessary
and an SPF from B's perspective may be necessary. The following
equations give the checks needed; the rationale is similar to that
given in <xref target="RFC5286"/>.</t>
<t>Loop-Free for S: D_opt(B, p) < D_opt(B, S) + D_opt(S, p)</t>
<t>Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(F, p)</t>
<t>The latter is equivalent to the following, which avoids the need to
compute the shortest path from F to p.</t>
<t>Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(S, p) - D_opt(S, F)</t>
<t>Finally, the rules for Endpoint selection are given below. The
basic idea is to repair to the prefix-advertising router selected for the
shortest-path and only to select and tunnel to a different endpoint if
necessary (e.g. A=F or F is a cut-vertex or the link (S,F) is a
cut-link).</t>
<t><list style="numbers">
<t>Does S have a node-protecting alternate to A? If so, select that.
Tunnel the packet to A along that alternate. For example, if LDP is
the forwarding mechanism, then push the label (MRT-Red, A) or
(MRT-Blue, A) onto the packet. </t>
<t>If not, then is there a router B that is loop-free to reach p while
avoiding both F and S? If so, select B as the end-point. Determine
the MRT alternate to reach B while avoiding F. Tunnel the packet to B
along that alternate. For example, with LDP, push the label (MRT-Red,
B) or (MRT-Blue, B) onto the packet.</t>
<t>If not, then does S have a link-protecting alternate to A? If so,
select that.</t>
<t>If not, then is there a router B that is loop-free to reach p while
avoiding S and the link from S to F? If so, select B as the endpoint
and the MRT alternate that for reaching B from S avoiding the link
(S,F).</t>
</list></t>
<t>The endpoint selected will receive a packet destined to itself and,
being the egress, will pop that MPLS label (or have signaled Implicit
Null) and forward based on what is underneath. This suffices for IP
traffic where the MPLS labels understood by the endpoint router are
not needed.</t>
</section>
<section title="Named Proxy-Nodes">
<t> A clear advantage to using a named proxy-node is that it is
possible to explicitly forward from the MRT Island along an interface
to a loop-free island neighbor (LFIN) when that interface may not be a
primary next-hop. For LDP traffic where the label indicates both the
topology and the FEC, it is necessary to either use a named proxy-node
or deal with learning remote MPLS labels.</t>
<t>A named proxy-node represents one or more destinations and, for LDP
forwarding, has a FEC associated with it that is signaled into the 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 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 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 uniquely
represented by the two routers in the MRT Island to which it is
connected. The extensions to signal such IP addresses are not defined
in <xref target="I-D.atlas-ospf-mrt"/>. The details of what
label-bindings must be originated are described in <xref
target="I-D.atlas-mpls-ldp-mrt"/>.</t>
<t>Computing the MRT next-hops to a named proxy-node and the MRT
alternate for the computing router S to avoid a particular failure
node F is extremely straightforward. The details of the simple
constant-time functions, Select_Proxy_Node_NHs() and
Select_Alternates_Proxy_Node(), are given in
<xref target="I-D.enyedi-rtgwg-mrt-frr-algorithm"/>. A key point is that
computing 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 impacting other existing MRT paths. This maps very
well to, for example, how OSPFv2 [<xref target="RFC2328"/> Section 16.5]
does incremental updates for new summary-LSAs.</t>
<t>The key question is how to attach the named proxy-node to the MRT
Island; all the routers in the MRT Island MUST do this consistently.
No more than 2 routers in the MRT Island can be selected; one should
only be selected if there are no others that meet the necessary
criteria. The named proxy-node is logically part of the
area/level.</t>
<t>There are two sources for candidate routers in the MRT Island to
connect to the named proxy-node. The first set are those routers that
are advertising the prefix; the cost assigned to each such router is
the announced cost to the prefix. The second set are those routers in
the MRT Island that are connected to routers not in the MRT Island but
in the same area/level; such routers will be defined as Island Border
Routers (IBRs). The routers connected to the IBRs that are not in the
MRT Island and are in the same area/level are Island Neighbors
(INs).</t>
<t>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
whatever router to which an IBR forwards the packet be loop-free with
regard to the whole MRT Island for the destination. Thus, an IBR is a
candidate router only if it possesses at least one IN whose path to
the prefix does not enter the MRT Island. The cost assigned to each
(IBR, IN) pair is the D_opt(IN, prefix) plus Cost(IBR, IN).</t>
<t>From the set of prefix-advertising routers and the IBRs, the two
lowest cost routers are selected and ties are broken based upon the
lowest Router ID. For ease of discussion, such selected routers are
proxy-node attachment routers and the two selected will be named A and
B.</t>
<t>A proxy-node attachment router has a special forwarding role. When
a packet is received destined to (MRT-Red, prefix) or (MRT-Blue,
prefix), if the proxy-node attachment router is an IBR, it MUST swap
to the default topology (e.g. swap to the label for (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 proxy-node attachment
router is not an IBR, then the packet MUST be removed from the MRT
forwarding topology and sent along the interface that caused the
router to advertise the prefix; this interface might be out of the
area/level/AS.</t>
<section title="Computing if an Island Neighbor (IN) is loop-free">
<t>As discussed, the Island Neighbor needs to be loop-free with regard
to the whole MRT Island for the destination. Conceptually, the cost
of transiting the MRT Island should be regarded as 0. This can be
done by collapsing the MRT Island into a single node, as seen in <xref
target="fig_island_ext_dest"/>, and then computing SPFs from each
Island Neighbor and from the MRT Island itself.</t>
<figure anchor="fig_island_ext_dest"
title="Computing alternates to destinations outside the MRT Island">
<artwork align="center"><![CDATA[
[G]---[E]---(V)---(U)---(T)
| \ | | |
| \ | | |
| \ | | |
[H]---[F]---(R)---(S)----|
(1) Network Graph with Partial Deployment
[E],[F],[G],[H] : No support for MRT
(R),(S),(T),(U),(V): MRT Island - supports MRT
[G]---[E]----| |---(V)---(U)---(T)
| \ | | | | |
| \ | ( MRT Island ) [ proxy ] | |
| \ | | | | |
[H]---[F]----| |---(R)---(S)----|
(2) Graph for determining (3) Graph for MRT computation
loop-free neighbors
]]></artwork>
</figure>
<t>The simple way to do this without manipulating the topology is to
compute the SPFs from each IN and a node in the MRT Island (e.g. the
GADAG root), but use a link metric of 0 for all links between routers
in the MRT Island. The distances computed via SPF this way will be
refered to as Dist_mrt0.</t>
<t>An IN is loop-free with respect to a destination D if:
Dist_mrt0(IN, D) < Dist_mrt0(IN, MRT Island Router) + Dist_mrt0(MRT
Island Router, D). Any router in the MRT Island can be used since the
cost of transiting between MRT Island routers is 0. The GADAG Root is
recommended for consistency.</t>
</section>
</section>
<section title="MRT Alternates for Destinations Outside the MRT Island">
<t>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 MRT FRR, where it provides alternates when appropriate LFAs aren't
available, there are also deployment scenarios where it may make 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 is
connected via two routers to the rest of the area.</t>
<t>Destinations inside the local island can obviously use MRT
alternates. Destinations outside the local island can be treated like
a multi-homed prefix and either Endpoint Selection or Named
Proxy-Nodes can be used. Named Proxy-Nodes MUST be supported when LDP
forwarding is supported and a label-binding for the destination is
sent to an IBR.</t>
<t>Naturally, there are more complicated options to improve coverage,
such as connecting multiple MRT islands across tunnels, but the need
for the additional complexity has not been justified.</t>
</section>
</section>
<section title="Network Convergence and Preparing for the Next Failure">
<t>After a failure, MRT detours ensure that packets reach their
intended destination while the IGP has not reconverged onto the new
topology. As link-state updates reach the routers, the IGP process
calculates the new shortest paths. Two things need attention:
micro-loop prevention and MRT re-calculation.</t>
<section title="Micro-forwarding loop prevention and MRTs">
<t>As is well known<xref target="RFC5715"/>, micro-loops can occur
during IGP convergence; such loops can be local to the failure or
remote from the failure. Managing micro-loops is an orthogonal issue
to having alternates for local repair, such as MRT fast-reroute
provides.</t>
<t>There are two possible micro-loop prevention mechanisms discussed in
<xref target="RFC5715"/>. The first is Ordered FIB <xref
target="I-D.ietf-rtgwg-ordered-fib"/>. The second is Farside
Tunneling which requires tunnels or an alternate topology to reach
routers on the farside of the failure.</t>
<t>Since MRTs provide an alternate topology through which traffic can
be sent and which can be manipulated separately from the SPT, it is
possible that MRTs could be used to support Farside Tunneling.
Details of how to do so are outside the scope of this document.</t>
<t>Micro-loop mitigation mechanisms can also work when combined with
MRT.</t>
</section>
<section anchor="sec_recalculation" title="MRT Recalculation">
<t>When a failure event happens, traffic is put by the PLRs onto the
MRT topologies. After that, each router recomputes its shortest path
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 MRT
topologies should each router install the recomputed MRTs into the
FIBs.</t>
<t>At each router, therefore, the sequence is as follows:
<list style="numbers">
<t>Receive failure notification</t>
<t>Recompute SPT</t>
<t>Install new SPT</t>
<t>If the network was stable before the failure occured, wait a
configured (or advertised) period for all routers to be using their SPTs
and traffic to drain from the MRTs.</t>
<t>Recompute MRTs</t>
<t>Install new MRTs.</t>
</list></t>
<t>While the recomputed MRTs are not installed in the FIB, protection
coverage is lowered. Therefore, it is important to recalculate the
MRTs and install them quickly.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Mike Shand for his valuable
review and contributions.</t>
<t>The authors would like to thank Joel Halpern, Hannes Gredler, Ted
Qian, Kishore Tiruveedhula, Shraddha Hegde, Santosh Esale, Nitin
Bahadur, Harish Sitaraman, Raveendra Torvi and Chris Bowers for
their suggestions and review.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This doument includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This architecture is not currently believed to introduce new security concerns.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC5714;
&RFC5286;
&I-D.enyedi-rtgwg-mrt-frr-algorithm;
</references>
<references title="Informative References">
&RFC2119;
&RFC2328;
&RFC3137;
&RFC5443;
&RFC5715;
&RFC6571;
&I-D.atlas-rtgwg-mrt-mc-arch;
&I-D.ietf-mpls-ldp-multi-topology;
&I-D.bryant-ipfrr-tunnels;
&I-D.ietf-rtgwg-remote-lfa;
&I-D.litkowski-rtgwg-node-protect-remote-lfa;
&I-D.ietf-rtgwg-ipfrr-notvia-addresses;
&I-D.ietf-rtgwg-ordered-fib;
<reference anchor="I-D.atlas-ospf-mrt">
<front>
<title>OSPF Extensions to Support Maximally Redundant Trees</title>
<author fullname="Alia K. Atlas" initials="A." surname="Atlas"/>
<author fullname="Shraddha Hegde" initials="S." surname="Hegde"/>
<author fullname="Chris Bowers" initials="C." surname="Chris"/>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"/>
<date month="July" day="12" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-atlas-ospf-mrt-00"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-atlas-ospf-mrt-00.txt"/>
</reference>
<reference anchor="I-D.atlas-mpls-ldp-mrt">
<front>
<title>LDP Extensions to Support Maximally Redundant Trees</title>
<author fullname="Alia K. Atlas" initials="A." surname="Atlas"/>
<author fullname="Kishore Tiruveedhula" initials="K" surname="Tiruveedhula"/>
<author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura"/>
<author fullname="IJsbrand Wijnands" initials="IJ.W." surname="Wijnands"/>
<date month="July" day="8" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-atlas-mpls-ldp-mrt-00"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-atlas-mpls-ldp-mrt-00.txt"/>
</reference>
<reference anchor="LightweightNotVia"
target="http://mycite.omikk.bme.hu/doc/71691.pdf">
<front>
<title>IP Fast ReRoute: Lightweight Not-Via without Additional Addresses</title>
<author fullname="Gábor Sándor Enyedi" initials="G.S.E." surname="Enyedi"/>
<author fullname="Gabor Retvari" initials="G.R." surname="Retvari"/>
<author fullname="Peter Szilagyi" initials="P.S." surname="Szilagyi"/>
<author fullname="András Császár" initials="A.C." surname="Császár"/>
<date year="2009" />
</front>
<seriesInfo name="Proceedings of IEEE INFOCOM" value=""/>
<format type='PDF' target="http://mycite.omikk.bme.hu/doc/71691.pdf"/>
</reference>
<reference anchor="LFARevisited"
target="http://opti.tmit.bme.hu/~tapolcai/papers/retvari2011lfa_infocom.pdf">
<front>
<title>IP Fast ReRoute: Loop Free Alternates Revisited</title>
<author fullname="Gabor Retvari" initials="G.R." surname="Retvari"/>
<author fullname="Janos Tapolcai" initials="J.T." surname="Tapolcai"/>
<author fullname="Gábor Sándor Enyedi" initials="G.S.E." surname="Enyedi"/>
<author fullname="András Császár" initials="A.C." surname="Császár"/>
<date year="2011" />
</front>
<seriesInfo name="Proceedings of IEEE INFOCOM" value=""/>
<format type='PDF' target="http://opti.tmit.bme.hu/~tapolcai/papers/retvari2011lfa_infocom.pdf"/>
</reference>
<reference anchor="EnyediThesis"
target="http://timon.tmit.bme.hu/theses/thesis_book.pdf">
<front>
<title>Novel Algorithms for IP Fast Reroute</title>
<author fullname="Gábor Sándor Enyedi" initials="G.S.E." surname="Enyedi"/>
<date month="February" year="2011"/>
</front>
<seriesInfo name="Department of Telecommunications and Media Informatics, Budapest University of Technology and Economics" value="Ph.D. Thesis"/>
<format type='PDF' target="http://www.omikk.bme.hu/collections/phd/Villamosmernoki_es_Informatikai_Kar/2011/Enyedi_Gabor/ertekezes.pdf" />
</reference>
</references>
<section title="General Issues with Area Abstraction">
<t>When a multi-homed prefix is connected in two different areas, it
may be impractical to protect them without adding the complexity of
explicit tunneling. This is also a problem for LFA and Remote-LFA.</t>
<figure anchor="fig_mhp_areas" title="AS external prefixes in different areas">
<artwork align="center"><![CDATA[
50
|----[ASBR Y]---[B]---[ABR 2]---[C] Backbone Area 0:
| | ABR 1, ABR 2, C, D
| |
| | Area 20: A, ASBR X
| |
p ---[ASBR X]---[A]---[ABR 1]---[D] Area 10: B, ASBR Y
5 p is a Type 1 AS-external
]]></artwork>
</figure>
<t>Consider the network in <xref target="fig_mhp_areas"/> and assume
there is a richer connective topology that isn't shown, where the same
prefix is 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 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 20. This problem occurs because the routers, including the ABR,
in one area are not yet aware of the failure in a different area.</t>
<t>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
are known, then explicit tunneling MAY be used as long as the
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 MRT
alternate.</t>
</section>
<!-- Change Log
v00 2011-06-28 AKA Initial version
v01 2011-07-13 RWK Multicast Changes
v02 2012-01-18 AKA First WG version - removed multicast
v03 2012-03-08 AKA Second WG version - added more details for
inter-area, IGP signaling, and phased deployment.
v04 2013-02-23 AKA WG-03 - added profile flags, LDP signaling, removed
restriction to only 2 nodes for proxy-nodes.
v05 2013-06-27 AKA Third WG version - serious revision for clarity,
added plan for MRT profiles, added full clear computation and details
for multi-homed prefixes and MRT islands.
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:07:27 |