Hi Tony, > How so? Doesn’t this correspond 1:1 with overlay BGP sessions?
Not at all. BGP is never full mesh across multiple areas. RR hops are used. BFD does not have concept of RRs last time I looked at it :) Kind regards, R. On Thu, Nov 18, 2021 at 5:38 PM Tony Li <[email protected]> wrote: > Les, > > You are not retaining scalability. You are damaging it. You are proposing > flooding a prefix per router that fails. If there is a mass failure, that > would result in flooding a large number of prefixes. The last thing you > want when there is a mass failure is additional load, exacerbating the > situation. > > *[LES2:] It is reasonable to limit the rate of pulses sent. Peter has > already indicated in an earlier reply that we will address that in a future > version of the event-notification draft. So, good point – and we are in > agreement regarding mass failure.* > > > > The fact that you have to limit the result is a pretty clear indication > that this is not architecturally appropriate. > > > You are signaling the (lack of) liveness of a remote node. I propose that > we instead use existing signaling mechanisms to do this. Multi-hop BFD > seems like an obvious choice. > *[LES2:] Conceptually this works. But I don’t think it scales.* > > > > How so? Doesn’t this correspond 1:1 with overlay BGP sessions? > > > If you greatly dislike that for some reason, I would suggest that we > create a proxy liveness service, advertised by the ABR. This would allow > correspondents to register for notifications. The ABR could signal these > unicast when it determines that the specific targets are unreachable. > > *[LES:] This would be a significant effort to provide such a service.* > *Granted, implementation of “pulse” is also a significant effort – so I am > not objecting to your idea simply based on that. I am just pointing out > that what you propose does not currently exist – so if you are serious > about this alternative you need to provide the details.* > > > > Fear of hard work does not make it the IGP’s problem. > > I am not the one with the issue. Those with the issue should propose the > details. At most, the IGP should carry a capability for this service. > > Tony > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
