1 / 26

IPFRR Extensions

IPFRR Extensions. Presentation at SIMULA IPFRR workshop. Oslo 20 th April 2007 Stewart Bryant & Mike Shand. Disclaimer. The ideas and problems discussed here are the thoughts of the authors and may or may not represent future Cisco product direction. The story so far….

mufutau-reeves
Download Presentation

IPFRR Extensions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPFRR Extensions Presentation at SIMULA IPFRR workshop. Oslo 20th April 2007 Stewart Bryant & Mike Shand

  2. Disclaimer • The ideas and problems discussed here are the thoughts of the authors and may or may not represent future Cisco product direction.

  3. The story so far… • IETF “basic” gives 80% protection • Not-via gives 100% • Present IETF direction is a combination of these two • Assumption has been that full topology information is available • i.e. Link-state routing protocols

  4. Explain not-via (link state)

  5. What about non-link state protocols? • Not-via requires computation of a route NOT VIA the potential failure. • With complete topological information this is computed at each node by incrementally removing the failure component and recomputing the path to the far side of the failure. • Non-link state protocols (e.g. RIP, BGP) perform a distributed computation of the optimum path. • By selectively filtering routing information for specific “not-via” addresses, such that a not-via address is never advertised across the failure to which it relates a distributed computation of the optimum not-via path can be achieved.

  6. Normal DV B(0) A B B B(1) B(0) B(2) D C B(1)

  7. Not-via DV Ba(0) A B Ba Ba(0) Ba(2) D C Ba(1)

  8. Filtering • For link protection the not-via advertisement can be filtered either by the source B, or the recipient A. • For node-protection ALL not-via advertisements referring to the protected node must be prevented from forming a path through it • Simplest to filter at the protected node

  9. Node protecting Not-via DV Cb(0) A B C Cb(0) Cb(1) Cb(3) F E D Cb(1) Cb(2)

  10. Additional information for node protection • For link protection the next hop, and hence required not-via address, is obvious • For node protection we need next-next-hop information. • i.e. which of the protected node’s neighbors should we repair the traffic to? • Various possible solutions, e.g…. • draft shen-nnhop? • BGP AS path list? • But do we actually NEED node protection?

  11. Step-wise deployment • Not-via advertisement is just another address • Only protecting routers need to understand special semantics • Correct not-via routes will automatically be computed by legacy routers.

  12. BGP example AS1 AS2 Yx X Y AS3

  13. BGP • Various possibilities for • Inter-AS Link protection • Border Node protection • Etc. • All using DV not-via propagation techniques

  14. Applicability • Not-via can be used in:- • Link State • Distance Vector • Path Vector • Are there any other fundamental classes of routing protocol which need to be considered?

  15. P’ C P’ C A S N P B P’’ D A S N P B P’’ D Local Area Networks - 1 S knows that it is not seeing BFD responses from P. P’ C P’ C A S N P B A S N P B P’’ D P’’ D Without further diagnostics, it does not know whether its connection to the LAN, P’s connection to the LAN, the LAN, or P has failed.

  16. Local Area Networks - 2 P’ C A S N P B P’’ D Without further diagnostics S must treat SP adjacency failure as a failure of the node P and the WHOLE LAN

  17. Local Area Networks - 3 • S can correlate adjacency checks from P, P’, and P’’, and diagnose • failure of P, in which the repair can traverse the LAN • failure of the LAN, in which case the repair can traverse P, but NOT the LAN. • However, slower and more complex P’ C Bp Plan A S N P B Similarly for P’,P’’,C & D P’’ D

  18. Failure of a router attached to a LAN P’ C P’s A S N P B Ps P’’s P’’ D When S fails, A needs to repair to all the other LAN members. Hence they each need a not-via S address Similarly, when P fails B needs a not-via P address on all others

  19. Proliferation of NV addresses • Each LAN member requires a not-via address for every other LAN member • N2 addresses {N(N-1) + N not-via LAN} • Could we reduce this to N at the expense of further complexity? • Is the complexity worth the gain?

  20. A partial solution • A needs to repair to only ONE other LAN member • By definition, able to reach ALL other LAN members using LAN, since LAN has not failed. • DR advertises not-via address for all other LAN members (N-1 addresses) • In case the DR fails, “secondary” DR advertises not-via address for DR (1 address)

  21. Simple DR repair P’ C A S N P B DRs P’’ D e.g. if P’’ is DR, If S fails, A repairs to DRS P’’ then forwards to B via P

  22. P’ C A S N P B DRs P’’ D 10 But… • The lowest cost path from P’’ to P (and hence B), MAY be back through A • Could we detect this “strange” topology and forbid the repair? • Or use directed forwarding?

  23. LANs conclusion • How much of a problem are LANs in reality? • Common in enterprise and data centre. • How hard do we need to try to optimize their repair? • Are there any other approaches?

  24. Multiple routing domains • Where there are multiple routing domains topology information is hidden to provide the necessary scaling, e.g. • IS-IS leve1 & level 2 • BGP & IGP • IBGP & EBGP • How much of a problem is this to IPFRR? • Effect of summarization • Inability to find all paths • Interaction between repair mechanisms • E.g. BGP and IGP both attempting a repair for the same failure • Timers may help, but is this the right strategy?

  25. BGP loop free convergence? • Do we need it? • If so, how do we do it? • Can we adapt existing link state methods? • Or do we need a fundamentally new method?

  26. Next generation routing • So far we have only considered retrofitting IPFRR to existing routing protocols • IETF “Routing and addressing” is considering possible new routing architectures for the internet • Should IPFRR be designed in on day one? • Would this change the fundamental design of a routing protocol? • If so, how?

More Related