IP AND LDP FAST PROTECTION SCHEMES

Julian Lucek

jlucek@juniper.net

Introduction to IP/LDP FRR

Schemes to improve LFA coverage:

•Remote LFA

•Dynamic RSVP bypass

Agenda

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 reuses IGP shortest-path trees, e.g.

• Loop-Free Alternate (LFA)

• Remote LFA (rLFA)

(ii) Protection traffic does not rely on shortest-path trees, e.g.

• RSVP bypass• On its own, or as a

supplement to LFA• Maximally Redundant

Trees (MRT)

Remote LFA

LFA COVERAGE ISSUE

S

R1

R2

R3R4

All links have the same metric.

Consider traffic travelling from S to D (via R1).

S has no viable LFA to protect the S-R1 link.

D

REMOTE LFA

S

R1

R2

R3R4

“Extended P-Space” contains the routers that S’s direct neighbours can reach without using the S-R1 link.

D

Extended P-Space

REMOTE LFA

S

R1

R2

R3R4

“Q-Space” contains the routers that normally reach D without using the S-R1 link.

DQ-Space

Extended P-Space

Router that is in both Extended P-Space and Q-Space is a PQ-node.

R2 and R3 are PQ-nodes.

COVERAGE EXTENSION USING REMOTE LFA

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 LSP follows the path S-R4-R3 without looping.

Once the traffic emerges at R3, the IGP metrics are in our favour so the traffic travels to D via R2 without looping.

R3 is known as a Remote Neighbour or PQ-node

Existing LDP LSP to R3

S

R1

R2

R3 (Remote neighbour)

R4

D

NUMBER OF PQ NODES PER NODE, FOR A REAL NETWORK TOPOLOGY

• 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!

0

100

200

300

400

500

600Number of PQ nodes per PLR

Node (in ascending order of number of PQ nodes)

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

0

10

20

30

40

50

60

70

80

90

100

Link protection coverage for remote LFA with 16 PQ nodes vs. local LFA only

Remote LFA Local LFA

0

10

20

30

40

50

60

70

80

90

100

Node protection coverage for remote LFA with 16 PQ nodes vs. local LFA only

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

1 LDP P2MP LSP

LDP unicast

LDP unicast

E

F

1 1

•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.•Let’s look in more detail at the label operations involved…

Protection path using LFA

B

C

A D

LINK PROTECTION USING LFA: LDP UNICAST CASE

•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.

LDP unicast

1

1 1

L2L1

E

F

B

C

A D

1 LDP P2MP LSP

D

1 1Protection tunnel:

LDP LSP to D

L22

L24

L23

LINK PROTECTION USING LFA: P2MP LDP CASE

• 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.

L21

E

F

B

C

A

LINK PROTECTION FOR LDP TRAFFIC: NO VIABLE LFA CASE

1 LDP P2MP LSP

LDP unicast

LDP unicast

1 50

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.

E

F

B

C

A D

LINK PROTECTION FOR LDP TRAFFIC USING DYNAMIC RSVP BYPASS TUNNEL

1 LDP P2MP LSP

LDP unicast

LDP unicast

1

•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.

50

D

Dynamic RSVP bypass to D

E

F

B

C

A

LINK PROTECTION FOR LDP TRAFFIC USING DYNAMIC RSVP BYPASS TUNNEL: LABEL OPERATIONS

•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.

1 LDP P2MP LSP

1 50

LDP unicast

L2L1

L22

L24

L23L21

D

Dynamic RSVP bypass to D

E

F

B

C

A

ALTERNATIVE MODES OF OPERATION TO ACHIEVE FULL COVERAGE

100%

LFA

Remote LFA

Dynamic RSVP bypass

100%

LFA

Dynamic RSVP bypass

100%

Dynamic RSVP bypass

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.