IP AND LDP FAST PROTECTION

SCHEMES
Julian Lucek

jlucek@juniper.net
 Agenda

Introduction to IP/LDP FRR

Schemes to improve LFA

coverage:
Remote LFA
Dynamic RSVP bypass
FAST PROTECTION SCHEMES

Several years ago, the situation was simple: the

only choice was RSVP LSPs, with FRR
activated.
In the meantime, there has been a lot of interest
in fast protection schemes for IP/LDP traffic.
There is also interest in protecting LDP P2MP
traffic, in addition to LDP unicast traffic.
TWO MAIN CATEGORIES OF IP/LDP FRR SCHEME

(i) Protection traffic (ii) Protection traffic does

reuses IGP shortest- not rely on shortest-path
path trees, e.g. trees, e.g.
Loop-Free Alternate RSVP bypass
(LFA) On its own, or as a
Remote LFA (rLFA) supplement to LFA
Maximally Redundant
Trees (MRT)
Remote LFA
 LFA COVERAGE ISSUE

D
R1
All links have the same
metric.

Consider traffic travelling

S R2
from S to D (via R1).

S has no viable LFA to

protect the S-R1 link.
R4 R3
 REMOTE LFA

D
R1
Extended P-Space
contains the routers that Ss
direct neighbours can reach
R2
without using the S-R1 link.
S

R4 R3

Extended P-Space
 REMOTE LFA

Q-Space
D
R1
Q-Space contains the
routers that normally reach D
without using the S-R1 link.
S R2
Router that is in both
Extended P-Space and Q-
Space is a PQ-node.

R4 R3 R2 and R3 are PQ-nodes.

Extended P-Space
 COVERAGE EXTENSION USING REMOTE LFA

D
R1
In order to get the traffic past R4,
traffic is tunnelled to R3 via the LDP
LSP that terminates at R3.

Given the IGP metrics, this LDP

S R2 LSP follows the path S-R4-R3
without looping.

R3 (Remote Once the traffic emerges at R3, the

neighbour)
IGP metrics are in our favour so the
traffic travels to D via R2 without
R4 looping.

Existing LDP R3 is known as a Remote

LSP to R3 Neighbour or PQ-node
NUMBER OF PQ NODES PER NODE, FOR A REAL
NETWORK TOPOLOGY
Number of PQ nodes per PLR
600

500

400

300

200

100

Node (in ascending order of number of PQ nodes)

Modelling on a real network with ~600 nodes.

From the point of view of a typical node X, most
of the nodes in the entire network are PQ nodes
with respect to some primary next-hop of X!
PQ-NODE SELECTION

PLR needs to perform a forward SPF rooted at each

PQ-node
c.f. draft-psarkar-rtgwg-rlfa-node-protection
Not practical for a PLR to do this for hundreds of PQ-
nodes.
In practice, implementations need heuristics for each
PLR to select a subset of PQ nodes for it to use, for
example based on:
Amount of protection given by each candidate PQ-
node
Distance (metric) from PLR to candidate PQ-node
 Link protection coverage for remote LFA with 16 PQ nodes vs. local LFA
only
100
90
80
70
60
50
40
30
20
10
0

Remote LFA Local LFA

Node protection coverage for remote LFA with 16 PQ nodes vs. local LFA
only
100
90
80
70
60
50
40
30
20
10
0

Remote LFA Local LFA

Dynamic RSVP bypass
ALTERNATIVE WAYS OF ACHIEVING FULL COVERAGE

So far, we have discussed schemes in which

protection traffic follows the IGP.
Coverage achieved depends on topology and IGP
metrics.
Alternative approach: use a source-routed
tunnel for the protection traffic.
E.g. an RSVP bypass.
Either instead of LFA, or as a supplement to LFA.
Get 100% coverage - can use any path we like
for the protection tunnel, regardless of
topology/metrics.
EXTENDING LFA COVERAGE USING RSVP TUNNEL:
EXAMPLE IMPLEMENTATION

Link protection scheme - applies to both unicast

