IP/LDP fast protection schemes

915 views
702 views

Published on

Презентация для доклада, сделанного в рамках конференции Juniper New Network Day 01.01.2014.

Докладчик -- Architect Specialist компании Juniper Networks Julian Lucek.

Видеозапись этого доклада с онлайн-трансляции конференции вы можете увидеть здесь:
http://www.youtube.com/watch?v=885L18ocIjY

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
915
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

IP/LDP fast protection schemes

  1. 1. IP AND LDP FAST PROTECTION SCHEMES Julian Lucek jlucek@juniper.net
  2. 2. Introduction to IP/LDP FRR Schemes to improve LFA coverage: •Remote LFA •Dynamic RSVP bypass Agenda
  3. 3. 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.
  4. 4. 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)
  5. 5. Remote LFA
  6. 6. 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
  7. 7. 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
  8. 8. REMOTE LFA S R1 R2 R3R4 “Q-Space” contains the routers that normally reach D without using the S-R1 link. D Q-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.
  9. 9. 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
  10. 10. 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 600 Number of PQ nodes per PLR Node (in ascending order of number of PQ nodes)
  11. 11. 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
  12. 12. 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
  13. 13. Dynamic RSVP bypass
  14. 14. 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.
  15. 15. 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.
  16. 16. 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
  17. 17. 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
  18. 18. 1 LDP P2MP LSP D 1 1 Protection 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. ALTERNATIVE MODES OF OPERATION TO ACHIEVE FULL COVERAGE 100% LFA Remote LFA Dynamic RSVP bypass 100% LFA Dynamic RSVP bypass 100% Dynamic RSVP bypass
  23. 23. 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.
  24. 24. 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
  25. 25. 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.

×