One document matched: draft-ietf-rtgwg-remote-lfa-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-rtgwg-remote-lfa-02" ipr="trust200902">
<front>
<title abbrev="Remote LFA FRR">Remote LFA FRR</title>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater, Green Park,</street>
<city>Reading</city>
<code>RG2 6GB, UK</code>
<country>UK</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>1831 Diegem</city>
<country>Belgium</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
</postal>
<email>sprevidi@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Mike Shand" initials="M" surname="Shand">
<organization>Independent Contributor</organization>
<address>
<postal>
<street></street>
</postal>
<email>imc.shand@gmail.com</email>
</address>
</author>
<author fullname="Ning So" initials="N" surname="So">
<organization>Tata Communications</organization>
<address>
<postal>
<street>Mobile Broadband Services</street>
</postal>
<email>Ning.So@tatacommunications.com</email>
</address>
</author>
<date year="2013" />
<area>Routing Area</area>
<workgroup>Network Working Group</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword>
<abstract>
<t>This draft describes an extension to the basic IP fast re-route
mechanism described in RFC5286 that provides additional backup
connectivity for link failures when none can be provided by the basic
mechanisms.</t>
</abstract>
<note 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">RFC2119</xref>.</t>
</note>
</front>
<middle>
<section title="Terminology">
<t>This draft uses the terms defined in <xref target="RFC5714"></xref>.
This section defines additional terms used in this draft.</t>
<t></t>
<t><list hangIndent="15" style="hanging">
<t hangText="Extended P-space"><vspace blankLines="1" />The union of
the P-space of the neighbours of a specific router with respect to
the protected link.</t>
<t hangText="P-space">P-space is the set of routers reachable from a
specific router without any path (including equal cost path splits)
transiting the protected link.<vspace blankLines="1" />For example,
the P-space of S, is the set of routers that S can reach without
using the protected link S-E.</t>
<t hangText="PQ node">A node which is a member of both the extended
P-space and the Q-space.</t>
<t hangText="Q-space">Q-space is the set of routers from which a
specific router can be reached without any path (including equal
cost path splits) transiting the protected link.</t>
<t hangText="Repair tunnel">A tunnel established for the purpose of
providing a virtual neighbor which is a Loop Free Alternate.</t>
<t hangText="Remote LFA">The tail-end of a repair tunnel. This
tail-end is a member of both the extended-P space the Q space. It is
also termed a “PQ” node.</t>
</list>In this document we use the notation X-Y to mean the path from
X to Y over the link directly connecting X and Y, whilst the notation
X->Y refers to the shortest path from X to Y via some set of
unspecified nodes including the null set (i.e. including over a link
directly connecting X and Y).</t>
</section>
<section title="Introduction">
<t>RFC 5714 <xref target="RFC5714"></xref> describes a framework for IP
Fast Re-route and provides a summary of various proposed IPFRR
solutions. A basic mechanism using loop-free alternates (LFAs) is
described in <xref target="RFC5286"></xref> that provides good repair
coverage in many topologies<xref
target="I-D.filsfils-rtgwg-lfa-applicability"></xref>, especially those
that are highly meshed. However, some topologies, notably ring based
topologies are not well protected by LFAs alone. This is illustrated in
<xref target="ring"></xref> below.</t>
<figure anchor="ring" title="A simple ring topology">
<artwork><![CDATA[
S---E
/ \
A D
\ /
B---C
]]></artwork>
</figure>
<t>If all link costs are equal, the link S-E cannot be fully protected
by LFAs. The destination C is an ECMP from S, and so can be protected
when S-E fails, but D and E are not protectable using LFAs</t>
<t>This draft describes extensions to the basic repair mechanism in
which tunnels are used to provide additional logical links which can
then be used as loop free alternates where none exist in the original
topology. For example if a tunnel is provided between S and C as shown
in <xref target="ring-tunneled"></xref> then C, now being a direct
neighbor of S would become an LFA for D and E. The non-failure traffic
distribution is not disrupted by the provision of such a tunnel since it
is only used for repair traffic and MUST NOT be used for normal
traffic.</t>
<figure anchor="ring-tunneled" title="The addition of a tunnel">
<artwork><![CDATA[
S---E
/ \ \
A \ D
\ \ /
B---C]]></artwork>
</figure>
<t></t>
<t>The use of this technique is not restricted to ring based topologies,
but is a general mechanism which can be used to enhance the protection
provided by LFAs.</t>
<t>This technique describes in this document is directed at providing
repairs in the case of link failures. Considerations regarding node
failures are discussed in <xref target="NF-Sec"></xref>.</t>
</section>
<section title="Repair Paths">
<t>As with LFA FRR, when a router detects an adjacent link failure, it
uses one or more repair paths in place of the failed link. Repair paths
are pre-computed in anticipation of later failures so they can be
promptly activated when a failure is detected.</t>
<t>A tunneled repair path tunnels traffic to some staging point in the
network from which it is assumed that, in the absence of multiple
failures, it will travel to its destination using normal forwarding
without looping back. This is equivalent to providing a virtual
loop-free alternate to supplement the physical loop-free alternates.
Hence the name “Remote LFA FRR”. When a link cannot be
entirely protected with local LFA neighbors, the protecting router seeks
the help of a remote LFA staging point.</t>
<section anchor="TunRepPath" title="Tunnels as Repair Paths">
<t>Consider an arbitrary protected link S-E. In LFA FRR, if a path to
the destination from a neighbor N of S does not cause a packet to loop
back over the link S-E (i.e. N is a loop-free alternate), then S can
send the packet to N and the packet will be delivered to the
destination using the pre-failure forwarding information. If there is
no such LFA neighbor, then S may be able to create a virtual LFA by
using a tunnel to carry the packet to a point in the network which is
not a direct neighbor of S from which the packet will be delivered to
the destination without looping back to S. In this document such a
tunnel is termed a repair tunnel. The tail-end of this tunnel is
called a “remote LFA” or a “PQ node”.</t>
<t>Note that the repair tunnel terminates at some intermediate router
between S and E, and not E itself. This is clearly the case, since if
it were possible to construct a tunnel from S to E then a conventional
LFA would have been sufficient to effect the repair.</t>
</section>
<section title="Tunnel Requirements">
<t>There are a number of IP in IP tunnel mechanisms that may be used
to fulfil the requirements of this design, such as IP-in-IP <xref
target="RFC1853"></xref> and GRE<xref target="RFC1701"></xref> .</t>
<t>In an MPLS enabled network using LDP<xref target="RFC5036"></xref>,
a simple label stack<xref target="RFC3032"></xref> may be used to
provide the required repair tunnel. In this case the outer label is
S's neighbor's label for the repair tunnel end point, and the inner
label is the repair tunnel end point's label for the packet
destination. In order for S to obtain the correct inner label it is
necessary to establish a directed LDP session<xref
target="RFC5036"></xref> to the tunnel end point.</t>
<t>The selection of the specific tunnelling mechanism (and any
necessary enhancements) used to provide a repair path is outside the
scope of this document. The authors simply note that deployment in an
MPLS/LDP environment is extremely simple and straight-forward as an
LDP LSP from S to the PQ node is readily available, and hence does not
require any new protocol extension or design change. This LSP is
automatically established as a basic property of LDP behavior. The
performance of the encapsulation and decapsulation is also excellent
as encapsulation is just a push of one label (like conventional MPLS
TE FRR) and the decapsulation occurs naturally at the penultimate hop
before the PQ node.</t>
<t>When a failure is detected, it is necessary to immediately redirect
traffic to the repair path. Consequently, the repair tunnel used must
be provisioned beforehand in anticipation of the failure. Since the
location of the repair tunnels is dynamically determined it is
necessary to establish the repair tunnels without management action.
Multiple repairs may share a tunnel end point.</t>
</section>
</section>
<section title="Construction of Repair Paths">
<t></t>
<section title="Identifying Required Tunneled Repair Paths">
<t>Not all links will require protection using a tunneled repair path.
Referring to <xref target="ring"></xref>, if E can already be
protected via an LFA, S-E does not need to be protected using a repair
tunnel, since all destinations normally reachable through E must
therefore also be protectable by an LFA. Such an LFA is frequently
termed a "link LFA". Tunneled repair paths are only required for links
which do not have a link LFA.</t>
</section>
<section title="Determining Tunnel End Points">
<t>The repair tunnel endpoint needs to be a node in the network
reachable from S without traversing S-E. In addition, the repair
tunnel end point needs to be a node from which packets will normally
flow towards their destination without being attracted back to the
failed link S-E.</t>
<t>Note that once released from the tunnel, the packet will be
forwarded, as normal, on the shortest path from the release point to
its destination. This may result in the packet traversing the router E
at the far end of the protected link S-E., but this is obviously not
required.</t>
<t>The properties that are required of repair tunnel end points are
therefore:</t>
<t><list style="symbols">
<t>The repair tunneled point MUST be reachable from the tunnel
source without traversing the failed link; and</t>
<t>When released, tunneled packets MUST proceed towards their
destination without being attracted back over the failed link.</t>
</list>Provided both these requirements are met, packets forwarded
over the repair tunnel will reach their destination and will not
loop.</t>
<t>In some topologies it will not be possible to find a repair tunnel
endpoint that exhibits both the required properties. For example if
the ring topology illustrated in <xref target="ring"></xref> had a
cost of 4 for the link B-C, while the remaining links were cost 1,
then it would not be possible to establish a tunnel from S to C
(without resorting to some form of source routing).</t>
<section anchor="CRR" title="Computing Repair Paths">
<t>The set of routers which can be reached from S without traversing
S-E is termed the P-space of S with respect to the link S-E. The
P-space can be obtained by computing a shortest path tree (SPT)
rooted at S and excising the sub-tree reached via the link S-E
(including those which are members of an ECMP). In the case of <xref
target="ring"></xref> the P-space comprises nodes A and B only.
Expressed in cost terms the set of routers {P} are those for which
the shortest path cost S->P is strictly less than the shortest
path cost S->E->P.</t>
<t>The set of routers from which the node E can be reached, by
normal forwarding, without traversing the link S-E is termed the
Q-space of E with respect to the link S-E. The Q-space can be
obtained by computing a reverse shortest path tree (rSPT) rooted at
E, with the sub-tree which traverses the failed link excised
(including those which are members of an ECMP). The rSPT uses the
cost towards the root rather than from it and yields the best paths
towards the root from other nodes in the network. In the case of
<xref target="ring"></xref> the Q-space comprises nodes C and D
only. Expressed in cost terms the set of routers {Q} are those for
which the shortest path cost E->Q is strictly less than the
shortest path cost E->S->Q. In <xref target="ring"></xref> the
intersection of the E's Q-space with S's P-space defines the set of
viable repair tunnel end-points, known as "PQ nodes". As can be
seen, for the case of <xref target="ring"></xref> there is no common
node and hence no viable repair tunnel end-point.</t>
<t>Note that the Q-space calculation could be conducted for each
individual destination and a per-destination repair tunnel end point
determined. However this would, in the worst case, require an SPF
computation per destination which is not currently considered to be
scalable. We therefore use the Q-space of E as a proxy for the
Q-space of each destination. This approximation is obviously correct
since the repair is only used for the set of destinations which
were, prior to the failure, routed through node E. This is analogous
to the use of link-LFAs rather than per-prefix LFAs.</t>
</section>
<section title="Extended P-space">
<t>The description in <xref target="CRR"></xref> calculated router
S's P-space rooted at S itself. However, since router S will only
use a repair path when it has detected the failure of the link S-E,
the initial hop of the repair path need not be subject to S's normal
forwarding decision process. Thus we introduce the concept of
extended P-space. Router S's extended P-space is the union of the
P-spaces of each of S's neighbours. This may be calculated by
computing the an SPT at each of S's neighbors (N) (excluding E) and
excising the subtree reached via the path N->S->E. The use of
extended P-space may allow router S to reach potential repair tunnel
end points that were otherwise unreachable. In cost terms a router
is in extended P-space if the shortest path cost S-N->P is
strictly less than the shortest path cost S-E->P.</t>
<t>Another way to describe extended P-space is that it is the union
of ( un-extended ) P-space and the set of destinations for which S
has a per-prefix LFA protecting the link S-E. i.e. the repair tunnel
end point can be reached either directly or using a per-prefix
LFA.</t>
<t>Since in the case of <xref target="ring"></xref> node A is a
per-prefix LFA for the destination node C, the set of extended
P-space nodes comprises nodes A, B and C. Since node C is also in
E's Q-space, there is now a node common to both extended P-space and
Q-space which can be used as a repair tunnel end-point to protect
the link S-E.</t>
</section>
<section title="Selecting Repair Paths">
<t>The mechanisms described above will identify all the possible
repair tunnel end points that can be used to protect a particular
link. In a well-connected network there are likely to be multiple
possible release points for each protected link. All will deliver
the packets correctly so, arguably, it does not matter which is
chosen. However, one repair tunnel end point may be preferred over
the others on the basis of path cost or some other selection
criteria.</t>
<t>There is no technical requirement for the selection criteria to
be consistent across all routers, but such consistency may be
desirable from an operational point of view. In general there are
advantages in choosing the repair tunnel end point closest (shortest
metric) to S. Choosing the closest maximises the opportunity for the
traffic to be load balanced once it has been released from the
tunnel. For consistency in behavior is RECOMMENDED that member of
the set of routers {P} with the lowest cost S->P be the default
choice for P. In the event of a tie the router with the lowest node
identifier SHOULD be selected.</t>
</section>
</section>
</section>
<section title="Example Application of Remote LFAs">
<t>An example of a commonly deployed topology which is not fully
protected by LFAs alone is shown in <xref target="biasedsquare"></xref>.
PE1 and PE2 are connected in the same site. P1 and P2 may be
geographically separated (inter-site). In order to guarantee the lowest
latency path from/to all other remote PEs, normally the shortest path
follows the geographical distance of the site locations. Therefore, to
ensure this, a lower IGP metric (5) is assigned between PE1 and PE2. A
high metric (1000) is set on the P-PE links to prevent the PEs being
used for transit traffic. The PEs are not individually dual-homed in
order to reduce costs.</t>
<t>This is a common topology in SP networks.</t>
<t>When a failure occurs on the link between PE1 and P2, PE1 does not
have an LFA for traffic reachable via P1. Similarly, by symmetry, if the
link between PE2 and P1 fails, PE2 does not have an LFA for traffic
reachable via P2.</t>
<t>Increasing the metric between PE1 and PE2 to allow the LFA would
impact the normal traffic performance by potentially increasing the
latency.</t>
<figure anchor="biasedsquare" title="Example SP topology">
<artwork><![CDATA[ | 100 |
-P2---------P1-
\ /
1000 \ / 1000
PE1---PE2
5]]></artwork>
</figure>
<t></t>
<t>Clearly, full protection can be provided, using the techniques
described in this draft, by PE1 choosing P2 as a PQ node, and PE2
choosing P1 as a PQ node.</t>
</section>
<section anchor="NF-Sec" title="Node Failures">
<t>When the failure is a node failure rather than a link failure there
is a danger that the RLFA repair will loop. This is discussed in detail
in <xref target="I-D.bryant-ipfrr-tunnels"></xref>. In summary problem
is that two of more of E's neighbors each with E as the next hop to some
destination D may attempt to repair a packet addressed to destination D
via the other neighbor and then E, thus causing a loop to form. As will
be noted from <xref target="I-D.bryant-ipfrr-tunnels"></xref>, this can
rapidly become a complex problem to address.</t>
<t>There are a number of ways to minimize the probability of a loop
forming when a node failure occurs and there exists the possibility that
two of E's neighbors may form a mutual repair.</t>
<t><list style="numbers">
<t>Detect when a packet has arrived on some interface I that is also
the interface used to reach the first hop on the RLFA path to PQ,
and drop the packet. This is useful in the case of a ring
topology.</t>
<t>Require that the path from PQ to destination D never passes
through E (including in the ECMP case), i.e. only use node
protecting paths in which the cost PQ to D is strictly less than the
cost PQ to E plus the cost E to D.</t>
<t>Require that where the packet may pass through another neighbor
of E, that node is down stream (i.e. strictly closer to D than the
repairing node). This means that some neighbor of E (X) can repair
via some other neighbor of E (Y), but Y cannot repair via X.</t>
</list>Case 1 accepts that loops may form and suppresses them by
dropping packets. Dropping packets may be considered less detrimental
than looping packets. Cases 2 and 3 above prevent the formation of a
loop, but at the expense of a reduced repair coverage and at the cost of
additional complexity in the algorithm to compute the repair path.</t>
<t>The probability of a node failure and the consequences of node
failure in any particular topology will depend on the node design, the
particular topology in use, and node failure strategy (including the
null strategy). It is recommended that a network operator perform an
analysis of the consequences and probability of node failure in their
network, and determine whether the incidence and consequence of
occurrence are acceptable.</t>
</section>
<section title="Operation in an LDP environment">
<t>Where this technique is used in an MPLS network using LDP <xref
target="RFC5036"> </xref>, S will need to push two labels onto the
repair packet. First it needs to push PQ's label to the destination, and
then it needs to push its own label for PQ. In the example <xref
target="TunRepPath"></xref> S already has the first hop (B) label for
the PQ node (C) as a result of the ordinary operation of LDP. To get the
PQ node (C) label for the destination (D), S needs to establish a
targeted LDP session with C. The label stack for normal operation and
RLFA operation is shown below in <xref target="LDPS"></xref>.</t>
<figure anchor="LDPS">
<artwork><![CDATA[+-----------------+ +-----------------+ +-----------------+
| datalink | | datalink | | datalink |
+-----------------+ +-----------------+ +-----------------+
| S's label for D | | E's label for D | | C's label for D |
+-----------------+ +-----------------+ +-----------------+
| Payload | | Payload | | B's label for C |
+-----------------+ +-----------------+ +-----------------+
X Y | Payload |
+-----------------+
Z
X = Normal label stack packet arriving at S
Y = Normal label stack packet leaving S
Z = RLFA label stack to D via C as PQ node
]]></artwork>
</figure>
<t></t>
<t>To establish an targeted LDP session with a candidate PQ node the
repairing node (S) needs to know what IP address PQ is willing to use
for targeted LDP sessions. This in turn requires PQ to advertise this
address in the IGP in use. What address is used, how this is advertised
in the IGP, and whether this is a special IP address or an IP address
also used for some other purpose is out of scope for this document and
must be specified in an IGP specific RFC.</t>
</section>
<section title="Historical Note">
<t>The basic concepts behind Remote LFA were invented in 2002 and were
later included in <xref target="I-D.bryant-ipfrr-tunnels"></xref>,
submitted in 2004.</t>
<t><xref target="I-D.bryant-ipfrr-tunnels"></xref>, targeted a 100%
protection coverage and hence included additional mechanisms on top of
the Remote LFA concept. The addition of these mechanisms made the
proposal very complex and computationally intensive and it was therefore
not pursued as a working group item.</t>
<t>As explained in <xref
target="I-D.filsfils-rtgwg-lfa-applicability"></xref>, the purpose of
the LFA FRR technology is not to provide coverage at any cost. A
solution for this already exists with MPLS TE FRR. MPLS TE FRR is a
mature technology which is able to provide protection in any topology
thanks to the explicit routing capability of MPLS TE.</t>
<t>The purpose of LFA FRR technology is to provide for a simple FRR
solution when such a solution is possible. The first step along this
simplicity approach was “local” LFA <xref
target="RFC5286"></xref>. We propose “Remote LFA” as a
natural second step. The following section motivates its benefits in
terms of simplicity, incremental deployment and significant coverage
increase.</t>
</section>
<section title="Benefits">
<t>Remote LFAs preserve the benefits of RFC5286: simplicity, incremental
deployment and good protection coverage.</t>
<section title="Simplicity">
<t>The remote LFA algorithm is simple to compute.<list style="symbols">
<t>The extended P space does not require any new computation (it
is known once per-prefix LFA computation is completed).</t>
<t>The Q-space is a single reverse SPF rooted at the neighbor.</t>
<t>The directed LDP session is automatically computed and
established.</t>
</list></t>
<t>In edge topologies (square, ring), the directed LDP session
position and number is deterministic and hence troubleshooting is
simple.</t>
<t>In core topologies, our simulation indicates that the 90th
percentile number of LDP sessions per node to achieve the significant
Remote LFA coverage observed in section 7.3 is <= 6. This is
insignificant compared to the number of LDP sessions commonly deployed
per router which is frequently is in the several hundreds.</t>
</section>
<section title="Incremental Deployment">
<t>The establishment of the directed LDP session to the PQ node does
not require any new technology on the PQ node. Indeed, routers
commonly support the ability to accept a remote request to open a
directed LDP session. The new capability is restricted to the
Remote-LFA computing node (the originator of the LDP session).</t>
</section>
<section title="Significant Coverage Extension">
<t>The previous sections have already explained how Remote LFAs
provide protection for frequently occurring edge topologies: square
and rings. In the core, we extend the analysis framework in section
4.3 of <xref target="I-D.filsfils-rtgwg-lfa-applicability"></xref>and
provide hereafter the Remote LFA coverage results for the 11
topologies:</t>
<t></t>
<figure>
<artwork><![CDATA[+----------+--------------+----------------+------------+
| Topology | Per-link LFA | Per-prefix LFA | Remote LFA |
+----------+--------------+----------------+------------+
| T1 | 45% | 77% | 78% |
| T2 | 49% | 99% | 100% |
| T3 | 88% | 99% | 99% |
| T4 | 68% | 84% | 92% |
| T5 | 75% | 94% | 99% |
| T6 | 87% | 99% | 100% |
| T7 | 16% | 67% | 96% |
| T8 | 87% | 100% | 100% |
| T9 | 67% | 80% | 98% |
| T10 | 98% | 100% | 100% |
| T11 | 59% | 77% | 95% |
| Average | 67% | 89% | 96% |
| Median | 68% | 94% | 99% |
+----------+--------------+----------------+------------+
]]></artwork>
</figure>
<t>Another study<xref target="ISOCORE2010"></xref> confirms the
significant coverage increase provided by Remote LFAs.</t>
</section>
</section>
<section title="Complete Protection">
<t>As shown in the previous table, Remote LFA provides for 96% average
(99% median) protection in the 11 analyzed SP topologies.</t>
<t>In an MPLS network, this is achieved without any scalability impact
as the tunnels to the PQ nodes are always present as a property of an
LDP-based deployment.</t>
<t>In the very few cases where P and Q spaces have an empty
intersection, one could select the closest node in the Q space and
signal an explicitely-routed RSVP TE LSP to that Q node. A directed LDP
session is then established with the selected Q node and the rest of the
solution is identical to that described elsewhere in this document.</t>
<t>The drawbacks of this solution are:</t>
<t><list style="numbers">
<t>only available for MPLS network;</t>
<t>the addition of LSPs in the SP infrastructure.</t>
</list></t>
<t>This extension is described for exhaustivity. In practice, the
"Remote LFA" solution should be preferred for three reasons: its
simplicity, its excellent coverage in the analyzed backbones and its
complete coverage in the most frequent access/aggregation topologies
(box or ring).</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations that arise from this architectural
description of IPFRR. The RFC Editor may remove this section on
publication.</t>
</section>
<section anchor="SecurityConsids" title="Security Considerations ">
<t>The security considerations of RFC 5286 also apply.</t>
<t>To prevent their use as an attack vector the repair tunnel endpoints
SHOULD be assigned from a set of addresses that are not reachable from
outside the routing domain.</t>
</section>
<section title="Acknowledgments">
<t>The authors acknowledge the technical contributions made to this work
by Stefano Previdi.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="ISOCORE2010">
<front>
<title>LFA (Loop Free Alternates) Case Studies in Verizon's LDP
Network</title>
<author fullname="Ning So, Tony Lin and Connie Chen" initials="N"
surname="So">
<organization></organization>
</author>
<author initials="T" surname="Lin">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="C" surname="Chen">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date year="2010" />
</front>
</reference>
<?rfc include="reference.RFC.5036"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.1701"?>
<?rfc include="reference.RFC.1853"?>
<?rfc include="reference.RFC.3032"?>
<?rfc include="reference.RFC.5286"?>
<?rfc include="reference.RFC.5714"?>
<?rfc include="reference.I-D.filsfils-rtgwg-lfa-applicability"?>
<?rfc include="reference.I-D.bryant-ipfrr-tunnels"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:57:05 |