Loop protection and IPFRR

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 wont 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
• 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.
• Doesnt 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 lt 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?