`1097`

`1097`

`01886`

`94089`

`85721`

```
```

```
```
This specification defines the MRT Lowpoint Algorithm, which is one
option among several possible MRT algorithms. Other alternatives are
described in the appendices.
In addition, it is possible to calculate Destination-Rooted GADAG,
where for each destination, a GADAG rooted at that destination is
computed. Then a router can compute the blue MRT and red MRT
next-hops to that destination. Building GADAGs per destination is
computationally more expensive, but may give somewhat shorter
alternate paths. It may be useful for live-live multicast along
MRTs.
The MRT Lowpoint algorithm is the lowest computation of the MRT
algorithms. Two other MRT algorithms are provided in and . When
analyzed on service provider network topologies, they did not provide
significant differences in the path lenghts for the alternatives.
This section does not focus on that analysis or the decision to use
the MRT Lowpoint algorithm as the default MRT algorithm; it has the
lowest computational and storage requirements and gave comparable
results.
Since this document defines the MRT Lowpoint algorithm for use in
fast-reroute applications, it is useful to compare MRT and Remote LFA
. This section compares MRT
and remote LFA for IP Fast Reroute in 19 service provider network
topologies, focusing on coverage and alternate path length. shows the node-protecting
coverage provided by local LFA (LLFA), remote LFA (RLFA), and MRT
against different failure scenarios in these topologies. The coverage
values are calculated as the percentage of source-destination pairs
protected by the given IPFRR method relative to those protectable by
optimal routing, against the same failure modes. More details on
alternate selection policies used for this analysis are described
later in this section.
For the topologies analyzed here, LLFA is able to provide
node-protecting coverage ranging from 37% to 95% of the
source-destination pairs, as seen in the column labeled NP_LLFA. The
use of RLFA in addition to LLFA is generally able to increase the
node-protecting coverage. The percentage of node-protecting coverage
with RLFA is provided in the column labeled NP_RLFA, ranges from 59%
to 98% for these topologies. The node-protecting coverage provided by
MRT is 100% since MRT is able to provide protection for any
source-destination pair for which a path still exists after the
failure.
We would also like to measure the quality of the alternate paths
produced by these different IPFRR methods. An obvious approach is to
take an average of the alternate path costs over all
source-destination pairs and failure modes. However, this presents a
problem, which we will illustrate by presenting an example of results
for one topology using this approach ( ). In this table, the average
relative path length is the alternate path length for the IPFRR method
divided by the optimal alternate path length, averaged over all
source-destination pairs and failure modes. The first three columns
of data in the table give the path length calculated from the sum of
IGP metrics of the links in the path. The results for topology T208
show that the metric-based path lengths for NP_LLFA and NP_RLFA
alternates are on average 78 and 66 times longer than the path lengths
for optimal alternates. The metric-based path lengths for MRT
alternates are on average 14 times longer than for optimal alternates.
The network topology represented by T208 uses values of 10, 100, and
1000 as IGP costs, so small deviations from the optimal alternate path
can result in large differences in relative path length. LLFA, RLFA,
and MRT all allow for at least one hop in the alterate path to be
chosen independent of the cost of the link. This can easily result in
an alternate using a link with cost 1000, which introduces noise into
the path length measurement. In the case of T208, the adverse effects
of using metric-based path lengths is obvious. However, we have
observed that the metric-based path length introduces noise into
alternate path length measurements in several other topologies as
well. For this reason, we have opted to measure the alternate path
length using hopcount. While IGP metrics may be adjusted by the
network operator for a number of reasons (e.g. traffic engineering),
the hopcount is a fairly stable measurement of path length. As shown
in the last three columns of ,
the hopcount-based alternate path lengths for topology T208 are fairly
well-behaved.
, , , and present the hopcount-based path
length results for the 19 topologies examined. The topologies in the
four tables are grouped based on the size of the topologies, as
measured by the number of nodes, with having the smallest topologies
and having the largest
topologies. Instead of trying to represent the path lengths of a
large set of alternates with a single number, we have chosen to
present a histogram of the path lengths for each IPFRR method and
alternate selection policy studied. The first eight colums of data
represent the percentage of failure scenarios protected by an
alternate N hops longer than the primary path, with the first column
representing an alternate 0 or 1 hops longer than the primary path,
all the way up through the eighth column respresenting an alternate 14
or 15 hops longer than the primary path. The last column in the table
gives the percentage of failure scenarios for which there is no
alternate less than 16 hops longer than the primary path. In the case
of LLFA and RLFA, this category includes failure scenarios for which
no alternate was found.
For each topology, the first row (labeled OPTIMAL) is the distribution
of the number of hops in excess of the primary path hopcount for
optimally routed alternates. (The optimal routing was done with
respect to IGP metrics, as opposed to hopcount.) The second
row(labeled NP_LLFA) is the distribution of the extra hops for
node-protecting LLFA. The third row (labeled NP_LLFA_THEN_NP_RLFA) is
the hopcount distribution when one adds node-protecting RLFA to
increase the coverage. The alternate selection policy used here first
tries to find a node-protecting LLFA. If that does not exist, then it
tries to find an RLFA, and checks if it is node-protecting. Comparing
the hopcount distribution for RLFA and LLFA across these topologies,
one can see how the coverage is increased at the expense of using
longer alternates. It is also worth noting that while superficially
LLFA and RLFA appear to have better hopcount distributions than
OPTIMAL, the presence of entries in the last column (no alternate <
16) mainly represent failure scenarios that are not protected, for
which the hopcount is effectively infinite.
The fourth and fifth rows of each topology show the hopcount
distributions for two alternate selection policies using MRT
alternates. The policy represented by the label
NP_LLFA_THEN_MRT_LOWPOINT will first use a node-protecting LLFA. If a
node-protecting LLFA does not exist, then it will use an MRT
alternate. The policy represented by the label MRT_LOWPOINT instead
will use the MRT alternate even if a node-protecting LLFA exists. One
can see from the data that combining node-protecting LLFA with MRT
results in a significant shortening of the alternate hopcount
distribution.
In the preceding analysis, the following procedure for selecting
an RLFA was used. Nodes were ordered with respect to distance from the
source and checked for membership in Q and P-space. The first node to
satisfy this condition was selected as the RLFA. More sophisticated
methods to select node-protecting RLFAs is an area of active research.
The analysis presented above uses the MRT Lowpoint Algorithm
defined in this specification with a common GADAG root. The
particular choice of a common GADAG root is expected to affect the
quality of the MRT alternate paths, with a more central common GADAG
root resulting in shorter MRT alternate path lengths. For the
analysis above, the GADAG root was chosen for each topology by
calculating node centrality as the sum of costs of all shortest paths
to and from a given node. The node with the lowest sum was chosen as
the common GADAG root. In actual deployments, the common GADAG root
would be chosen based on the GADAG Root Selection Priority advertised
by each router, the values of which would be determined off-line.
In order to measure how sensitive the MRT alternate path lengths are
to the choice of common GADAG root, we performed the same analysis
using different choices of GADAG root. All of the nodes in the
network were ordered with respect to the node centrality as computed
above. Nodes were chosen at the 0th, 25th, and 50th percentile with
respect to the centrality ordering, with 0th percentile being the most
central node. The distribution of alternate path lengths for those
three choices of GADAG root are shown in for a subset of
the 19 topologies (chosen arbitrarily). The third row for each
topology (labeled MRT_LOWPOINT ( 0 percentile) ) reproduces the
results presented above for MRT_LOWPOINT_ONLY. The fourth and fifth
rows show the alternate path length distibution for the 25th and 50th
percentile choice for GADAG root. One can see some impact on the path
length distribution with the less central choice of GADAG root
resulting in longer path lenghths.
We also looked at the impact of MRT algorithm variant on the alternate
path lengths. The first two rows for each topology present results of
the same alternate path length distribution analysis for the SPF and
Hybrid methods for computing the GADAG. These two methods are
described in and . For three of the topologies in this
subset (T201, T206, and T211), the use of SPF or Hybrid methods does
not appear to provide a significant advantage over the Lowpoint method
with respect to path length. Instead, the choice of GADAG root
appears to have more impact on the path length. However, for two of
the topologies in this subset(T216 and T219) and for this particular
choice of GAGAG root, the use of the SPF method results in noticeably
shorter alternate path lengths than the use of the Lowpoint or Hybrid
methods. It remains to be determined if this effect applies generally
across more topologies or is sensitive to choice of GADAG root.
[RFC Editor: please remove this section prior to publication.]
Please see for
details on implementation status.
The authors would like to thank Shraddha Hegde for her
suggestions and review. We would also like to thank Anil Kumar SN
for his assistance in clarifying the algorithm description and
pseudo-code.
This document includes no request to IANA.
This architecture is not currently believed to introduce new security concerns.

