In such cases I would rather consider implementing pulse to be less then host route.
Suppressing them randomly may lead to even bigger disappointment of unreachability propagation hence delaying connectivity restoration to a backup path. Many thx, R. On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak <[email protected]> wrote: > Robert, > > On 18/11/2021 13:42, Robert Raszuk wrote: > > [WAJ] In the scenarios that you mentioned, BGP nexthop reachability > > is derived from the directed interface, there is no summary action > > done by the router. Is that true? > > > > > > Not necessarily - TORs do not always do eBGP to compute and set next hop > > self. There can be IBGP session there and therefor next hop is not > > changed all the way to the remote compute. But the point was that today > > BGP is involved already in reachability and service distribution. > > > > And while current IGP proposals can propagate this too the point is > > about scalability when it comes to signalling of such massive failures > > in the IGP. The amount of IGP traffic and processing in those moments > > may be significant. > > we can certainly address such case by not allowing thousands of pulses > to be generated in case half of the universe falls apart. That seems > obvious and easy to implement. > > thanks, > Peter > > > > > And yes I agree this is not really a "hole punching" ... that was just a > > description shortcut I used. > > > > Thx, > > R. > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
