1. Loop protection and IPFRR
Alia Atlas
Stewart Bryant
Mike Shand

2. Loop-prevention techniques under discussion
PLSN
oFIB
Tunnels?
There are many cool things you can do with tunnels, but…
Ubiquitous tunnelling is coming, but not yet
Really need a solution now!
We won’t consider tunnels for loop-prevention

3. Applications Planned operational maintenance for topology changes
including metric changes for TE purposes
Unplanned changes (i.e. failures)
IPFRR
MPLS FRR
I.E. loop free convergence is an IETF matter not just an IPFRR local matter

4. PLSN characteristics Around 80% protection Computed per prefix
But VERY topology sensitive
On average prevents 50% of current loops
Computed per prefix
Completed in 3 worst case FIB times
2 without type B
Deals naturally with SRLG
Albeit, with reduced protection
Good correlation with LFA
Partial coverage poor for managed change

5. oFIB characteristics 100% protection
Simple computation for single link or node change
SRLG requires computation per failed link (worst case)
Adds optimizing message to obtain sub-second convergence
Worst case if all messages lost is up to network diameter (worst case) FIB times.
Doesn’t build on PLSN
Handles managed changes and single failures completely.
Messages add some implementation complexity

6. Management application constraints
Really need 100% coverage for management changes
Otherwise they are not benign
SRLG not an issue – because you can always decompose into constituent links
Points to oFIB

7. IPFRR application constraints
For “basic” IPFFR PLSN fits well
Coverage is correlated
But oFIB is better because it has 100% coverage
Of course, an incomplete IPFRR mechanism means that a longer convergence may be of concern.
For any complete fast reroute method 100% loop prevention is highly desirable.

8. IPFRR technologies under discussion
“basic” (LFAs)
Not-via

9. LFA charactersitics Only 80% (65% to 95%) coverage
Good in highly meshed topologies
Poor in “ring” topologies
Difficult to ensure particular “customers” get good service
Even when so engineered, a single failure may break it for subsequent failures

10. Not-via characteristics
100% coverage in all cases
Intuitive repair paths
Next best path
Close to path used after re-convergence
Requires tunnels
But combining with LFAs reduces the volume of tunnelled traffic in most topologies
Only required at protecting nodes, not all nodes on repair path
Computational complexity about an order of magnitude worse than normal SPF
Not-via typically < 100mS compute
Slightly longer for complex SRLGs
Requires an extra (private) address per interface
Can assign a “group” to a router and allow automatic allocation.

11. Discussion?