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