Hi Russ, > so I could just missing something > that prevents eBGP convergence time from coming into play here (?).
As you see in this specific topology in the draft there are 16/32/64 ECMP paths so single or maybe even double failures of any node/link should not result in significant outage. It's still local repair. Best, R. On Mon, Sep 9, 2013 at 4:47 PM, Russ White <[email protected]> wrote: > >> - i think you skimp over the problems associated with bgp session failure >> detection / reconvergence. Mandating ebgp will get rid of the problems >> associated with the traditional loopback-to-loopback configuration of most >> ibgp networks, but there are still situations where dead link detection is >> going to be necessary using some form of keepalive mechanism which works >> faster than ebgp timers. It would be good to have a little more > discussion >> about bfd - if we can point vendors to good use cases here, they will be > more >> inclined to support bfd on tor boxes. > > Another point to consider is you're counting on there being an alternate > path always available to bring convergence to down detection time. If you > run eBGP in this situation, and there are multiple hops, any given AS will > only advertise one path to any destination to any other given AS; if that > path fails, you must eBGP converge to get back to forwarding, which is then > going to depend on route flap dampening (assuming this wouldn't be > configured here) and min route advertisement interval (assuming this would > be 0 here) --but either way, convergence isn't going to be in the msec. Note > this isn't local convergence, it's remote convergence --it's not reaction to > a link failure between the two peers, it's reaction to the link failure > several hops (eBGP wise) away. > > I think I had planned to think through this with Jon at one point, but we > never sat down and worked it out on paper, so I could just missing something > that prevents eBGP convergence time from coming into play here (?). > > iBGP would be faster to converge, given you're either using something like > add-paths at the RR, or something else, to improve convergence. We can't > fall back on "the igp will keep our bgp session up through some other path," > because there's no igp underneath. > > Russ > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
