Hi, Robert: If you use iBGP in your mentioned scenario, how to propagate the reachability of BGP nexthop? I think it is impossible to use again BGP itself. Then depend only BGP can’t solve your problem.
If the underlying using IGP to propagate such reachability information, we have mechanism to control for which covered prefix to send the notification when they become unreachable. It is not randomly suppressed. Aijun Wang China Telecom > On Nov 18, 2021, at 21:27, Robert Raszuk <[email protected]> wrote: > > > > 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
