One document matched: draft-ietf-rtgwg-lf-conv-frmwk-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. -->
]>
<?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="no"?>
<!-- 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="info" docName="draft-ietf-rtgwg-lf-conv-frmwk-02"
ipr="full3978">
<!-- 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>
<title abbrev="A Framework for Loop-free Convergence">A Framework for
Loop-free Convergence</title>
<author fullname="Mike Shand" initials="M." surname="Shand">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater Ave,</street>
<city>Green Park,</city>
<region>Reading,</region>
<code>RG2 6GB,</code>
<country>United Kingdom.</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>mshand@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250, Longwater Ave,</street>
<!-- Reorder these if your country does things differently -->
<city>Green Park,</city>
<region>Reading,</region>
<code>RG2 6GB</code>
<country>United Kingdom.</country>
</postal>
<phone></phone>
<email>stbryant@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="February" year="2008" />
<area>Routing</area>
<workgroup>RTGWG</workgroup>
<abstract>
<t>This draft describes 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.</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>When there is a change to the network topology (due to the failure or
restoration of a link or router, or as a result of management action)
the routers need to converge on a common view of the new topology and
the paths to be used for forwarding traffic to each destination. During
this process, referred to as a routing transition, packet delivery
between certain source/destination pairs may be disrupted. This occurs
due to the time it takes for the topology change to be propagated around
the network together with the time it takes each individual router to
determine and then update the forwarding information base (FIB) for the
affected destinations. During this transition, packets may be lost due
to the continuing attempts to use the failed component, and due to
forwarding loops. Forwarding loops arise due to the inconsistent FIBs
that occur as a result of the difference in time taken by routers to
execute the transition process. This is a problem that occurs in both IP
networks and MPLS networks that use LDP <xref
target="RFC3036">RFC3036</xref> as the label switched path (LSP)
signaling protocol.</t>
<t>The service failures caused by routing transitions are largely hidden
by higher-level protocols that retransmit the lost data. However new
Internet services are emerging which are more sensitive to the packet
disruption that occurs during a transition. To make the transition
transparent to their users, these services require a short routing
transition. Ideally, routing transitions would be completed in zero time
with no packet loss.</t>
<t>Regardless of how optimally the mechanisms involved have been
designed and implemented, it is inevitable that a routing transition
will take some minimum interval that is greater than zero. This has led
to the development of a TE fast-reroute mechanism for MPLS <xref
target="RFC4090">RFC4090</xref>. Alternative mechanisms that might be
deployed in an MPLS network and mechanisms that may be used in an IP
network are work in progress in the IETF <xref
target="I-D.ietf-rtgwg-ipfrr-framework">IPFRR</xref>. Any repair
mechanism may however be disrupted by the formation of micro-loops
during the period between the time when the failure is announced, and
the time when all FIBs have been updated to reflect the new
topology.</t>
<t>There is, however, little point in introducing new mechanisms into an
IP network to provide fast re-route, without also deploying mechanisms
that prevent the disruptive effects of micro-loops which may starve the
repair or cause congestion loss as a result of looping packets.</t>
<t>The disruptive effect of micro-loops is not confined to periods when
there is a component failure. Micro-loops can, for example, form when a
component is put back into service following repair. Micro- loops can
also form as a result of a network maintenance action such as adding a
new network component, removing a network component or modifying a link
cost.</t>
<t>This framework provides a summary of the mechanisms that have been
proposed to address the micro-loop issue.</t>
</section>
<section anchor="natureOfUl" title="The Nature of Micro-loops">
<t>Micro-loops may form during the periods when a network is re-
converging following ANY topology change, and are caused by inconsistent
FIBs in the routers. During the transition, micro-loops may occur over a
single link between a pair of routers that temporarily use each other as
the next hop for a prefix. Micro-loops may also form when each router in
a cycle of routers has the next router in the cycle as a next hop for a
prefix.</t>
<t>Cyclic loops may occur if one or more of the following conditions are
met:- <list>
<t>1) Asymmetric link costs.</t>
<t>2) The existence of an equal cost path between a pair of routers
which make different decisions regarding which path to use for
forwarding a particular destination. Note that even routers which do
not implement equal cost multi-path (ECMP) forwarding must make a
choice between the available equal cost paths and unless they make
the same choice the condition for cyclic loops will be
fulfilled.</t>
<t>3) Topology changes affecting multiple links, including single
node and line card failures.</t>
</list> Micro-loops have two undesirable side-effects; congestion and
repair starvation. A looping packet consumes bandwidth until it either
escapes as a result of the re-synchronization of the FIBs, or its TTL
expires. This transiently increases the traffic over a link by as much
as 128 times, and may cause the link to congest. This congestion reduces
the bandwidth available to other traffic (which is not otherwise
affected by the topology change). As a result the "innocent" traffic
using the link experiences increased latency, and is liable to
congestive packet loss.</t>
<t>In cases where the link or node failure has been protected by a fast
re-route repair, the inconsistency in the FIBs prevents some traffic
from reaching the failure and hence being repaired. The repair may thus
become starved of traffic and hence become ineffective. Thus in addition
to the congestive damage, the repair is rendered ineffective by the
micro-loop. Similarly, if the topology change is the result of
management action the link could have been retained in service
throughout the transition (i.e. the link acts as its own repair path),
however, if micro-loops form, they prevent productive forwarding during
the transition.</t>
<t>Unless otherwise controlled, micro-loops may form in any part of the
network that forwards (or in the case of a new link, will forward)
packets over a path that includes the affected topology change. The time
taken to propagate the topology change through the network, and the
non-uniform time taken by each router to calculate the new shortest path
tree (SPT) and update its FIB may significantly extend the duration of
the packet disruption caused by the micro-loops. In some cases a packet
may be subject to disruption from micro-loops which occur sequentially
at links along the path, thus further extending the period of disruption
beyond that required to resolve a single loop.</t>
<t></t>
</section>
<section anchor="Applic" title="Applicability">
<t>Loop free convergence techniques are applicable <xref
target="I-D.bryant-shand-lf-applicability">APPL</xref>to any situation
in which micro-loops may form. For example the convergence of a network
following:</t>
<t><list>
<t>1) Component failure.</t>
<t>2) Component repair.</t>
<t>3) Management withdrawal of a component.</t>
<t>4) Management insertion or a component.</t>
<t>5) Management change of link cost (either positive or
negative).</t>
<t>6) External cost change, for example change of external gateway
as a result of a BGP change.</t>
<t>7) A Shared risk link group failure.</t>
</list> In each case, a component may be a link or a router.</t>
<t>Loop free convergence techniques are applicable to both IP networks
and MPLS enabled networks that use LDP, including LDP networks that use
the single-hop tunnel fast-reroute mechanism.</t>
<t></t>
</section>
<section title="Micro-loop Control Strategies">
<t>Micro-loop control strategies fall into three basic classes:</t>
<t><list>
<t>1) Micro-loop mitigation</t>
<t>2) Micro-loop prevention</t>
<t>3) Micro-loop suppression</t>
</list> A micro-loop mitigation scheme works by re-converging the
network in such a way that it reduces, but does not eliminate, the
formation of micro-loops. Such schemes cannot guarantee the productive
forwarding of packets during the transition.</t>
<t>A micro-loop prevention mechanism controls the re-convergence of
network in such a way that no micro-loops form. Such a micro-loop
prevention mechanism allows the continued use of any fast repair method
until the network has converged on its new topology, and prevents the
collateral damage that occurs to other traffic for the duration of each
micro-loop.</t>
<t>A micro-loop suppression mechanism attempts to eliminate the
collateral damage done by micro-loops to other traffic. This may be
achieved by, for example, using a packet monitoring method, which
detects that a packet is looping and drops it. Such schemes make no
attempt to productively forward the packet throughout the network
transition.</t>
<t>Note that all known micro-loop mitigation and micro-loop prevention
mechanisms extend the duration of the re-convergence process. When the
failed component is protected by a fast re-route repair this implies
that the converging network requires the repair to remain in place for
longer than would otherwise be the case. The extended convergence time
means any traffic which is NOT repaired by an imperfect repair
experiences a significantly longer outage than it would experience with
conventional convergence.</t>
<t>When a component is returned to service, or when a network management
action has taken place, this additional delay does not cause traffic
disruption, because there is no repair involved. However the extended
delay is undesirable, because it increases the time that the network
takes to be ready for another failure, and hence leaves it vulnerable to
multiple failures.</t>
<t></t>
</section>
<section anchor="LoopMit" title="Loop mitigation ">
<t>The only known loop mitigation approach is the Path Locking with
safe-neighbors (PLSN) method described in <xref
target="I-D.ietf-rtgwg-microloop-analysis">PLSN</xref>. In this method,
a micro-loop free next-hop safety condition is defined as follows: In a
symmetric cost network, it is safe for router X to change to the use of
neighbor Y as its next-hop for a specific destination if the path
through Y to that destination satisfies both of the following
criteria:</t>
<t><list>
<t>1. X considers Y as its loop-free neighbor based on the topology
before the change AND</t>
<t>2. X considers Y as its downstream neighbor based on the topology
after the change.</t>
</list>In an asymmetric cost network, a stricter safety condition is
needed, and the criterion is that:</t>
<t><list>
<t>X considers Y as its downstream neighbor based on the topology
both before and after the change.</t>
</list></t>
<t>Based on these criteria, destinations are classified by each router
into three classes:</t>
<t><list>
<t>Type A destinations: Destinations unaffected by the change (type
A1) and also destinations whose next hop after the change satisfies
the safety criteria (type A2).</t>
<t>Type B destinations: Destinations that cannot be sent via the new
primary next-hop because the safety criteria are not satisfied, but
which can be sent via another next-hop that does satisfy the safety
criteria.</t>
<t>Type C destinations: All other destinations.</t>
</list> Following a topology change, Type A destinations are
immediately changed to go via the new topology. Type B destinations are
immediately changed to go via the next hop that satisfies the safety
criteria, even though this is not the shortest path. Type B destinations
continue to go via this path until all routers have changed their Type C
destinations over to the new next hop. Routers must not change their
Type C destinations until all routers have changed their Type A2 and
Type B destinations to the new or intermediate (safe) next hop.</t>
<t>Simulations indicate that this approach produces a significant
reduction in the number of links that are subject to micro-looping.
However unlike all of the micro-loop prevention methods it is only a
partial solution. In particular, micro-loops may form on any link
joining a pair of type C routers.</t>
<t>Because routers delay updating their Type C destination FIB entries,
they will continue to route towards the failure during the time when the
routers are changing their Type A and B destinations, and hence will
continue to productively forward packets provided that viable repair
paths exist.</t>
<t>A backwards compatibility issue arises with PLSN. If a router is not
capable of micro-loop control, it will not correctly delay its FIB
update. If all such routers had only type A destinations this loop
mitigation mechanism would work as it was designed. Alternatively, if
all such incapable routers had only type C destinations, the "covert"
announcement mechanism used to trigger the tunnel based schemes (see
sections 5.2 to 5.4) could be used to cause the Type A and Type B
destinations to be changed, with the incapable routers and routers
having type C destinations delaying until they received the "real"
announcement. Unfortunately, these two approaches are mutually
incompatible.</t>
<t>Note that simulations indicate that in most topologies treating type
B destinations as type C results in only a small degradation in loop
prevention. Also note that simulation results indicate that in
production networks where some, but not all, links have asymmetric
costs, using the stricter asymmetric cost criterion actually REDUCES the
number of loop free destinations, because fewer destinations can be
classified as type A or B.</t>
<t>This mechanism operates identically for both "bad-news" events,
"good-news" events and SRLG failure.</t>
</section>
<section title="Micro-loop Prevention ">
<t>Eight micro-loop prevention methods have been proposed:</t>
<t><list counter="uloop" style="format %d.">
<t>Incremental cost advertisement</t>
<t>Nearside tunneling</t>
<t>Farside tunneling</t>
<t>Distributed tunnels</t>
<t>Packet marking</t>
<t>New MPLS labels</t>
<t>Ordered FIB update</t>
<t>Synchronized FIB update</t>
</list></t>
<section title="Incremental Cost Advertisement">
<t>When a link fails, the cost of the link is normally changed from
its assigned metric to "infinity" in one step. However, it can be
proved that no micro-loops will form if the link cost is increased in
suitable increments, and the network is allowed to stabilize before
the next cost increment is advertised. Once the link cost has been
increased to a value greater than that of the lowest alternative cost
around the link, the link may be disabled without causing a
micro-loop.</t>
<t>The criterion for a link cost change to be safe is that any link
which is subjected to a cost change of x can only cause loops in a
part of the network that has a cyclic cost less than or equal to x.
Because there may exist links which have a cost of one in each
direction, resulting in a cyclic cost of two, this can result in the
link cost having to be raised in increments of one. However the
increment can be larger where the minimum cost permits. Recent work
<eref
target=""Disruption free topology reconfiguration in OSPF networks", IEEE INFOCOM 2007, May 2007, Anchorage."></eref>
has shown that there are a number of optimizations which can be
applied to the problem in order to minimize the number of increments
required.</t>
<t>The incremental cost change approach has the advantage over all
other currently known loop prevention scheme that it requires no
change to the routing protocol. It will work in any network because it
does not require any co-operation from the other routers in the
network.</t>
<t>Where large metrics are used and no optimization is performed, the
method can be extremely slow. However in cases where the per link
metric is small, either because small values have been assigned by the
network designers, or because of restrictions implicit in the routing
protocol (e.g. RIP restricts the metric, and BGP using the AS path
length frequently uses an effective metric of one, or a very small
integer for each inter AS hop), the number of required increments can
be acceptably small even without optimizations.</t>
<t>The number of increments required, and hence the time taken to
fully converge, is significant because for the duration of the
transition some parts of the network continue to use the old
forwarding path, and hence use any repair mechanism for an extended
period. In the case of a failure that cannot be fully repaired, some
destinations may become unreachable for an extended period.</t>
<t>Where the micro-loop prevention mechanism was being used to support
a fast re-route repair the network may be vulnerable to a second
failure for the duration of the controlled re-convergence.</t>
<t>Where the micro-loop prevention mechanism was being used to support
a reconfiguration of the network the extended time is less of an
issue. In this case, because the real forwarding path is available
throughout the whole transition, there is no conflict between
concurrent change actions throughout the network.</t>
<t>It will be appreciated that when a link is returned to service, its
cost is reduced in small steps from "infinity" to its final cost,
thereby providing similar micro-loop prevention during a "good-news"
event. Note that the link cost may be decreased from "infinity" to any
value greater than that of the lowest alternative cost around the link
in one step without causing a micro-loop.</t>
<t>When the failure is an SRLG the link cost increments must be
coordinated across all members of the SRLG. This may be achieved by
completing the transition of one link before starting the next, or by
interleaving the changes. This can be achieved without the need for
any protocol extensions, by for example, using existing identifiers to
establish the ordering and the arrival of LSP/LSAs to trigger the
generation of the next increment.</t>
</section>
<section title="Nearside Tunneling ">
<t>This mechanism works by creating an overlay network using tunnels
whose path is not affected by the topology change and carrying the
traffic affected by the change in that new network. When all the
traffic is in the new, tunnel based, network, the real network is
allowed to converge on the new topology. Because all the traffic that
would be affected by the change is carried in the overlay network no
micro-loops form.</t>
<t>When a failure is detected (or a link is withdrawn from service),
the router adjacent to the failure issues a new ("covert") routing
message announcing the topology change. This message is propagated
through the network by all routers, but is only understood by routers
capable of using one of the tunnel based micro-loop prevention
mechanisms.</t>
<t>Each of the micro-loop preventing routers builds a tunnel to the
closest router adjacent to the failure. They then determine which of
their traffic would transit the failure and place that traffic in the
tunnel. When all of these tunnels are in place, the failure is then
announced as normal. Because these tunnels will be unaffected by the
transition, and because the routers protecting the link will continue
the repair (or forward across the link being withdrawn), no traffic
will be disrupted by the failure. When the network has converged these
tunnels are withdrawn, allowing traffic to be forwarded along its new
"natural" path. The order of tunnel insertion and withdrawal is not
important, provided that the tunnels are all in place before the
normal announcement is issued.</t>
<t>This method completes in bounded time, and is much faster than the
incremental cost method. Depending on the exact design, it completes
in two or three flood-SPF-FIB update cycles.</t>
<t>At the time at which the failure is announced as normal,
micro-loops may form within isolated islands of non-micro-loop
preventing routers. However, only traffic entering the network via
such routers can micro-loop. All traffic entering the network via a
micro-loop preventing router will be tunneled correctly to the nearest
repairing router, including, if necessary being tunneled via a non-
micro-loop preventing router, and will not micro-loop.</t>
<t>Where there is no requirement to prevent the formation of micro-
loops involving non-micro-loop preventing routers, a single, "normal"
announcement may be made, and a local timer used to determine the time
at which transition from tunneled forwarding to normal forwarding over
the new topology may commence.</t>
<t>This technique has the disadvantage that it requires traffic to be
tunneled during the transition. This is an issue in IP networks
because not all router designs are capable of high performance IP
tunneling. It is also an issue in MPLS networks because the
encapsulating router has to know the label set that the decapsulating
router is distributing.</t>
<t>A further disadvantage of this method is that it requires co-
operation from all the routers within the routing domain to fully
protect the network against micro-loops.</t>
<t>When a new link is added, the mechanism is run in "reverse". When
the "covert" announcement is heard, routers determine which traffic
they will send over the new link, and tunnel that traffic to the
router on the near side of that link. This path will not be affected
by the presence of the new link. When the "normal" announcement is
heard, they then update their FIB to send the traffic normally
according to the new topology. Any traffic encountering a router that
has not yet updated its FIB will be tunneled to the near side of the
link, and will therefore not loop.</t>
<t>When a management change to the topology is required, again exactly
the same mechanism protects against micro-looping of packets by the
micro-loop preventing routers.</t>
<t>When the failure is an SRLG, the required strategy is to classify
traffic according the first member of the SRLG that it will traverse
on its way to the destination, and to tunnel that traffic to the
router that is closest to that SRLG member. This will require multiple
tunnel destinations, in the limiting case, one per SRLG member.</t>
</section>
<section title="Farside Tunnels">
<t>Farside tunneling loop prevention requires the loop preventing
routers to place all of the traffic that would traverse the failure in
one or more tunnels terminating at the router (or in the case of node
failure routers) at the far side of the failure. The properties of
this method are a more uniform distribution of repair traffic than is
a achieved using the nearside tunnel method, and in the case of node
failure, a reduction in the decapsulation load on any single
router.</t>
<t>Unlike the nearside tunnel method (which uses normal routing to the
repairing router), this method requires the use of a repair path to
the farside router. This may be provided by the not-via mechanism, in
which case no further computation is needed.</t>
<t>The mode of operation is otherwise identical to the nearside
tunneling loop prevention method (Section 5.2).</t>
</section>
<section title="Distributed Tunnels">
<t>In the distributed tunnels loop prevention method, each router
calculates its own repair and forwards traffic affected by the failure
using that repair. Unlike the FRR case, the actual failure is known at
the time of the calculation. The objective of the loop preventing
routers is to get the packets that would have gone via the failure
into G-space <xref target="I-D.bryant-ipfrr-tunnels">TUNNEL</xref>
using routers that are in F-space. Because packets are decapsulated on
entry to G-space, rather than being forced to go to the farside of the
failure, more optimum routing may be achieved. This method is subject
to the same reachability constraints described in <xref
target="I-D.bryant-ipfrr-tunnels">TUNNEL</xref> .</t>
<t>The mode of operation is otherwise identical to the nearside
tunneling loop prevention method (Section 5.2).</t>
</section>
<section title="Packet Marking ">
<t>If packets could be marked in some way, this information could be
used to assign them to one of: the new topology, the old topology or a
transition topology. They would then be correctly forwarded during the
transition. This could, for example, be achieved by allocating a Type
of Service bit to the task <xref target="RFC0791">RFC791</xref>. This
mechanism works identically for both "bad-news" and "good-news"
events. It also works identically for SRLG failure. There are three
problems with this solution:</t>
<t><list>
<t>The packet marking bit may not available.</t>
<t>The mechanism would introduce a non-standard forwarding
procedure.</t>
<t>Packet marking using either the old or the new topology would
double the size of the FIB, however some optimizations may be
possible</t>
</list></t>
</section>
<section title="MPLS New Labels ">
<t>In an MPLS network that is using <xref
target="RFC3036">RFC3036</xref> for label distribution, loop free
convergence can be achieved through the use of new labels when the
path that a prefix will take through the network changes.</t>
<t>As described in Section 5.2, the repairing routers issue a covert
announcement to start the loop free convergence process. All loop
preventing routers calculate the new topology and determine whether
their FIB needs to be changed. If there is no change in the FIB they
take no part in the following process.</t>
<t>The routers that need to make a change to their FIB consider each
change and check the new next hop to determine whether it will use a
path in the OLD topology which reaches the destination without
traversing the failure (i.e. the next hop is in F-space with respect
to the failure <xref target="I-D.bryant-ipfrr-tunnels">TUNNEL</xref>).
If so the FIB entry can be immediately updated. For all of the
remaining FIB entries, the router issues a new label to each of its
neighbors. This new label is used to lock the path during the
transition in a similar manner to the previously described loop-free
convergence with tunnels method (Section 5.2). Routers receiving a new
label install it in their FIB, for MPLS label translation, but do not
yet remove the old label and do not yet use this new label to forward
IP packets. i.e. they prepare to forward using the new label on the
new path, but do not use it yet. Any packets received continue to be
forwarded the old way, using the old labels, towards the repair.</t>
<t>At some time after the covert announcement, an overt announcement
of the failure is issued. This announcement must not be issued until
such time as all routers have carried out all of their covert
announcement activities. On receipt of the overt announcement all
routers that were delaying convergence move to their new path for both
the new and the old labels. This involves changing the IP address
entries to use the new labels, AND changing the old labels to forward
using the new labels.</t>
<t>Because the new label path was installed during the covert phase,
packets reach their destinations as follows:</t>
<t><list>
<t>If they do not go via any router using a new label they go via
the repairing router and the repair.</t>
<t>If they meet any router that is using the new labels they get
marked with the new labels and reach their destination using the
new path, back-tracking if necessary.</t>
</list></t>
<t>When all routers have changed to the new path the network is
converged. At some time later, when it can be assumed that all routers
have moved to using the new path, the FIB can be cleaned up to remove
the, now redundant, old labels.</t>
<t>As with other method methods the new labels may be modified to
provide loop prevention for "good news". There are also a number of
optimizations of this method.</t>
</section>
<section title="Ordered FIB Update ">
<t>The Ordered FIB loop prevention method is described in <xref
target="I-D.ietf-rtgwg-ordered-fib">OFIB</xref>. Micro-loops occur
following a failure or a cost increase, when a router closer to the
failed component revises its routes to take account of the failure
before a router which is further away. By analyzing the reverse
spanning tree over which traffic is directed to the failed component
in the old topology, it is possible to determine a strict ordering
which ensures that nodes closer to the root always process the failure
after any nodes further away, and hence micro-loops are prevented.</t>
<t>When the failure has been announced, each router waits a multiple
of the convergence timer <xref
target="I-D.atlas-bryant-shand-lf-timers">TIMER</xref>. The multiple
is determined by the node's position in the reverse spanning tree, and
the delay value is chosen to guarantee that a node can complete its
processing within this time. The convergence time may be reduced by
employing a signaling mechanism to notify the parent when all the
children have completed their processing, and hence when it was safe
for the parent to instantiate its new routes.</t>
<t>The property of this approach is therefore that it imposes a delay
which is bounded by the network diameter although in many cases it
will be much less.</t>
<t>When a link is returned to service the convergence process above is
reversed. A router first determines its distance (in hops) from the
new link in the NEW topology. Before updating its FIB, it then waits a
time equal to the value of that distance multiplied by the convergence
timer.</t>
<t>It will be seen that network management actions can similarly be
undertaken by treating a cost increase in a manner similar to a
failure and a cost decrease similar to a restoration.</t>
<t>The ordered FIB mechanism requires all nodes in the domain to
operate according to these procedures, and the presence of non co-
operating nodes can give rise to loops for any traffic which traverses
them (not just traffic which is originated through them). Without
additional mechanisms these loops could remain in place for a
significant time.</t>
<t>It should be noted that this method requires per router ordering,
but not per prefix ordering. A router must wait its turn to update its
FIB, but it should then update its entire FIB.</t>
<t>When an SRLG failure occurs a router must classify traffic into the
classes that pass over each member of the SRLG. Each router is then
independently assigned a ranking with respect to each SRLG member for
which they have a traffic class. These rankings may be different for
each traffic class. The prefixes of each class are then changed in the
FIB according to the ordering of their specific ranking. Again, as for
the single failure case, signaling may be used to speed up the
convergence process.</t>
<t>Note that the special SRLG case of a full or partial node failure,
can be dealt with without using per prefix ordering, by running a
single reverse SPF rooted at the failed node (or common point of the
subset of failing links in the partial case).</t>
<t>There are two classes of signaling optimization that can be applied
to the ordered FIB loop-prevention method:</t>
<t><list>
<t>When the router makes NO change, it can signal immediately.
This significantly reduces the time taken by the network to
process long chains of routers that have no change to make to
their FIB.</t>
<t>When a router HAS changed, it can signal that it has completed.
This is more problematic since this may be difficult to determine,
particularly in a distributed architecture, and the optimization
obtained is the difference between the actual time taken to make
the FIB change and the worst case timer value. This saving could
be of the order of one second per hop.</t>
</list></t>
<t>There is another method of executing ordered FIB which is based on
pure signaling <eref
target="P. Francois, O. Bonaventure, "Avoiding transient loops during IGP convergence" IEEE INFOCOM 2005, March 2005, Miami, Fl., USA ."></eref>.
Methods that use signaling as an optimization are safe because
eventually they fall back on the established IGP mechanisms which
ensure that networks converge under conditions of packet loss. However
a mechanism that relies on signaling in order to converge requires a
reliable signaling mechanism which must be proven to recover from any
failure circumstance.</t>
</section>
<section title="Synchronised FIB Update">
<t>Micro-loops form because of the asynchronous nature of the FIB
update process during a network transition. In many router
architectures it is the time taken to update the FIB itself that is
the dominant term. One approach would be to have two FIBs and, in a
synchronized action throughout the network, to switch from the old to
the new. One way to achieve this synchronized change would be to
signal or otherwise determine the wall clock time of the change, and
then execute the change at that time, using <xref target="RFC1305">
NTP </xref> to synchronize the wall clocks in the routers.</t>
<t>This approach has a number of major issues. Firstly two complete
FIBs are needed which may create a scaling issue and secondly a
suitable network wide synchronization method is needed. However,
neither of these are insurmountable problems.</t>
<t>Since the FIB change synchronization will not be perfect there may
be some interval during which micro-loops form. Whether this scheme is
classified as a micro-loop prevention mechanism or a micro-loop
mitigation mechanism within this taxonomy is therefore dependent on
the degree of synchronization achieved.</t>
<t>This mechanism works identically for both "bad-news" and
"good-news" events. It also works identically for SRLG failure.
Further consideration needs to be given to interoperating with routers
that do not support this mechanism. Without a suitable interoperating
mechanism, loops may form for the duration of the synchronization
delay.</t>
</section>
</section>
<section title="Using PLSN In Conjunction With Other Methods ">
<t>All of the tunnel methods and packet marking can be combined with
PLSN <xref target="I-D.ietf-rtgwg-microloop-analysis">PLSN</xref> to
reduce the traffic that needs to be protected by the advanced method.
Specifically all traffic could use PLSN except traffic between a pair of
routers both of which consider the destination to be type C. The type C
to type C traffic would be protected from micro-looping through the use
of a loop prevention method.</t>
<t>However, determining whether the new next hop router considers a
destination to be type C may be computationally intensive. An
alternative approach would be to use a loop prevention method for all
local type C destinations. This would not require any additional
computation, but would require the additional loop prevention method to
be used in cases which would not have generated loops (i.e. when the new
next-hop router considered this to be a type A or B destination).</t>
<t>The amount of traffic that would use PLSN is highly dependent on the
network topology and the specific change, but would be expected to be in
the region %70 to %90 in typical networks.</t>
<t>However, PLSN cannot be combined safely with Ordered FIB. Consider
the network fragment shown below:</t>
<t></t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[ R
/|\
/ | \
1/ 2| \3
/ | \ cost S->T = 10
Y-----X----S----T cost T->S = 1
| 1 2 |
|1 |
D---------------+
20 ]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t></t>
<t>On failure of link XY, according to PLSN, S will regard R as a safe
neighbor for traffic to D. However the ordered FIB rank of both R and T
will be zero and hence these can change their FIBs during the same time
interval. If R changes before T, then a loop will form around R, T and
S. This can be prevented by using a stronger safety condition than PLSN
currently specifies, at the cost of introducing more type C routers, and
hence reducing the PLSN coverage.</t>
<t></t>
</section>
<section title="Loop Suppression ">
<t>A micro-loop suppression mechanism recognizes that a packet is
looping and drops it. One such approach would be for a router to
recognize, by some means, that it had seen the same packet before. It is
difficult to see how sufficiently reliable discrimination could be
achieved without some form of per-router signature such as route
recording. A packet recognizing approach therefore seems infeasible.</t>
<t>An alternative approach would be to recognize that a packet was
looping by recognizing that it was being sent back to the place that it
had just come from. This would work for the types of loop that form in
symmetric cost networks, but would not suppress the cyclic loops that
form in asymmetric networks.</t>
<t>This mechanism operates identically for both "bad-news" events,
"good-news" events and SRLG failure.</t>
<t>The problem with this class of micro-loop control strategies is that
whilst they prevent collateral damage they do nothing to enhance the
productive forwarding of packets during the network transition.</t>
</section>
<section title="Compatibility Issues ">
<t>Deployment of any micro-loop control mechanism is a major change to a
network. Full consideration must be given to interoperation between
routers that are capable of micro-loop control, and those that are not.
Additionally there may be a desire to limit the complexity of micro-loop
control by choosing a method based purely on its simplicity. Any such
decision must take into account that if a more capable scheme is needed
in the future, its deployment will be complicated by interaction with
the scheme previously deployed.</t>
</section>
<section title="Comparison of Loop-free Convergence Methods ">
<t><xref target="I-D.ietf-rtgwg-microloop-analysis">PLSN</xref> is an
efficient mechanism to prevent the formation of micro-loops, but is only
a partial solution. It is a useful adjunct to some of the complete
solutions, but may need modification.</t>
<t>Incremental cost advertisement is impractical as a general solution
because it takes too long to complete. However, it is universally
available, and hence may find use in certain network reconfiguration
operations.</t>
<t>Packet Marking is probably impractical because of the need to find
the marking bit and to change the forwarding behavior.</t>
<t>Of the remaining methods distributed tunnels is significantly more
complex than nearside or farside tunnels, and should only be considered
if there is a requirement to distribute the tunnel decapsulation
load.</t>
<t>Synchronised FIBs is a fast method, but has the issue that a suitable
synchronization mechanism needs to be defined. One method would be to
use <xref target="RFC1305">NTP </xref>, however the coupling of routing
convergence to a protocol that uses the network may be a problem. During
the transition there will be some micro-looping for a short interval
because it is not possible to achieve complete synchronization of the
FIB changeover.</t>
<t>The ordered FIB mechanism has the major advantage that it is a
control plane only solution. However, SRLGs require a per- destination
calculation, and the convergence delay is high, bounded by the network
diameter. The use of signaling as an accelerator will reduce the number
of destinations that experience the full delay, and hence reduce the
total re-convergence time to an acceptable period.</t>
<t>The nearside and farside tunnel methods deal relatively easily with
SRLGs and uncorrelated changes. The convergence delay would be small.
However these methods require the use of tunneled forwarding which is
not supported on all router hardware, and raises issues of forwarding
performance. When used with PLSN, the amount of traffic that was
tunneled would be significantly reduced, thus reducing the forwarding
performance concerns. If the selected repair mechanism requires the use
of tunnels, then a tunnel based loop prevention scheme may be
acceptable.</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA considerations that arise from this draft.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All micro-loop control mechanisms raise significant security issues
which must be addressed in their detailed technical description.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- -->
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include="reference.I-D.bryant-shand-lf-applicability"?>
<?rfc include="reference.I-D.ietf-rtgwg-ipfrr-framework"?>
<?rfc include="reference.RFC.3036"?>
<?rfc include="reference.RFC.4090"?>
<?rfc include="reference.RFC.1305"?>
<?rfc include="reference.I-D.ietf-rtgwg-ordered-fib"?>
<?rfc include="reference.I-D.ietf-rtgwg-microloop-analysis"?>
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.I-D.atlas-bryant-shand-lf-timers"?>
<?rfc include="reference.I-D.bryant-ipfrr-tunnels"?>
</references>
<!-- -->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 03:37:22 |