> > As we’ve been saying for months now, the ordering is: > > 1) Leak PE loopbacks > 2) Pub/Sub > 3) Carry loopbacks in BGP and recurse > 4) Multi-hop BFD > 5) Pulse > 6) PUA
I would like to actually add to this list two alternatives which some vendors have been shipping for decades: X) Withdraw service routes based on the local next hop tracking trigger (from local RR) Y) Even Further Aggregate the withdraws as described in X X alone gives you today max a few seconds of connectivity disruption - if that is the overall goal we are heading to no 1-6 is required. Y as described in https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt and/or https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-nh-cost can even further reduce that. #3 above is even further speed up via native to BGP recursion. If BGP is not running there some service does and that service hopefully has better convergence characteristics then BGP. So the main point here is that yes it is highly recommended to use summaries across areas. But what's not clear (at least to me) is if we really need to signal node liveness in IGP to accomplish the ultimate goal of few sec connectivity restoration upon PE failure in the cases of redundant egress connectivity. I am perhaps restating the above but trying to look holistically at the problem. Especially as some folks apparently still believe that "BGP is slow" and that iBGP def timers of 180 sec are even relevant to the topic. They are clearly not. Many thx, Robert
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