```
```
&RFC2119;
&RFC2328;
&RFC3137;
&RFC5120;
&RFC5286;
&RFC5714;
&RFC7490;
&I-D.ietf-rtgwg-ipfrr-notvia-addresses;
&I-D.ietf-rtgwg-lfa-manageability;
Topological sorting of large networks
Novel Algorithms for IP Fast Reroute
&RFC6571;
IP Fast ReRoute: Lightweight Not-Via without Additional Addresses
IP Fast ReRoute: Loop Free Alternates Revisited
On Finding Maximally Redundant Trees in Strictly Linear Time
Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)
International Organization for Standardization
The basic idea in this option is to use slightly-modified SPF
computations to find ears. In every block, an SPF computation is first
done to find a cycle from the local root and then SPF computations in
that block find ears until there are no more interfaces to be
explored. The used result from the SPF computation is the path of
interfaces indicated by following the previous hops from the mininized
IN_GADAG node back to the SPF root.
To do this, first all cut-vertices must be identified and
local-roots assigned as specified in .
The slight modifications to the SPF are as follows. The root of the
block is referred to as the block-root; it is either the GADAG root or
a cut-vertex.
The SPF is rooted at a neighbor x of an IN_GADAG node y. All links
between y and x are marked as TEMP_UNUSABLE. They should not be used
during the SPF computation.
If y is not the block-root, then it is marked TEMP_UNUSABLE. It
should not be used during the SPF computation. This prevents ears
from starting and ending at the same node and avoids cycles; the
exception is because cycles to/from the block-root are acceptable and
expected.
Do not explore links to nodes whose local-root is not the
block-root. This keeps the SPF confined to the particular block.
Terminate when the first IN_GADAG node z is minimized.
Respect the existing directions (e.g. INCOMING, OUTGOING,
UNDIRECTED) already specified for each interface.

