Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk <[e-mail]>]

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