draft-dickson-idr-second-best Second-Best: A Path-Hunting Solution Brian Dickson

NB: changes to ID Normally, would not do this before a meeting But, removing things makes for easier review And, shortens the presentation REMOVED: BACKUP_ONLY  will propose backup_only as a well-known community instead

Purpose of this draft Provide a solution to path-hunting Secondary benefit – fix persistent oscillations

Cost Summary Requires additional memory usage for in-rib Initialization requires two passes of best-path Update processing cost (per update) will often be reduced, not increased (!)‏ Reduction in path-hunting further reduces update frequency, and thus total cost No impact to FIB size FIB updates when best changes – no different

Basic Idea: pick local second-best and send both best and second-best best second-best best second-best best second-best

Basic Idea: delete and send withdrawal immediately best second-best best second-best best second-best NB: This withdrawal is ALWAYS a transient state, and will be followed later with new Best (and Second Best if one exists). We do this to propagate the withdrawal as far and as fast as possible.

Basic Idea: promote second-best best second-best best second-best best second-best

Basic Idea: recalculate both (deferred update)‏ (old second-)best (new) second-best (old second-)best (new) second-best (old second-)best (new) second- best

Detail per prefix: received per peer best second-best best second-best best second-best Peer SendsIN-RIB RIB best second-best best second-best best second-best best second-best Peer A Peer B Peer C

Selection: Case 1 (normal)‏ best second-best best second-best best second-best Peer SendsIN-RIB RIB best second-best best second-best best second-best best second-best Peer A Peer B Peer C

Selection: Case 2 (rare)‏ best second-best best second-best best second-best Peer SendsIN-RIB RIB best second-best best second-best best second-best best second-best Peer A Peer B Peer C

Update criteria We always want a feasible second-best Second-best may temporarily not be truly second-best choice, but... Second-best must always be some peer's current best (or second-best, in the “rare” case)‏ Track linkages from IN-RIB to RIB for optimization, so we can... Avoid re-calculating best/second unnecessarily

Withdraw logic: modify IN-RIB only if best & second are not affected best second-best best second-best best second-best Peer SendsIN-RIB RIB best second-best best second-best best second-best best second-best Peer A Peer B Peer C No need to run new path selection process

Withdraw logic: promote IN-RIB second-best to RIB second-best best second-best best second-best best second-best Peer SendsIN-RIB RIB best second-best best second-best best second-best best second-best Peer A Peer B Peer C Defer running new path-selection rather than “blocking” But, do run new path selection process

Withdraw logic: no IN-RIB 2 nd best? Find new RIB 2 nd best (if possible)‏ best second-best best second-best best second-best Peer SendsIN-RIB RIB best second-best best second-best best Peer A Peer B Peer C Do NOT defer doing path-selection !!

Withdraw logic: no IN-RIB 2 nd best? Find new RIB 2 nd best (if possible)‏ best second-best best second-best best second-best Peer SendsIN-RIB RIB best Peer A Peer B Do NOT defer doing path-selection !!

Withdraw logic: no 2 nd best found? Withdraw 2 nd best (rare)‏ best second-best Peer SendsIN-RIB RIB best Peer A Peer B Do NOT defer doing path-selection !! NB: This withdrawal is NOT a transient state. This means recipient may process its changes immediately.

Withdraw 2 nd : modify IN-RIB only, if best & second are not affected best second-best best second-best best second-best Peer SendsIN-RIB RIB best second-best best second-best best second-best best second-best Peer A Peer B Peer C No need to run new path selection process

Withdraw 2 nd logic: affect 2 nd best? Find new 2 nd best (if possible)‏ best second-best best second-best best second-best Peer SendsIN-RIB RIB best second-best best second-best best second-best best second-best Peer A Peer B Peer C Do NOT defer doing path selection!

EBGP Peers: suppression logic and 2 nd best selection best second-best best (second-best)‏ OUT-RIBIN-RIB RIB (best) [suppress] second-best best second-best Router A best second-best best second-best best second-best best second-best Router B OUT-RIB IN-RIB RIB Special case!

EBGP Peers: Withdraw results in: temporary routing loop... best second-best best (second-best)‏ OUT-RIBIN-RIB RIB (best) [suppress] (second-)best best second-best Router A best second-best best second-best best second-best best (second-)best Router B OUT-RIB IN-RIB RIB Special case!

EBGP Peers:...a loop that disappears quickly best (second-)best best (second-best)‏ OUT-RIBIN-RIB RIB (best) [suppress] (second-)best best (second-)best Router A best (second-)best best second-best best second-best best (second-)best Router B OUT-RIB IN-RIB RIB Special case!

IBGP Peers: suppression logic and 2 nd best selection best second-best RIB Router A best second-best best second-best Router B RIB Router C

IBGP Peers: withdrawal behaviour: sub-optimal, no loop... best second-best RIB Router A best second-best best (second-)best Router B RIB Router C

IBGP Peers:... and then optimal best second-best RIB Router A best (second-)best best (second-)best Router B RIB Router C

Comparison with draft-walton-* draft-walton-add-paths and -bgp-route- oscillation address only the oscillation issue draft-walton requires more than 2 route instances, more memory doesn't affect path-hunting behaviour does solve oscillation issue this draft also solves oscillation issue (via its minor tweak to path selection)‏

Comparison with draft-filsfils-* draft-filsfils provide a cute hack for achieving fast convergence for one specific case requires multipath-bgp, and carrying peering network in IGP (an operational risk for third- party unpaid transit, BTW)‏ only affects local AS convergence, has no affect on path-hunting remains to be seen how well it compares to second-best on that specific scenario