Assume that an ear is found by going from y to x and then running
an SPF that terminates by minimizing z
(e.g. y<->x...q<->z). Now it is necessary to determine
the direction of the ear; if y << z, then the path should be
y->x...q->z but if y >> z, then the path should be
y<-x...q<-z. In , the same
problem was handled by finding all ears that started at a node before
looking at ears starting at nodes higher in the partial order. In
this algorithm, using that approach could mean that new ears aren't
added in order of their total cost since all ears connected to a node
would need to be found before additional nodes could be found.
The alternative is to track the order relationship of each node
with respect to every other node. This can be accomplished by
maintaining two sets of nodes at each node. The first set,
Higher_Nodes, contains all nodes that are known to be ordered above
the node. The second set, Lower_Nodes, contains all nodes that are
known to be ordered below the node. This is the approach used in this
algorithm.
A goal of the algorithm is to find the shortest cycles and ears.
An ear is started by going to a neighbor x of an IN_GADAG node y. The
path from x to an IN_GADAG node is minimal, since it is computed via
SPF. Since a shortest path is made of shortest paths, to find the
shortest ears requires reaching from the set of IN_GADAG nodes to the
closest node that isn't IN_GADAG. Therefore, an ordered tree is
maintained of interfaces that could be explored from the IN_GADAG
nodes. The interfaces are ordered by their characteristics of metric,
local loopback address, remote loopback address, and ifindex, as in
the algorithm previously described in .
The algorithm ignores interfaces picked from the ordered tree that
belong to the block root if the block in which the interface is
present already has an ear that has been computed. This is necessary
since we allow at most one incoming interface to a block root in each
block. This requirement stems from the way next-hops are computed as
was seen in . After any ear
gets computed, we traverse the newly added nodes to the GADAG and
insert interfaces whose far end is not yet on the GADAG to the ordered
tree for later processing.
Finally, cut-links are a special case because there is no point in
doing an SPF on a block of 2 nodes. The algorithm identifies
cut-links simply as links where both ends of the link are
cut-vertices. Cut-links can simply be added to the GADAG with both
OUTGOING and INCOMING specified on their interfaces.
In this option, the idea is to combine the salient features of the
lowpoint inheritance and SPF methods. To this end, we process nodes
as they get added to the GADAG just like in the lowpoint inheritance
by maintaining a stack of nodes. This ensures that we do not need to
maintain lower and higher sets at each node to ascertain ear
directions since the ears will always be directed from the node being
processed towards the end of the ear. To compute the ear however, we
resort to an SPF to have the possibility of better ears (path lentghs)
thus giving more flexibility than the restricted use of lowpoint/dfs
parents.
Regarding ears involving a block root, unlike the SPF method which
ignored interfaces of the block root after the first ear, in the
hybrid method we would have to process all interfaces of the block
root before moving on to other nodes in the block since the direction
of an ear is pre-determined. Thus, whenever the block already has an
ear computed, and we are processing an interface of the block root, we
mark the block root as unusable before the SPF run that computes the
ear. This ensures that the SPF terminates at some node other than the
block-root. This in turn guarantees that the block-root has only one
incoming interface in each block, which is necessary for correctly
computing the next-hops on the GADAG.
As in the SPF gadag, bridge ears are handled as a special case.
The entire algorithm is shown below in

```
```