Tony - From: Lsr <lsr-boun...@ietf.org> On Behalf Of Tony Li Sent: Thursday, November 18, 2021 8:07 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Gyan Mishra <hayabusa...@gmail.com>; Christian Hopps <cho...@chopps.org>; Aijun Wang <wangai...@tsinghua.org.cn>; lsr@ietf.org; Acee Lindem (acee) <a...@cisco.com>; Tony Przygienda <tonysi...@gmail.com> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes
Les, Why would we then punch holes in the summary for member routers? Just because we can? [LES:] No. We are doing it to improve convergence AND retain scalability. You are not improving convergence. You are propagating liveness. The fact that this relates to convergence in the overlay is irrelevant to the IGP. 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. Should we corrupt the architecture just because we can? There are other, architecturally appropriate solutions available. How about we just use them? [LES:] What are you proposing? 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. 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. Les Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