Comparison with sigcomm2000 paper example Excellent paper by Labowitz, Ahuja, Bose, Jahanian, sigcomm2000 on Delayed Internet Routing Convergence Examples of unconstrained redistribution and path-hunting steps observed, v.s. MRAI timers With proposed modification, withdrawal propagation occurs without MRAI timer exp. Minimal announcements, mostly withdrawals Nearly no path hunting – withdrawals catch up

Example – 4-node mesh Key: [Router((list of best paths),(list of second-best paths))] where: *Best +Second-Best - (no entry or supressed due to loop prevention)‏ Initial State (steady state, queues empty)‏ 0((*R,+1R,2R,3R),(-,-,-,-))‏ 1((*R,+0R,2R,3R),(-,-,20R,30R))‏ 2((*R,+0R,1R,3R),(-,01R,10R,30R))‏ 3((*R,+0R,1R,2R),(-,01R,10R,20R))‏

Example – 4-node mesh – option 1 Option 1: Triggering of re-calculate immediately upon receiving Withdraw(Best)‏ State of each router's IN-RIBs Queue(s) of messages Initiating withdrawal and subsequent possible path hunting: R->0 RW; R->1 RW; R->2 RW; R->3 RW processing queued messages... 0((-,+1R,2R,3R),(-,-,-,-)) 0->1 0RW; 0->2 0RW; 0->3 0RW 1((-,+0R,2R,3R),(-,-,20R,30R)) 1->0 1RW; 0->2 1RW; 1->3 1RW 2((-,+0R,1R,3R),(-,01R,10R,30R)) 2->0 2RW; 2->1 2RW; 2->3 2RW 3((-,+0R,1R,2R),(-,01R,10R,20R)) 3->0 3RW; 3->1 3RW; 3->2 3RW recalculating... 0((-,*1R,+2R,3R),(-,-,-,-)) 0->1 (-,02R); 0->2 (01R,-); 0->3 (01R,02R)‏ 1((-,*0R,+2R,3R),(-,-,20R,30R)) 1->0 (-,12R); 1->2 (10R,-); 1->3 (10R,12R)‏ 2((-,*0R,+1R,3R),(-,01R,10R,30R)) 2->0 (-,21R); 2->1 (20R,-); 2->3 (20R,21R)‏ 3((-,*0R,+1R,2R),(-,01R,10R,20R)) 3->0 (-,31R); 3->1 (30R,-); 3->2 (30R,31R)‏ [begin MRAI timers] processing queued messages... 0((-,-,-,-),(-,12R,23R,31R)) 0->1 (-,02R) 02RW 03RW; 0->2 (01R,-) 01RW 03RW; 0->3 (01R,02R) 01RW 02RW 1((-,-,-,-),(-,02R,23R,30R)) 1->0 (-,12R) 12RW 13RW; 1->2 (10R,-) 10RW 13RW; 1->3 (10R,12R) 10RW 12RW 2((-,-,-,-),(-,01R,13R,30R)) 2->0 (-,21R) 21RW 23RW; 2->1 (20R,-) 20RW 23RW; 2->3 (20R,21R) 20RW 21RW 3((-,-,-,-),(-,01R,12R,20R)) 3->0 (-,31R) 31RW 32RW; 3->1 (30R,-) 30RW 32RW; 3->2 (30R,31R) 30RW 31RW processing queued messages... 0((-,-,-,-),(-,-,-,-))‏ 1((-,-,-,-),(-,-,-,-))‏ 2((-,-,-,-),(-,-,-,-))‏ 3((-,-,-,-),(-,-,-,-))‏ Total steps: 13 Number of MRAI timer expiries: 0 Total elapsed time: O(RTT*3 + 3*CPU_COST), possibly << 1s.

Example – 4-node mesh – option 2 Option 2: Delay triggering path selection and announcements until queues are drained: State of each router's IN-RIBs Queue(s) of messages Initiating withdrawal and subsequent possible path hunting: R->0 RW; R->1 RW; R->2 RW; R->3 RW processing queued messages... 0((-,+1R,2R,3R),(-,-,-,-)) 0->1 0RW; 0->2 0RW; 0->3 0RW 1((-,+0R,2R,3R),(-,-,20R,30R)) 1->0 1RW; 0->2 1RW; 1->3 1RW 2((-,+0R,1R,3R),(-,01R,10R,30R)) 2->0 2RW; 2->1 2RW; 2->3 2RW 3((-,+0R,1R,2R),(-,01R,10R,20R)) 3->0 3RW; 3->1 3RW; 3->2 3RW 0((-,-,-,-),(-,12R,23R,31R)) 0->1 02RW 03RW; 0->2 01RW 03RW; 0->3 01RW 02RW 1((-,-,-,-),(-,02R,23R,30R)) 1->0 12RW 13RW; 1->2 10RW 13RW; 1->3 10RW 12RW 2((-,-,-,-),(-,01R,13R,30R)) 2->0 21RW 23RW; 2->1 20RW 23RW; 2->3 20RW 21RW 3((-,-,-,-),(-,01R,12R,20R)) 3->0 31RW 32RW; 3->1 30RW 32RW; 3->2 30RW 31RW 0((-,-,-,-),(-,-,-,-))‏ 1((-,-,-,-),(-,-,-,-))‏ 2((-,-,-,-),(-,-,-,-))‏ 3((-,-,-,-),(-,-,-,-))‏ Total steps: 9 Number of MRAI timer expries: 0 Total elapsed time: O(RTT*2 + 2*CPU_COST), possibly << 1s.

Summary Incremental to current BGP standard Extra memory needed  Sensible implementations likely to minimize the impact of additional paths/attributes No additional FIB usage Reduced CPU usage, bandwidth, churn Dramatically faster local and global convergence Next steps?

Thank you Presentation on IETF 71 site Draft updates forthcoming (including some presented here and sent to IDR list)‏ Author: Brian Dickson,