One document matched: draft-ietf-rtgwg-ipfrr-notvia-addresses-02.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 BFD SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfd-base.xml">
<!ENTITY GRE SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1701.xml">
<!ENTITY IPFRR SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-ipfrr-framework.xml">
<!ENTITY IPIP SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2003.xml">
<!ENTITY L2TPv3 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY LDP SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY BASE SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-ipfrr-spec-base.xml">
<!ENTITY NNHL SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shen-mpls-ldp-nnhop-label.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="yes" ?>
<!-- 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-ipfrr-notvia-addresses-02.txt"
ipr="full3978" updates="">
<!-- 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>IP Fast Reroute Using Not-via Addresses</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Mike Shand" initials="M." surname="Shand">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater Avenue.</street>
<!-- Reorder these if your country does things differently -->
<city>Reading</city>
<region>Berks</region>
<code>RG2 6GB</code>
<country>UK</country>
</postal>
<email>mshand@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater Avenue.</street>
<city>Reading</city>
<region>Berks</region>
<code>RG2 6GB</code>
<country>UK</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Via Del Serafico, 200</street>
<city>00142 Rome</city>
<region></region>
<code></code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<date year="2008" />
<!-- 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 -->
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This draft describes a mechanism that provides fast reroute in an IP
network through encapsulation to "not-via" addresses. A single level of
encapsulation is used. The mechanism protects unicast, multicast and LDP
traffic against link, router and shared risk group failure, regardless
of network topology and metrics.</t>
</abstract>
</front>
<middle>
<section title="Conventions used in this document">
<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 RFC 2119 <xref
target="RFC2119"></xref>.</t>
<t></t>
</section>
<section title="Introduction">
<t></t>
<t>When a link or a router fails, only the neighbors of the failure are
initially aware that the failure has occurred. In a network operating IP
fast reroute <xref target="I-D.ietf-rtgwg-ipfrr-framework"></xref>, the
routers that are the neighbors of the failure repair the failure. These
repairing routers have to steer packets to their destinations despite
the fact that most other routers in the network are unaware of the
nature and location of the failure.</t>
<t>A common limitation in most IPFRR mechanisms is an inability to
indicate the identity of the failure and to explicitly steer the
repaired packet round the failure. The extent to which this limitation
affects the repair coverage is topology dependent. The mechanism
proposed here is to encapsulate the packet to an address that explicitly
identifies the network component that the repair must avoid. This
produces a repair mechanism, which, provided the network is not
partitioned by the failure, will always achieve a repair.</t>
</section>
<section title="Overview of Not-via Repairs">
<t></t>
<t>When a link or a router fails, only the neighbors of the failure are
initially aware that the failure has occurred. In a network operating IP
fast reroute <xref target="I-D.ietf-rtgwg-ipfrr-framework"></xref>, the
routers that are the neighbors of the failure repair the failure. These
repairing routers have to steer packets to their destinations despite
the fact that most other routers in the network are unaware of the
nature and location of the failure.</t>
<t>A common limitation in most IPFRR mechanisms is an inability to
indicate the identity of the failure and to explicitly steer the
repaired packet round the failure. The extent to which this limitation
affects the repair coverage is topology dependent. The mechanism
proposed here is to encapsulate the packet to an address that explicitly
identifies the network component that the repair must avoid. This
produces a repair mechanism, which, provided the network is not
partitioned by the failure, will always achieve a repair.</t>
<t></t>
<figure anchor="fig-repair" title="Not-via repair of router failure">
<preamble></preamble>
<artwork><![CDATA[ A
| Bp is the address to use to get
| a packet to B not-via P
|
S----------P----------B. . . . . . . . . .D
\ | Bp^
\ | |
\ | |
\ C |
\ |
----------------+
Repair to Bp
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t></t>
<t>Assume that S has a packet for some destination D that it would
normally send via P and B, and that S suspects that P has failed. S
encapsulates the packet to Bp. The path from S to Bp is the shortest
path from S to B not going via P. If the network contains a path from S
to B that does not transit router P, i.e. the network is not partitioned
by the failure of P, then the packet will be successfully delivered to
B. When the packet addressed to Bp arrives at B, B removes the
encapsulation and forwards the repaired packet towards its final
destination.</t>
<t>Note that if the path from B to the final destination includes one or
more nodes that are included in the repair path, a packet may back track
after the encapsulation is removed. However, because the decapsulating
router is always closer to the packet destination than the encapsulating
router, the packet will not loop.</t>
<t>For complete protection, all of P's neighbors will require a not-via
address that allows traffic to be directed to them without traversing P.
This is shown in <xref target="fig-notvia-P"></xref>.</t>
<figure anchor="fig-notvia-P" title="The set of Not-via P Addresses ">
<preamble></preamble>
<artwork><![CDATA[ A
|Ap
|
Sp Pa|Pb
S----------P----------B
Ps|Pc Bp
|
Cp|
C
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<section title="Use of Equal Cost Multi-Path">
<t></t>
<t>A router can use an equal cost multi-path (ECMP) repair in place of
a not-via repair.</t>
<t>A router computing a not-via repair path MAY subject the repair to
ECMP.</t>
</section>
<section title="Use of LFA repairs">
<t></t>
<t>The not-via approach provides complete repair coverage and
therefore may be used as the sole repair mechanism. There are,
however, advantages in using not-via in combination with loop free
alternates (LFA) and or downstream paths as documented in <xref
target="I-D.ietf-rtgwg-ipfrr-spec-base"></xref>.</t>
<t>LFAs are computed on a per destination basis and in general, only a
subset of the destinations requiring repair will have a suitable LFA
repair. In this case, those destinations which are repairable by LFAs
are so repaired and the remainder of the destinations are repaired
using the not-via encapsulation. This has the advantage of reducing
the volume of traffic that requires encapsulation. On the other hand,
the path taken by an LFA repair may be less optimal than that of the
equivalent not-via repair for traffic destined to nodes close to the
far end of the failure, but may be more optimal for some other
traffic. The description in this document assumes that LFAs will be
used where available, but the distribution of repairs between the two
mechanisms is a local implementation choice.</t>
</section>
</section>
<section title="Not-via Repair Path Computation ">
<t></t>
<t>The not-via repair mechanism requires that all routers on the path
from S to B (<xref target="fig-repair"></xref>) have a route to Bp. They
can calculate this by failing node P, running an SPF, and finding the
shortest route to B.</t>
<t>A router has no simple way of knowing whether it is on the shortest
path for any particular repair. It is therefore necessary for every
router to calculate the path it would use in the event of any possible
router failure. Each router therefore "fails" every router in the
network, one at a time, and calculates its own best route to each of the
neighbors of that router. In other words, with reference to <xref
target="fig-repair"></xref>, some router X will consider each router in
turn to be P, fail P, and then calculate its own route to each of the
not-via P addresses advertised by the neighbors of P. i.e. X calculates
its route to Sp, Ap, Bp, and Cp, in each case, not via P.</t>
<t>To calculate the repair paths a router has to calculate n-1 SPFs
where n is the number of routers in the network. This is expensive to
compute. However, the problem is amenable to a solution in which each
router (X) proceeds as follows. X first calculates the base topology
with all routers functional and determines its normal path to all
not-via addresses. This can be performed as part of the normal SPF
computation. For each router P in the topology, X then performs the
following actions:-</t>
<t><list style="numbers">
<t>Removes router P from the topology.</t>
<t>Performs an incremental SPF <xref target="ISPF"></xref> on the
modified topology. The iSPF process involves detaching the sub-tree
affected by the removal of router P, and then re-attaching the
detached nodes. However, it is not necessary to run the iSPF to
completion. It is sufficient to run the iSPF up to the point where
all of the nodes advertising not-via P addresses have been
re-attached to the SPT, and then terminate it.</t>
<t>Reverts to the base topology.</t>
</list>This algorithm is significantly less expensive than a set of
full SPFs. Thus, although a router has to calculate the repair paths for
n-1 failures, the computational effort is much less than n-1 SPFs.</t>
<t>Experiments on a selection of real world network topologies with
between 40 and 400 nodes suggest that the worst-case computational
complexity using the above optimizations is equivalent to performing
between 5 and 13 full SPFs. Further optimizations are described in
section 6.</t>
<section title="Computing not-via repairs in routing vector protocols">
<t></t>
<t>While this document focuses on link state routing protocols, it is
equally possible to compute not-via repairs in distance vector (e.g.
RIP) or path vector (e.g. BGP) routing protocols. This can be achieved
with very little protocol modification by advertising the not-via
address in the normal way, but ensuring that the information about a
not-via address Ps is not propagated through the node S. In the case
of link protection this simply means that the advertisement from P to
S is suppressed, with the result that S and all other nodes compute a
route to Ps which doesn't traverse S, as required.</t>
<t>In the case of node protection, where P is the protected node, and
N is some neighbor, the advertisement of Np must be suppressed not
only across the link N->P, but also across any link to P. The
simplest way of achieving this is for P itself to perform the
suppression of any address of the form Xp.</t>
</section>
</section>
<section title="Operation of Repairs">
<t>This section explains the basic operation of the not-via repair of
node and link failure.</t>
<section title="Node Failure">
<t></t>
<t>When router P fails (<xref target="fig-notvia-P"></xref>) S
encapsulates any packet that it would send to B via P to Bp, and then
sends the encapsulated packet on the shortest path to Bp. S follows
the same procedure for routers A and C in <xref
target="fig-notvia-P"></xref>. The packet is decapsulated at the
repair target (A, B or C) and then forwarded normally to its
destination. The repair target can be determined as part of the normal
SPF by recording the "next-next-hop" for each destination in addition
to the normal next-hop.</t>
<t>Notice that with this technique only one level of encapsulation is
needed, and that it is possible to repair ANY failure regardless of
link metrics and any asymmetry that may be present in the network. The
only exception to this is where the failure was a single point of
failure that partitioned the network, in which case ANY repair is
clearly impossible.</t>
</section>
<section title="Link Failure">
<t></t>
<t>The normal mode of operation of the network would be to assume
router failure. However, where some destinations are only reachable
through the failed router, it is desirable that an attempt be made to
repair to those destinations by assuming that only a link failure has
occurred.</t>
<t>To perform a link repair, S encapsulates to Ps (i.e. it instructs
the network to deliver the packet to P not-via S). All of the
neighbors of S will have calculated a path to Ps in case S itself had
failed. S could therefore give the packet to any of its neighbors
(except, of course, P). However, S should preferably send the
encapsulated packet on the shortest available path to P. This path is
calculated by running an SPF with the link SP failed. Note that this
may again be an incremental calculation, which can terminate when
address Ps has been reattached.</t>
<t>It is necessary to consider the behavior of IPFRR solutions when a
link repair is attempted in the presence of node failure. In its
simplest form the not-via IPFRR solution prevents the formation of
loops forming as a result of mutual repair, by never providing a
repair path for a not-via address. Referring to <xref
target="fig-notvia-P"></xref>, if A was the neighbor of P that was on
the link repair path from S to P, and P itself had failed, the
repaired packet from S would arrive at A encapsulated to Ps. A would
have detected that the AP link had failed and would normally attempt
to repair the packet. However, no repair path is provided for any
not-via address, and so A would be forced to drop the packet, thus
preventing the formation of loop.</t>
<t></t>
</section>
<section title="Multi-homed Prefixes">
<t></t>
<t>A multi-homed Prefix (MHP) is a prefix that is reachable via more
than one router in the network. Some of these may be repairable using
LFAs as described in <xref
target="I-D.ietf-rtgwg-ipfrr-spec-base"></xref>. Only those without
such a repair need be considered here.</t>
<t>When IPFRR router S (<xref target="fig-MHP"></xref>) discovers that
P has failed, it needs to send packets addressed to the MHP X, which
is normally reachable through P, to an alternate router, which is
still able to reach X.</t>
<figure anchor="fig-MHP" title="Multi-homed Prefixes">
<preamble></preamble>
<artwork><![CDATA[ X X X
| | |
| | |
| Sp |Pb |
Z...............S----------P----------B...............Y
Ps|Pc Bp
|
Cp|
C ]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>S should choose the closest router that can reach X during the
failure as the alternate router. S determines which router to use as
the alternate while running the SPF with P failed. This is
accomplished by the normal process of re-attaching a leaf node to the
core topology (this is sometimes known as a "partial SPF").</t>
<t>First, consider the case where the shortest alternate path to X is
via Z. S can reach Z without using the failed router P. However, S
cannot just send the packet towards Z, because the other routers in
the network will not be aware of the failure of P, and may loop the
packet back to S. S therefore encapsulates the packet to Z (using a
normal address for Z). When Z receives the encapsulated packet it
removes the encapsulation and forwards the packet to X.</t>
<t>Now consider the case where the shortest alternate path to X is via
Y, which S reaches via P and B. To reach Y, S must first repair the
packet to B using the normal not-via repair mechanism. To do this S
encapsulates the packet for X to Bp. When B receives the packet it
removes the encapsulation and discovers that the packet is intended
for MHP X. The situation now reverts to the previous case, in which
the shortest alternate path does not require traversal of the failure.
B therefore follows the algorithm above and encapsulates the packet to
Y (using a normal address for Y). Y removes the encapsulation and
forwards the packet to X.</t>
<t>It may be that the cost of reaching X using local delivery from the
alternate router (i.e. Z or Y) is greater than the cost of reaching X
via P. Under those circumstances, the alternate router would normally
forward to X via P, which would cause the IPFRR repair to loop. To
prevent the repair from looping the alternate router must locally
deliver a packet received via a repair encapsulation. This may be
specified by using a special address with the above semantics. Note
that only one such address is required per node. Notice that using the
not-via approach, only one level of encapsulation was needed to repair
MHPs to the alternate router.</t>
</section>
<section title="Installation of Repair Paths ">
<t></t>
<t>The following algorithm is used by node S (<xref
target="fig-MHP"></xref>) to pre- calculate and install repair paths
in the FIB, ready for immediate use in the event of a failure. It is
assumed that the not-via repair paths have already been calculated as
described above.</t>
<t>For each neighbor P, consider all destinations which are reachable
via P in the current topology:-</t>
<t><list style="numbers">
<t>For all destinations with an ECMP or LFA repair (as described
in <xref target="I-D.ietf-rtgwg-ipfrr-spec-base"></xref>) install
that repair.</t>
<t>For each destination (DR) that remains, identify in the current
topology the next-next-hop (H) (i.e. the neighbor of P that P will
use to send the packet to DR). This can be determined during the
normal SPF run by recording the additional information. If S has a
path to the not-via address Hp (H not via P), install a not-via
repair to Hp for the destination DR.</t>
<t>Identify all remaining destinations (M) which can still be
reached when node P fails. These will be multi-homed prefixes that
are not repairable by LFA, for which the normal attachment node is
P, or a router for which P is a single point of failure, and have
an alternative attachment point that is reachable after P has
failed. One way of determining these destinations would be to run
an SPF rooted at S with node P removed, but an implementation may
record alternative attachment points during the normal SPF run. In
either case, the next best point of attachment can also be
determined for use in step (4) below.</t>
<t>For each multi-homed prefix (M) identified in step (3):-<list
style="letters">
<t>Identify the new attachment node (as shown in <xref
target="fig-MHP"></xref>). This may be:-<list style="letters">
<t>Y, where the next hop towards Y is P, or</t>
<t>Z, where the next hop towards Z is not P.</t>
</list>If the attachment node is Z, install the repair for M
as a tunnel to Z' (where Z' is the address of Z that is used
to force local forwarding).</t>
<t>For the subset of prefixes (M) that remain (having
attachment point Y), install the repair path previously
installed for destination Y.</t>
</list>For each destination (DS) that remains, install a not-via
repair to Ps (P not via S). Note, these are destinations for which
node P is a single point of failure, and can only be repaired by
assuming that the apparent failure of node P was simply a failure
of the S-P link. Note that, if available, a downstream path to P
may be used for such a repair. This cannot generate a persistent
loop in the event of the failure of node P, but if one neighbor of
P uses a not-via repair and another uses a downstream path, it is
possible for a packet sent on the downstream path to be returned
to the sending node inside a not-via encapsulation. Since packets
destined to not-via addresses are not repaired, the packet will be
dropped after executing a single turn loop.</t>
</list></t>
</section>
</section>
<section title="Compound Failures">
<t>The following types of failures involve more tha one component.</t>
<section title="Shared Risk Link Groups">
<t></t>
<t>A Shared Risk Link Group (SRLG) is a set of links whose failure can
be caused by a single action such as a conduit cut or line card
failure. When repairing the failure of a link that is a member of an
SRLG, it must be assumed that all the other links that are also
members of the SRLG have also failed. Consequently, any repair path
must be computed to avoid not just the adjacent link, but also all the
links which are members of the same SRLG.</t>
<t>In <xref target="fig-SRLG1"></xref> below, the links S-P and A-B
are both members of SRLG "a". The semantics of the not-via address Ps
changes from simply "P not-via the link S-P" to be "P not-via the link
S-P or any other link with which S-P shares an SRLG" In <xref
target="fig-SRLG1"></xref> this is the links that are members of SRLG
"a". I.e. links S-P and A-B. Since the information about SRLG
membership of all links is available in the Link State Database, all
nodes computing routes to the not-via address Ps can infer these
semantics, and perform the computation by failing all the links in the
SRLG when running the iSPF.</t>
<t>Note that it is not necessary for S to consider repairs to any
other nodes attached to members of the SRLG (such as B). It is
sufficient for S to repair to the other end of the adjacent link (P in
this case).</t>
<figure anchor="fig-SRLG1" title="Shared Risk Link Group ">
<preamble></preamble>
<artwork><![CDATA[ a Ps
S----------P---------D
| |
| a |
A----------B
| |
| |
C----------E ]]></artwork>
<postamble></postamble>
</figure>
<t>In some cases, it may be that the links comprising the SRLG occur
in series on the path from S to the destination D, as shown in <xref
target="fig-SRLG2"></xref>. In this case, multiple consecutive repairs
may be necessary. S will first repair to Ps, then P will repair to Dp.
In both cases, because the links concerned are members of SRLG "a" the
paths are computed to avoid all members of SRLG "a".</t>
<figure anchor="fig-SRLG2"
title="Shared Risk Link Group members in series">
<preamble></preamble>
<artwork><![CDATA[ a Ps a Dp
S----------P---------D
| | |
| a | |
A----------B |
| | |
| | |
C----------E---------F ]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>While the use of multiple repairs in series introduces some
additional overhead, these semantics avoid the potential combinatorial
explosion of not-via addresses that could otherwise occur.</t>
<t>Note that although multiple repairs are used, only a single level
of encapsulation is required. This is because the first repair packet
is de-capsulated before the packet is re-encapsulated using the not-
via address corresponding to the far side of the next link which is a
member of the same SRLG. In some cases the de-capsulation and re-
encapsulation takes place (at least notionally) at a single node,
while in other cases, these functions may be performed by different
nodes. This scenario is illustrated in <xref
target="fig-SRLG3"></xref> below.</t>
<figure anchor="fig-SRLG3"
title="Shared Risk Link Group members in series ">
<preamble></preamble>
<artwork><![CDATA[ a Ps a Dg
S----------P---------G--------D
| | | |
| a | | |
A----------B | |
| | | |
| | | |
C----------E---------F--------H
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>In this case, S first encapsulates to Ps, and node P decapsulates
the packet and forwards it "native" to G using its normal FIB entry
for destination D. G then repairs the packet to Dg.</t>
<t>It can be shown that such multiple repairs can never form a loop
because each repair causes the packet to move closer to its
destination.</t>
<t>It is often the case that a single link may be a member of multiple
SRLGs, and those SRLG may not be isomorphic. This is illustrated in
<xref target="fig-SRLG4"></xref> below.</t>
<figure anchor="fig-SRLG4" title="Multiple Shared Risk Link Groups ">
<preamble></preamble>
<artwork><![CDATA[ ab Ps a Dg
S----------P---------G--------D
| | | |
| a | | |
A----------B | |
| | | |
| b | | b |
C----------E---------F--------H
| |
| |
J----------K ]]></artwork>
<postamble></postamble>
</figure>
<t>The link SP is a member of SRLGs "a" and "b". When a failure of the
link SP is detected, it must be assumed that BOTH SRLGs have failed.
Therefore the not-via path to Ps must be computed by failing all links
which are members of SRLG "a" or SRLG "b". I.e. the semantics of Ps is
now "P not-via any links which are members of any of the SRLGs of
which link SP is a member". This is illustrated in <xref
target="fig-SRLG5"></xref> below.</t>
<figure anchor="fig-SRLG5"
title="Topology used for repair computation for link S-P">
<preamble></preamble>
<artwork><![CDATA[ ab Ps a Dg
S----/-----P---------G---/----D
| | | |
| a | | |
A----/-----B | |
| | | |
| b | | b |
C----/-----E---------F---/----H
| |
| |
J----------K ]]></artwork>
<postamble></postamble>
</figure>
<t>In this case, the repair path to Ps will be S-A-C-J-K-E-B-P. It may
appear that there is no path to D because GD is a member of SRLG "a"
and FH is a member of SRLG "b". This is true if BOTH SRLGs "a" and "b"
have in fact failed. But that would be an instance of multiple
uncorrelated failures which are out of scope for this design. In
practice it is likely that there is only a single failure, i.e. either
SRLG "a" or SRLG "b" has failed, but not both. These two possibilities
are indistinguishable from the point of view of the repairing router S
and so it must repair on the assumption that both are unavailable.
However, each link repair is considered independently. The repair to
Ps delivers the packet to P which then forwards the packet to G. When
the packet arrives at G, if SRLG "a" has failed it will be repaired
around the path G-F-H-D. This is illustrated in <xref
target="fig-SRLG6"></xref> below. If, on the other hand, SRLG "b" has
failed, link GD will still be available. In this case the packet will
be delivered as normal across the link GD.</t>
<figure anchor="fig-SRLG6"
title="Topology used for repair computation for link G-D ">
<preamble></preamble>
<artwork><![CDATA[ ab Ps a Dg
S----/-----P---------G---/----D
| | | |
| a | | |
A----/-----B | |
| | | |
| b | | b |
C----------E---------F--------H
| |
| |
J----------K ]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>A repair strategy that assumes the worst-case failure for each link
can often result in longer repair paths than necessary. In cases where
only a single link fails, rather than the full SRLG, this strategy may
occasionally fail to identify a repair even though a viable repair
path exists in the network. The use of sub-optimal repair paths is an
inevitable consequence of this compromise approach. The failure to
identify any repair is a serious deficiency, but is a rare occurrence
in a robustly designed network. This problem can be addressed
by:-<list style="numbers">
<t>Reporting that the link in question is irreparable, so that the
network designer can take appropriate action.</t>
<t>Modifying the design of the network to avoid this
possibility.</t>
<t>Using some form of SRLG diagnostic (for example, by running BFD
over alternate repair paths) to determine which SRLG member(s) has
actually failed and using this information to select an
appropriate pre-computed repair path. However, aside from the
complexity of performing the diagnostics, this requires multiple
not-via addresses per interface, which has poor scaling
properties.</t>
</list></t>
<section title="Use of LFAs with SRLGs ">
<t>Section 4.1 above describes the repair of links which are members
of one or more SRLGs. LFAs can be used for the repair of such links
provided that any other link with which S-P shares an SRLG is
avoided when computing the LFA. This is described for the simple
case of "local-SRLGs" in <xref
target="I-D.ietf-rtgwg-ipfrr-spec-base"></xref>.</t>
<t></t>
</section>
</section>
<section title="Local Area Networks">
<t>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.
Protecting against link failure of the LAN link(s) is relatively
straightforward, but as with all fast reroute mechanisms, the problem
becomes more complex when it is desired to protect against the
possibility of failure of the nodes attached to the LAN as well as the
LAN itself.</t>
<figure anchor="fig-LAN1" title="Local Area Networks ">
<preamble></preamble>
<artwork><![CDATA[ +--------------Q------C
|
|
|
A--------S-------(N)-------------P------B
|
|
|
+--------------R------D ]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>Consider the LAN shown in <xref target="fig-LAN1"></xref>. For
connectivity purposes, we consider that the LAN is represented by the
pseudonode (N). To provide IPFRR protection, S must run a connectivity
check to each of its protected LAN adjacencies P, Q, and R, using, for
example BFD <xref target="I-D.ietf-bfd-base"></xref>.</t>
<t>When S discovers that it has lost connectivity to P, it is unsure
whether the failure is:</t>
<t><list style="symbols">
<t>its own interface to the LAN,</t>
<t>the LAN itself,</t>
<t>the LAN interface of P,</t>
<t>the node P.</t>
</list></t>
<section title="Simple LAN Repair">
<t>A simple approach to LAN repair is to consider the LAN and all of
its connected routers as a single SRLG. Thus, the address P not via
the LAN (Pl) would require P to be reached not-via any router
connected to the LAN. This is shown in <xref
target="fig-LAN2"></xref>.</t>
<figure anchor="fig-LAN2" title="Local Area Networks - LAN SRLG">
<preamble></preamble>
<artwork><![CDATA[ Ql Cl
+-------------Q--------C
| Qc
|
As Sl | Pl Bl
A--------S-------(N)------------P--------B
Sa | Pb
|
| Rl Dl
+-------------R--------D
Rd
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>In this case, when S detected that P had failed it would send
traffic reached via P and B to B not-via the LAN or any router
attached to the LAN (i.e. to Bl). Any destination only reachable
through P would be addressed to P not-via the LAN or any router
attached to the LAN (except of course P).</t>
<t>Whilst this approach is simple, it assumes that a large portion
of the network adjacent to the failure has also failed. This will
result in the use of sub-optimal repair paths and in some cases the
inability to identify a viable repair.</t>
<t></t>
</section>
<section title="LAN Component Repair">
<t></t>
<t>In this approach, possible failures are considered at a finer
granularity, but without the use of diagnostics to identify the
specific component that has failed. Because S is unable to diagnose
the failure it must repair traffic sent through P and B, to B not-
via P,N (i.e. not via P and not via N), on the conservative
assumption that both the entire LAN and P have failed. Destinations
for which P is a single point of failure must as usual be sent to P
using an address that avoids the interface by which P is reached
from S, i.e. to P not-via N. Similarly for routers Q and R.</t>
<t>Notice that each router that is connected to a LAN must, as
usual, advertise one not-via address for each neighbor. In addition,
each router on the LAN must advertise an extra address not via the
pseudonode (N).</t>
<t>Notice also that each neighbor of a router connected to a LAN
must advertise two not-via addresses, the usual one not via the
neighbor and an additional one, not via either the neighbor or the
pseudonode. The required set of LAN address assignments is shown in
<xref target="fig-LAN3"></xref> below. Each router on the LAN, and
each of its neighbors, is advertising exactly one address more than
it would otherwise have advertised if this degree of connectivity
had been achieved using point-to-point links.</t>
<figure anchor="fig-LAN3" title="Local Area Networks">
<preamble></preamble>
<artwork><![CDATA[ Qs Qp Qc Cqn
+--------------Q---------C
| Qr Qn Cq
|
Asn Sa Sp Sq | Ps Pq Pb Bpn
A--------S-------(N)-------------P---------B
As Sr Sn | Pr Pn Bp
|
| Rs Rp Pd Drn
+--------------R---------D
Rq Rn Dr ]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="LAN Repair Using Diagnostics ">
<t>A more specific LAN repair can be undertaken by using
diagnostics. In order to explicitly diagnose the failed network
component, S correlates the connectivity reports from P and one or
more of the other routers on the LAN, in this case, Q and R. If it
lost connectivity to P alone, it could deduce that the LAN was still
functioning and that the fault lay with either P, or the interface
connecting P to the LAN. It would then repair to B not via P (and P
not-via N for destinations for which P is a single point of failure)
in the usual way. If S lost connectivity to more than one router on
the LAN, it could conclude that the fault lay only with the LAN, and
could repair to P, Q and R not-via N, again in the usual way.</t>
<t></t>
</section>
</section>
</section>
<section title="Multiple Simultaneous Failures ">
<t></t>
<t>The failure of a node or an SRLG can result in multiple correlated
failures, which may be repaired using the mechanisms described in this
design. This design will not correctly repair a set of unanticipated
multiple failures. Such failures are out of scope of this design and are
for further study.</t>
<t>It is important that the routers in the network are able to
discriminate between these two classes of failure, and take appropriate
action.</t>
</section>
<section title="Optimizing not-via computations using LFAs">
<t></t>
<t>If repairing node S has an LFA to the repair endpoint it is not
necessary for any router to perform the incremental SPF with the link SP
removed in order to compute the route to the not-via address Ps. This is
because the correct routes will already have been computed as a result
of the SPF on the base topology. Node S can signal this condition to all
other routers by including a bit in its LSP or LSA associated with each
LFA protected link. Routers computing not-via routes can then omit the
running of the iSPF for links with this bit set.</t>
<t>When running the iSPF for a particular link AB, the calculating
router first checks whether the link AB is present in the existing SPT.
If the link is not present in the SPT, no further work is required. This
check is a normal part of the iSPF computation.</t>
<t>If the link is present in the SPT, this optimization introduces a
further check to determine whether the link is marked as protected by an
LFA in the direction in which the link appears in the SPT. If so the
iSPF need not be performed. For example, if the link appears in the SPT
in the direction A->B and A has indicated that the link AB is
protected by an LFA no further action is required for this link.</t>
<t>If the receipt of this information is delayed, the correct operation
of the protocol is not compromised provided that the necessity to
perform a not-via computation is re-evaluated whenever new information
arrives.</t>
<t>This optimization is not particularly beneficial to nodes close to
the repair since, as has been observed above, the computation for nodes
on the LFA path is trivial. However, for nodes upstream of the link SP
for which S-P is in the path to P, there is a significant reduction in
the computation required.</t>
</section>
<section title="Multicast">
<t></t>
<t>Multicast traffic can be repaired in a similar way to unicast. The
multicast forwarder is able to use the not-via address to which the
multicast packet was addressed as an indication of the expected receive
interface and hence to correctly run the required RPF check.</t>
<t>In some cases, all the destinations, including the repair endpoint,
are repairable by an LFA. In this case, all unicast traffic may be
repaired without encapsulation. Multicast traffic still requires
encapsulation, but for the nodes on the LFA repair path the computation
of the not-via forwarding entry is unnecessary since, by definition,
their normal path to the repair endpoint is not via the failure.</t>
<t>A more complete description of multicast operation will be provided
in a future version of this draft.</t>
<t></t>
</section>
<section title="Fast Reroute in an MPLS LDP Network. ">
<t></t>
<t>Not-via addresses are IP addresses and LDP <xref
target="RFC5036"></xref> will distribute labels for them in the usual
way. The not-via repair mechanism may therefore be used to provide fast
re-route in an MPLS network by first pushing the label which the repair
endpoint uses to forward the packet, and then pushing the label
corresponding to the not-via address needed to effect the repair.
Referring once again to <xref target="fig-repair"></xref>, if S has a
packet destined for D that it must reach via P and B, S first pushes B's
label for D. S then pushes the label that its next hop to Bp needs to
reach Bp.</t>
<t>Note that in an MPLS LDP network it is necessary for S to have the
repair endpoint's label for the destination. When S is effecting a link
repair it already has this. In the case of a node repair, S either needs
to set up a directed LDP session with each of its neighbor's neighbors,
or it needs to use the next-next hop label distribution mechanism
proposed in <xref target="I-D.shen-mpls-ldp-nnhop-label"></xref>.</t>
</section>
<section title="Encapsulation">
<t>Any IETF specified IP in IP encapsulation may be used to carry a
not-via repair. IP in IP <xref target="RFC2003"></xref>, GRE <xref
target="RFC1701"></xref> and L2TPv3 <xref target="RFC3931"></xref>, all
have the necessary and sufficient properties. The requirement is that
both the encapsulating router and the router to which the encapsulated
packet is addressed have a common ability to process the chosen
encapsulation type. When an MPLS LDP network is being protected, the
encapsulation would normally be an additional MPLS label. In an MPLS
enabled IP network an MPLS label may be used in place of an IP in IP
encapsulation in the case above.</t>
</section>
<section title="Routing Extensions">
<t></t>
<t>IPFRR requires IGP extensions. Each IPFRR router that is directly
connected to a protected network component must advertise a not-via
address for that component. This must be advertised in such a way that
the association between the protected component (link, router or SRLG)
and the not-via address can be determined by the other routers in the
network.</t>
<t>It is necessary that not-via capable routers advertise in the IGP
that they will calculate not-via routes.</t>
<t>It is necessary for routers to advertise the type of encapsulation
that they support (MPLS, GRE, L2TPv3 etc). However, the deployment of
mixed IP encapsulation types within a network is discouraged.</t>
</section>
<section title="Incremental Deployment">
<t>Incremental deployment is supported by excluding routers that are not
calculating not-via routes (as indicated by their capability information
flooded with their link state information) from the base topology used
for the computation of repair paths. In that way repairs may be steered
around islands of routers that are not IPFRR capable. Routers that are
protecting a network component need to have the capability to
encapsulate and de-capsulate packets. However, routers that are on the
repair path only need to be capable of calculating not-via paths and
including the not-via addresses in their FIB i.e. these routers do not
need any changes to their forwarding mechanism.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations that arise from this draft.</t>
</section>
<section title="Security Considerations">
<t>The repair endpoints present vulnerability in that they might be used
as a method of disguising the delivery of a packet to a point in the
network. The primary method of protection should be through the use of a
private address space for the not-via addresses. These addresses MUST
NOT be advertised outside the area, and SHOULD be filtered at the
network entry points. In addition, a mechanism might be developed that
allowed the use of the mild security available through the use of a key
<xref target="RFC1701"></xref> <xref target="RFC3931"></xref>. With the
deployment of such mechanisms, the repair endpoints would not increase
the security risk beyond that of existing IP tunnel mechanisms. An
attacker may attempt to overload a router by addressing an excessive
traffic load to the de-capsulation endpoint. Typically, routers take a
50% performance penalty in decapsulating a packet. The attacker could
not be certain that the router would be impacted, and the extremely high
volume of traffic needed, would easily be detected as an anomaly. If an
attacker were able to influence the availability of a link, they could
cause the network to invoke the not-via repair mechanism. A network
protected by not-via IPFRR is less vulnerable to such an attack than a
network that undertook a full convergence in response to a link up/down
event.</t>
<t></t>
</section>
<section title="Acknowledgements">
<t>The authors would like to acknowledge contributions made by Alia
Atlas and John Harper.</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">
&RFC2119;
</references>
<references title="Informative References">
&BFD;
&GRE;
&IPFRR;
&IPIP;
&L2TPv3;
&LDP;
&BASE;
&NNHL;
<reference anchor="ISPF">
<front>
<title>ARPANET Routing Algorithm Improvements"</title>
<author initials="J." surname="McQuillan">
<organization abbrev="BBN">BBN</organization>
</author>
<author initials="I." surname="Richer">
<organization abbrev="BBN">BBN</organization>
</author>
<author initials="E." surname="Rosen">
<organization abbrev="BBN">BBN</organization>
</author>
<date year="1978" />
</front>
<seriesInfo name="BBN Technical Report" value="3803" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 17:24:02 |