LDP and P2MP LDP (mLDP) traffic.
RSVP bypasses created dynamically, to in-fill
LFA coverage gaps.
RSVP bypasses are only used for protection
do not interfere with normal forwarding.
Already supported in Junos production code.
 LINK PROTECTION FOR LDP UNICAST AND LDP P2MP

E
1 Protection path 1
using LFA

A B D LDP
LDP
1 unicast
P2MP LSP

LDP
unicast F

B needs to protect the B-D link, for LDP unicast and LDP P2MP traffic.
Given the metrics shown, C is a viable LFA neighbour, so if the B-D link breaks, LFA action
is employed.
Lets look in more detail at the label operations involved
 LINK PROTECTION USING LFA: LDP UNICAST CASE

E
1
1

A B D
1

L1 L2
LDP
unicast F

L3 is the LDP unicast label for FEC F advertised by C to B.

Repair action: B swaps label L1 for L3 and sends packet to C.
This is the normal LFA action that has been available for several years
for LDP.
 LINK PROTECTION USING LFA: P2MP LDP CASE
C

E
1 1
Protection tunnel:
LDP LSP to D
A B D LDP
1
L24 P2MP LSP

L21 L22
L23
F

P2MP LDP case is different from unicast case on previous slide, as C has no
knowledge of the P2MP LSP. Instead, LDP LSP to D provides protection.
L10 is the LDP unicast label for FEC D advertised by C to B.
Repair action: B swaps the LDP P2MP label L21 for L22, pushes the label L10
on top and sends to C.
C pops label L10 (due to PHP). Packet arrives at D with originally expected label
value of L22.
LINK PROTECTION FOR LDP TRAFFIC: NO VIABLE
LFA CASE
C

E
1 50

A B D LDP
LDP
1 unicast
P2MP LSP

LDP
unicast F

What if the topology/metrics mean that there is no LFA present?

High metric between C and D means C is not an LFA of B.

 LINK PROTECTION FOR LDP TRAFFIC USING
DYNAMIC RSVP BYPASS TUNNEL
C

E
1 50
Dynamic RSVP
bypass to D
A B D LDP
1 unicast LDP
P2MP LSP

LDP
unicast F

Given the metrics shown, C is not a viable LFA neighbour of B.

B realises this, and automatically pre-builds an RSVP bypass tunnel to D to
protect the traffic.
LINK PROTECTION FOR LDP TRAFFIC USING DYNAMIC
RSVP BYPASS TUNNEL: LABEL OPERATIONS
C

E
1 Dynamic RSVP 50
bypass to D
A B D LDP
1
L24 P2MP LSP

L21 L22 L23

L1 L2 LDP F
unicast

Repair action: B swaps the LDP label as normal, pushes the RSVP
bypass label L40 on top and sends to C.
C pops label L40 (due to PHP). Packet arrives at D with originally
expected LDP label value.
ALTERNATIVE MODES OF OPERATION TO ACHIEVE
FULL COVERAGE
Dynamic
RSVP
bypass
Dynamic
RSVP
bypass Remote
LFA

Dynamic
100% RSVP
100% 100% bypass

LFA LFA
COMMENTS ABOUT DYNAMIC RSVP BYPASS
SCHEMES

Very simple to use and understand.

100% coverage, as long as there is some other
way of reaching the far-end router of the protected
link.
Can be used to protect both unicast and multicast
(P2MP) LDP traffic.
Use of RSVP bypass is consistent with protection
scheme for RSVP point-to-point and RSVP P2MP
LSPs.
Total number of RSVP LSPs needed is low.
Only one per link per direction, in the worst case.
WHITEPAPER

Whitepaper available describing the LFA +

dynamic RSVP scheme
Has router configs and router show-command
outputs
Please send me an email or ask your account
team to receive a copy
 Conclusions

Remote LFA improves LFA coverage quite well.

Important for implementations to have good heuristics for
PQ-node selection.

Dynamic RSVP bypasses are a very attractive alternative

or supplement to LFA/rLFA.
Easy to use and understand.
Fully automated.
100% coverage.