Preferred Path Loop-Free Alternate (pLFA)Futurewei Technologies Incstewart.bryant@gmail.comFuturewei Technologies Incuchundur@futurewei.comFuturewei Technologies Inctte+ietf@cs.fau.deRouting Area Working GroupFast re-route (FRR) is a technique that allows productive forwarding to
continue in a network after a failure has occurred, but before
the network has has time to re-converge. This is achieved by forwarding
a packet on an alternate path that will not result in the packet looping.
Preferred Path Routing
(PPR) provides a method of injecting explicit paths into the
routing protocol. The use of PPR to support FRR has a number of
advantages. This document describes the advantages of using
PPR to provide a loop-free alternate FRR path, and provides a framework for its use
in this application.Preferred Path Routing (PPR)
is a method of introducing explicit paths to a network. Such a path
may be any loop-free path between two points in the network that
satisfies the need for which the path was created. The PPR path is not
constrained to be the shortest path between any points in the network,
although the use of shortest path segments is provided for in
order to compress the
size of the path description flooded by the routing protocol.
The advantages of PPR over alternate methods of creating such paths is
described in .A packet is carried over the network in an appropriate form
using the Preferred Path Routing Identifier (PPR-ID) as the data plane
identifier to map the packet to the PPR path, and hence the resources
and next-hop (NH). One way of adding a PPR-ID to a packet would be
to encapsulate it, but PPR does not restrict the user to the use of
encapsulation. How the PPR-ID is carried in the general case is
outside the scope of this document. Various methods of adding the PPR-ID
to a packet for the purposes of Fast-Reroute (FRR) are described in .IP Fast Re-route (IPFRR)
and the methods known at the time of
its writing is described in . A number of later methods are
described in , , and
.This document is a framework describing various methods whereby PPR can
be used to provide IP Fast Reroute (IPFRR) paths. PPR can provide IPFRR
in a number of ways.o Signaling pre-computed preferred alternatives for the primary path
o Signaling individual segments on the repair path.
o Selective overriding of locally computed Loop Free Alternates (LFA) for the NH failure.
o Local repair to a Traffic Engineered paths avoiding the need for multi-hop
Bidirectional Forwarding Detection (BFD) .
o Micro-loop elimination .These are described in more detail within this memo.The term IP fast re-route (IPFRR) was adopted by the IETF as the
general name for best-effort Fast Re-route (FRR) in best effort
IP and MPLS networks. This was to distinguish this new work from
the then established FRR as described in which
uses RSVP Traffic Engineered (RSVP-TE) MPLS paths .Within this document the terms IPFRR and FRR are used interchangeably.PPR works by injecting into the network a path or a graph and a corresponding
forwarding identifier (PPR-ID). A node examines each PPR path description and
if it is on the path it inserts into the Forwarding Information Database (FIB)
an entry for the PPR-ID with the next hop as either the next entry along the
PPR path, or if a loose path is specified, the next hop on the shortest path
to the next hop along the PPR path. This is described in
.PPR also has the ability to inject into a network a tree rooted at
a node identified a PPR-ID. This is described in .
This graph mechanism provides a compact representation of a set of paths to a given PPR-ID.
This works in a similar manner to the linear path case, in which a node on the
graph inserts a FIB entry for the PPR-ID with the next hop as either the
next node in the graph, or the next hop on the shortest path to the next
node in the graph. Clearly the graph needs to be a spanning tree
and must not contain a cycle.In the description of the FRR methods provided in the text, the term
encapsulation (and decapsulation) is frequently used in connection with
the addition (and removal) of a PPR-ID to be used by the forwarding
later to identify to the forwarders the PPR path that the packet needs to
traverse to be follow the repair path. Encapsulation is only one of a number
of methods that can be used and is used in this memo as a convenience
without loss of generality. For more information see .PPR allows the construction of arbitrary engineered backup paths.
In this respect it is like similar to RSVP-TE and Topology Independent Loop-Free Alternates (TI-LFA)
. However, unlike those
approaches PPR is applicable to any forwarding plane. For
example, it is possible to support MPLS, both IPv4 and IPv6 and Ethernet.Like Segment Routing (SR) , PPR uses extensions to the existing IGP,
however, unlike SR, PPR requires
no extension to the data plane. Again, unlike SR, which requires
a Segment Identifier (SID) in the network layer header for every non-shortest path
forwarding instruction, an arbitrary
path does not require expansion of the user data packet beyond that needed
for the initial insertion of the PPR-ID. This mitigates the MTU stress
that SR introduces to the network.PPR based IPFRR supports 100% failure coverage similar to RSVP-TE , TI-LFA,
Maximally Redundant Trees (MRT) and Not-Via . It does not
have the coverage restrictions that apply to Loop-Free Alternate (LFA) and
Remote LFA (RLFA) .Shared Risk Link Groups (SRLGs) make it more difficult find repairs in LFA and RLFA reducing
repair coverage. TI-LFA can address this, but only at a cost of expanding
the number of SIDs and hence the packet size.Supporting multiple concurrent failures is difficult in all of the
IPRFF approaches except MRT, which can repair two concurrent failures.
However unlike MRT, which is constrained by its network wide algorithm,
PPR allows individual, arbitrary repair paths to instantiated, for any
failure.In the current TI-LFA design, priority is given to repairing connectivity
rather than conforming to the operator traffic policy. A PPR based FFR
approach can apply policy to the repaired traffic, including, if required
multiple policies to an individual failure.One of the main advantages of TI-LFA compared to other IPFRR approaches
is that it creates repair paths that are congruent with the post
convergence path from the Point of Local Repair (PLR) to the destination.
These paths, which may be longer than strictly necessary to reach Q-space
, stop micro-loops from forming along the repair path during
re-convergence. PPR can also create these congruent paths without
the need to introduce SR into the network.One of the limitations in TI-LFA, RLFA and LFA is that they do not have a method
of selectively creating alternative next-hops or indeed full repair
paths based on policy, or traffic engineering information known
to the operator. PPR provides a simple way to inject arbitrary paths. It
may therefore be used to enhance an existing LFA/RLFA/TI-LFA IPFRR enabled
network by selectively injecting paths to provide a repair for
business critical links with a policy in the PLR that where provided
a PPR path should be preferred over a local calculated LFA based paths.PPR is applicable to both centralized and PLR computed repair paths
each of which has advantages in different circumstances.
A centrally computed repair path only requires interaction with one network
node which then floods the instruction. This differs from the normal
SDN approach which requires interaction with all of the nodes along the path
and RSVP-TE which requires interaction with at least one end-point of
every repair.Like TI-LFA, pLFA is based on a small extension to the IGP. It uses
the IGP flooding mechanism and in-built state maintenance and consistency
checks. This contrasts with RSVP-TE which needs its own separate
Signaling and soft-state maintenance method.The requirement that the pLFA solution addresses is thus the
ability to construct repair paths that conform to operator policy without
data-plane changes or significant MTU increase, and without introducing
any control plane changes other than a small addition to the existing
IGP.A more detailed technical comparison between pLFA and
the existing solutions is provided in the technical description of
pLFA that follows.In this, the most basic, scenario we assume that we
have a path A-B-C-D that the packet must traverse. This may
be a normal best effort path or a traffic engineered path.PPR is used to inject the repair path B->E->F->G->C
into the network with a PPR-ID of c’. B is monitoring
the health of link B->C, for example looking for loss-of-light, or
using Bidirectional Forwarding Detection (BFD) .
When B detects a failure it encapsulates the packet to
C by adding to the packet the PPR-ID for c’ and sending it to E.
At C the packet is decapsulated and sent to D. The path
C->E->F->G->C may be a traffic engineered path or it may be a best
effort path. B may have at its disposal multiple paths to
C with different properties for different traffic classes.
In this case each path to be used would require its own PPR-ID (c’, c’’ etc).In some circumstances, the repair path may be terminated at
another point in Q-space or at a node between C and D.
For example, in if all costs are 1, F is in Q-space with
respect to a B->C failure (F->G->C cost = 2, whilst F->E->B->C cost = 3)
and thus the packet can safely be encapsulated and send to F with a
PPR-ID of f’. Releasing the packet early in Q-space has two advantages, firstly
the packet can take a shorter path to its destination if one is available
rather than traveling to the far side of the failure and then back tracking.Releasing a packet in Q-space also reduces the size of the PPR path that needs to be advertised, and
potentially allows a repair path to be shared among a number of
failures. For example in G with PPR-ID g’ via B->E->F->G can
be used to provide an IPFRR path for the failure of both
B->C and B->H.Shared paths are useful in reducing the number of PPR paths
that need to be flooded to support FRR.Note that where the packet takes the shortest path to the point
in Q-space that is closest to the destination, it will be taking
a path that is congruent with the post convergence path from the
PLR to the destination. This is the path that TI-LFA chooses
to avoid its loop-free convergence. However this is not
the only loop-free strategy available to a pLFA based
solution.Consider the network fragment shown in taken from
, and consider that node A needs
to deal with the possible failure of node E.Node S needs the use of four repair paths to address the failure of node E,
one repair to each of E’s neighbours for which E is on the path to that
neighbour. In there are three of these next-next-hop
repairs, noted as Repair S-Sx in the figure. In addition a repair
to E (Repair S->E) using a path other than along the path S-E> should
be installed for traffic to E on the basis that the problem may be a
failure of link S->E rather than a failure of the node.The three repair paths to the next-next-hops of E can be installed as
PPR path S-Sx with a PPR-ID of sx’. The link repair for E a PPR path
to E which avoids link S-E with a PPR-ID of e’.A shared risk link group (SRLG) is a set of links that are believed to
have some systematic connection such that when one fails there is
a high probability of all of them failing. This occurs, for example,
where all of the members of the group run in a common cable duct.
Where this relationship is known, and the simultaneous failure does not
partition the network,PPR can install paths such that
all members of the SRLG are avoided. pLFA has fewer constraints than
other methods in constructing arbitrary repair paths in the network.
Section 6.1 describes the SRLG problem as it applies to
IPFRR. pLFA can address all of the cases described in .SRLG avoiding IPFRR paths can be complex. Since a packet can be attracted towards
the failure whenever it is released from a strict path, the
repair path may need a number of segments to steer it safely into
Q-space. If this is done in the data-plane this can stress the MTU.
pLFA creates the path in the control plane and its encapsulation is
invariant with respect to the complexity of the path. Furthermore,
if the need to reduce the data-plane encapsulation side means that
the repair path needs to use a sequence of loose hops it is necessary
to determine the behaviour of each router on the chosen path.
This contrasts with pLFA which can determine the path
using whatever metrics and policy is appropriate, and then simply
impose it without any data-plane overhead beyond that needed for
a simple repair.LANs are a special type of SRLG and are solved using the SRLG
mechanisms outlined above. With all SRLGs, there is a trade-off
between the sophistication of the fault detection and the size of the
SRLG. Section 6.2 describes the LAN problem as it applies to
IPFRR. pLFA can address all of the cases described in .The Multiple Independent Failure cases described in Section 6.3
will be analyzed in a future version of this document.The Multi-Homed Prefix (MHP) problem is described in
Section 6.1, Section 5.3 and .
MHP will be addressed in a future version of this document.Equal Cost Multi-Path (ECMP) is a consideration in any IPFRR
method that does not use strict paths, and can be both an
opportunity and threat. It is an opportunity in that
it allows for the repair traffic to be distributed over
a number of alternative paths to minimize congestion.
If a loose pLFA path is injected into the network,
then any available ECMP paths that fulfill the PPR path
constraints can be installed following the same procedure used in
normal IGP path computation.However, care must be taken that a packet is not in a
position where it is released from a repair at an ECMP
point such that one of the ECMP paths is back via the failure.
This can never happen if the correct definition of Q-space
is used in calculating the repair path.In this approach there are two traffic engineered paths
from A to D (.The primary path A->B->C->D is protected by a traffic
engineered path A->F->G->D (PPR-ID d’) with traffic engineered
connectors from B (B->F) and C (C->G). The
path A->F->G->D and its connectors can be created and injected
by any node with access to the IGP, but it is more likely to
be created by a traffic engineering controller.If link B->C fails, B re-routes packets destined
for D to the traffic engineered path A->F->G->D via
connector B->F. It does this by encapsulating the packet
with a PPR-ID of d’.Clearly there is nothing special needed
to get the packet from B to F as they are adjacent but
if there is a node say X on the path from B to F an explicit
path needs to be created from B to F via X. Normally the
repair would be created as a single PPR path (i.e. B->F->G->D)
with a PPR-ID of d’. In this approach the repair from
A would be A->F->G->D with a PPR-ID of d’ also. Similarly
C-G-D would again share the PPR-ID d’.If preferred the repair path could also be constructed using double
encapsulation or using an SR approach in which the first segment
was B-F with a PPR-ID/SID f’ and the second segment
was F-D with PPR-ID of d’.In the example shown in the proposed B-//->C protection
path was B->F->G->D. This is node protecting on C since the
repair path avoids C. Although link failures tend to be more common than
node failures some critical applications would prefer node protection
where possible. Node avoidance may not
be possible within the network, and may come at a cost of increased
path repair path length. However, whether to include node protection
and as what cost to accept its inclusion is a matter of
network operator policy.The repair constructed in this section required the inclusion
of a set of PPR defined links to construct the repair. PPR
has the ability to construct graphs
which can simplify the specification of the required repair
topology. This is discussed in .PPR has the ability to inject graphs into a network as well as
linear paths .
PPR graphs specify the paths from a set of nodes
to a single node, and are a compact method of representing
a set of paths to that destination with shared properties.In the S bit in the PPR Path Description
Element (PDE) specifies that a
a network node is a Source and a D bit specifies that
it is a destination. A graph with all S bits set on the
leaves and a D bit on the root is a unidirectional tree.Consider the network fragment shown in . A graph
with a PPR-ID d’ is constructed attaching each of the nodes
A, B, and C to D. Should any of the nodes A, B or C fail the
packet can be forwarded on the PPR graph to D with the PPR-ID
of d’. In the unidirectional repair graph A, B, and C are
all sources (signaled with the S bit set), and D is the only
destination (signaled with the D bit set.Consider Figure 1 from which illustrates the
problem of IPFRR in a network that is 2-connected.(a) is the full network, and (b) and (b) are two
corresponding redundant trees from .
Using the Red and Blue trees towards R every node has at least two
paths to R. We give R a PPR-ID of r’ in the Blue tree and a
PPR-ID of r’’ in the Red tree. R is the only destination in the
PPR graph (D bit set), but all other nodes are sources (S bit set).
For clarity this bit setting is not shown in .It is worth
noting what happens at nodes B and D in (b). B is an
ECMP to D via F and C. What happens at node B is a matter of
implementation and operator preference. Either B can choose one
of the next-hops, or it use them as an ECMP pair. It can also
use the availability of the pair to protect against B->F or
B->C being an unexpected SRLG with respect to link A->R.
D is a merge point for traffic destined for r’ arriving from
F and from C. It simply forwards the traffic to r’ as normal.
Similarly in (c) D can sent traffic to r’’ via F or C.Whilst in this example the Red and Blue trees use exactly
the same links and nodes used by the main topology, a repair
graph could use available nodes and links outside this network
fragment.Now consider Figure 2 from which illustrates the
problem of IPFRR in a network that is not 2-connected.Again there are two paths (with PPR-IDs r’ and r’’) to R from all nodes except
that G, J and H all depend on link G->C and node C
which is a single point of failure in the network.Again note that B in the Blue tree and D in the Red
tree has two paths to r’ and r’’ respectively that it may
use according to configuration or preference.pLFA paths can be established through both centralized and decentralized
approaches.A centralized system has a more holistic view of the network and
its policies, its resource constraints and resource usage. A decentralized
system is inherently more resilient to failure and is a good fit where the
network is a simple best effort network as is commonly deployed.A centralized system gathers the network state, just as any
SDN system does, and computes the FRR paths needed. However, unlike
normal SDN operation where the controller needs to individually
instruct every entity on the path for every path, in a PPR network it is
only necessary to inject the PPR path at one point. In practice, for
reliability, it would inject the PPR paths in a small number of places,
and the naturally reliability of the IGP would ensure the complete
distribution of the paths. Furthermore, the system collecting the
network state would naturally send the PPR LSPs back to the SDN
controller providing quality assurance that the FRR paths had been
distributed.In a decentralized approach the pLFA path is computed within
the network, normally by the PLR. Further details of this approach
will be provided in a future version of this document.Each PPR path is independent of all other paths in the network.
This means that there is no constraint on how the path
is calculated, and a different algorithm can be used on every path.
Some of the other FRR approaches have this property, but not all. For
example LFA is constrained by the properties of the base IGP as to
a large degree is RLFA. PPR can incorporate best effort segments
if required, but from a data-plane perspective there is no advantage
in doing so. In this case there is a dependence on the path
choice in the base routing protocol.MRT and Not-Via can use any algorithm to
calculate the repair, but it needs to be common across the network, although
the expectation in the case of Not-Via is that the algorithm would be
a Dijkstra based SPF calculation. In both these cases to change the
algorithm would require turning off FRR for the whole network,
re-configuring and then restarting FRR.RSVP-TE based FRR can specify any path, but at the cost of maintaining
the soft-state.A PLR in a TI-LFA or any SR based approach can also compute paths independent
of each other, but they tend to need to do this as a concatenation of
a series of shortest paths in order to reduce the number of SIDs they
need to form the path. TI-LFA is thus highly dependent on the underlying
best effort paths.pLFA can be used as a method of converting classic LFA or RLFA to full coverage
by providing the paths that these methods are unable to support, or
to provide any the sub-paths needed to reduce the number of TI-LFA SIDs.This section is a survey of a number of data-planes in each case
considering how a PPR-ID could added to map the packet to
required FRR path.Where the data-plane is “traditional” IP the user packet needs to
be encapsulated such that the outer IP address is the PPR-ID.
Any preferred encapsulation can be used such as: IP in IP, IP in GRE,
or IP in UDP.The tunnel capabilities of a node can be advertised
using the method described in allowing
different tunnel types to be used for different PPR paths, depending
on the capability of the various nodes in the network.A common operational issue with this type of encapsulation for IPFRR
has been the shortage of IP addresses. However this is not an issue
in an IPv6 network.Where the data-plane is SRv6
pLFA would be used to steer a packet towards the next segment end-point.
Clearly an extra level of IP encapsulation could be used ,
but that expands the packet by adding at least 36 octets.Where the packet is a “traditional” IP packet, and the repair
end-point is SRv6 capable, an alternative to the methods
described in is to insert an SRH into the IP packet
setting the SID in the SRH to the original packet DA and
replacing the outer DA with the PPR-ID. If this method is
used the semantics of the PPR-ID must include the reconstruction
of the packet, by replacing the DA with the original DA
retrieved from the SRH and the removal of the SRH.Where the data-plane is MPLS any encapsulation needed
is tiny (a label push), but the exact action depends
on the repair strategy, and there is the usual FRR problem
of the setting of the new value for the top label
prior to pushing the PPR-ID label.Where the FRR path terminates at an MPLS node other than
the network egress provider edge (PE) in the type
of pLFA repair described in , the original
top label needed to be set to the label the node was expecting.Consider the network fragment shown in . This is
straight forward case because node B swaps the top label
the label it would have used without the failure and then
pushes the label that corresponds to c’. If the repair strategy
had been to exit Q-space at the earliest opportunity
for example at F, then B would have needed to know what
label F required to reach the destination. A very similar
problem occurs when a node repair is undertaken ,
where S needs to know the label that the next-next-hops (S1, S2 and S3)
need to reach the destination.Where the traffic is being moved to a new path terminating
at the egress PE as shown in , the problem much
simpler and only requires the swapping of the top
label with the label that represents d’.Whilst IPFRR puts in place a temporary network repair, eventually the
network needs to re-converge around the surviving network components. During
this phase there is a danger that micro-loops will form and disrupt the traffic
flowing across the network. A similar problem can occur when the failed
component returns to service, or when a new component is introduced
into the network. describes the problem of loop-free
convergence in detail and examines the methods known at the time of its writing.
Since that time has proposed a timer based loop mitigation (but
not elimination) process, and
has proposed that by making the IPFRR path congruent with the post
convergence path loops can be eliminated along the repair path. However
whilst these mitigation techniques address component failure, neither
are targeted at the repair/new component case.These problems only effect best effort paths and path segments, fully
defined paths do not have this problem.A network using pLFA is compatible with all of the
know loop-free convergence and loop mitigation approaches.PPR may also be used in a way that provides an alternative to running
multi-hop BFD from ingress on a traffic engineered (TE) path with
reducing the complexities that arise from echo reply false alarms.
In this use case pLFA works by locally detecting the failure
and transferring the traffic to preferred TE backups which are
in time replaced by the newly computed TE paths to the same PPR-ID.As noted in pLFA paths are constrained by the routing domain
and thus the traffic will be no more subject to observation than
it would in normal operation. Indeed PPR has the capability to constrain
the path of the traffic more tightly than other IPFRR approaches.
pLFA therefore does not reduce the privacy of user traffic on the network.The security considerations of PPR are discussed in
which in turn refers
the reader to the security considerations of the underlying routing
protocol and the data-plane in use. The pLFA application of PPR to IPFRR
introduces no additional security regarding PPR itself.General IPFRR security considerations are discussed in and these
apply to this solution.One further consideration, is the whether policy that applied to the
original path needs to be applied to the repair path. The decision is
operator and application specific, however pLFA is better than some other
IPFRR solution in that it is possible to precisely choose the repair
path.IPFRR is deployed within the scope of the routing protocol that underpins it
which limits the security vulnerability. Furthermore it is unlikely that
IPFRR would be deployed outside a well managed network. These restrictions
in-turn significantly mitigate any security threat.This document makes no IANA requests.Preferred Path Route Graph StructureThis document defines a graph structure for the Preferred Path Route (PPR) for IS-IS, OSPFv2 and OSPFv3 protocols. This structure helps further scale of the PPR and reduce domain level global entries needed in some data planes.Preferred Path Routing (PPR) in IS-ISThis document specifies Preferred Path Routing (PPR), a routing protocol extension to simplify the path description on the packet for Segment Routing (SR) deployments and beyond. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overhead; and also supports further extensions along the paths.Procedures for Modifying the Resource reSerVation Protocol (RSVP)This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Fast Reroute Extensions to RSVP-TE for LSP TunnelsThis document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]Basic Specification for IP Fast Reroute: Loop-Free AlternatesThis document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]IP Fast Reroute FrameworkThis document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes.A Framework for Loop-Free ConvergenceA micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.Bidirectional Forwarding Detection (BFD)This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]A Framework for IP and MPLS Fast Reroute Using Not-Via AddressesThis document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). 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.Micro-loop Prevention by Introducing a Local Convergence DelayThis document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.The mechanism is limited to the link-down event in order to keep the mechanism simple.Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops.Segment Routing ArchitectureSegment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.Selection of Loop-Free Alternates for Multi-Homed PrefixesDeployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement. This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. This document updates Section 6 of RFC 5286 by expanding some of the routing aspects.Topology Independent Fast Reroute using Segment RoutingThis document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any IGP network. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, dramatically reducing the operational need to control the tie-breaks among various FRR options.IPv6 Segment Routing Header (SRH)Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header. This document describes the Segment Routing Extension Header and how it is used by Segment Routing capable nodes.IP Fast Reroute using tunnelsThis draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented.Advertising Tunnelling Capability in IS-ISSome networks use tunnels for a variety of reasons. A large variety of tunnel types are defined and the ingress needs to select a type of tunnel which is supported by the egress. This document defines how to advertise egress tunnel capabilities in IS-IS Router Capability TLV.