> If you want to address this problem with BGP keep alive timers, that’s certainly an alternative as well.
Nope that is not what I previously described in this thread. BGP uses recursion. So you can propage next hops in BGP and recurse your service route next hops over those with simple config knob to only consider /32 or /128 routes as next hops. Local detection of node going down can be done with BFD or LOS: TOR to RR or Compute to TOR or ... BGP propagation via few RRs will be in milliseconds. Then you can also apply constrain equal to service route constrains to limit the blast to only those targets which need that info. Not sure how to do such limiting in proposed IGP solutions. Thx, R. On Thu, Nov 18, 2021 at 5:16 PM Tony Li <tony...@tony.li> wrote: > > Robert, > > Why would we need to deploy a full mesh of BFD or introduce a new proxy > liveness service if BGP can do all what is needed here with just a few > lines of additional cfg on existing and deployed operating systems ? > > > > If you want to address this problem with BGP keep alive timers, that’s > certainly an alternative as well. > > Additional configuration is not a good metric on architectural complexity > and fragility. The worst ‘features’ can be enabled with a single line. :) > > > In respect to using BFD here - let's start with basic question - who would > be the producer to install those host routes into RIB ? Note in the > discussed scenario there are not there today - only summary is there. > > > > Why do you assume that BFD would produce a route? I would instead suggest > that the overlay BGP would register with BFD for notifications about a > remote. > > Tony > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
