The Micro-loop Prevention DT has been considering the existing proposals and
exploring additional ones. Please refer to the following reading material:
We have eliminated incremental cost changes, and synchronized FIB installation.
Incremental cost changes has been eliminated due to the excessively long time
(hours) for network convergence.
Synchronized FIB installation has been eliminated due to the strong
implementation constraints, dependency on NTP, and the fact that traffic loss
due to loops would be minimized and not eliminated.
Proposals still under consideration are:
- path-locking via safe neighbors (PLSN)
- ordered FIB installation (OFIB)
- combination of PLSN with OFIB and tunnels
A brief description of each mechanism is given below:
Path Locking via Safe Neighbors (PLSN)
Path locking via safe neighbors has a fixed convergence time regardless of
network size. This method also works regardless of the topology change(s) that
have occurred; this allows SRLG protection. The mechanism is easy to
understand. Analysis of existing networks shows that about 90% of the
potential 2-hop micro-loops are eliminated. The set of source/destination
pairs that are not protected is similar to that not protected via loop-free
The disadvantages of path locking via safe neighbors are as follows. First,
the coverage is not 100% on existing networks. As with the Basic IP FRR
mechanism, increasing redundancy in network topology can be used to increase
micro-loop coverage. However, without 100% coverage, even traffic that is
micro-loop free may suffer congestion or loss due to the traffic across a link
that is not micro-loop free. Second, prevention of multi-hop micro-loops in
networks with asymmetric link costs requires a stricter neighbor safety
condition (downstream path before topology change), which reduces the coverage
below the anticipated 90%.
Path locking can be augmented in a number of different ways (requiring
different forwarding mechanism) to provide 100% coverage. These methods
include tunneling, marking traffic, or U-turn traffic redirection.
Ordered FIB (OFIB)
Ordered FIB installation has the advantage that it provides 100% coverage for
all micro-loops - including ones due to asymmetric link cost. This method also
works with SRLGs. This however, may require different delays for different
sets of prefixes.
The disadvantage of Ordered FIB installation is that the worst-case network
convergence time depends on the diameter of the network - and this can be
quite long. When used with a repair mechanism that does not provide 100%
coverage some traffic will suffer a significantly longer disruption that it
would have experienced through conventional convergence. The length of the
network convergence time also raises the risk that another topology event will
occur before the network has converged; this could happen if there were
another failure or even a maintenance event during the interval.
The DT is also discussing the possibility of improving convergence time with
the OFIB proposal through use of explicit FIB-update-completion signaling.
The DT is in the process of discussing this method at the moment. Attractive
properties of this method include being able to cover 100% of cases, and
independence of transition time from the size of the network. On the other
hand, this method requires modifications to the routing protocol to support
"covert" topology change announcement, using tunneling introduces different
operational and security considerations, and the distributed version of the
method involves relatively higher level of complexity.
Combinations of PLSN with OFIB or Tunnels
Such a combination would make it possible to use the simpler PLSN method to
compliment the Basic FRR (LFA) mechanism, whose coverage would then be
extended with OFIB or Tunnels to reach 100% for the advanced FRR methods.
At this point the DT is still discussing different proposals. As the next
step, the design team is expected to come up with the recommendation of a
mechanism to compliment the Basic IP FRR specification.
The DT will give will provide a comprehensive report at the IETF-62 meeting in
Comments and feedback are appreciated.
Rtgwg mailing list