Hi, Tony:
From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Tony Li Sent: Wednesday, November 24, 2021 12:52 AM To: Aijun Wang <wangai...@tsinghua.org.cn> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Gyan Mishra <hayabusa...@gmail.com>; Christian Hopps <cho...@chopps.org>; lsr <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 Hi Aijun, I object to adding negative liveness to the LSDB because of the scale and because it adds scale during failures. [WAJ] If we have no such mechanism, operator should either advertise the host routes across areas(which has scale problem), or lose the fast convergences for some overlay services(which defeat the user experiences). Within the real network, there is very rare chance for the massive failure. And even such thing happen accidently, the information about node liveness is countable, is there any router can’t process such information? The received unreachable information does not trigger the SPF calculation. Will they influence intensively the performance of the router? If the scale is equal, then I would prefer to see flooding positive information rather than negative information. Operationally this is key: if there is a failure and positive information doesn’t propagate, then it’s a bug that will be found in due course and the operator can react outside of a failure scenario. [WAJ] What we want to do is the “Positive Summary”+” Specific Negative Information”. This can have both the summary scale advantage and also decrease the convergence time that based on the protocol hello timer. Having a scale failure on top of a topology failure is a far more painful scenario. The odds of a mass failure may be low. The fact of the matter is that they still happen. It is our job to ensure that the IGP performs well when it does. Increasing the size of the LSDB always affects performance. It slows flooding. Some nodes may not realize that SPF is not needed. When LSP fragments are rearranged, inferring that SPF is not necessary is non-trivial. Impacting router and network performance is a given. [WAJ] PUAM does not increase the overall size of the LSDB. It utilizes the existing LSA/TLV/Sub-TLV. My understanding is that N node failures would result in O(N) bytes added to the LSDB. If someone has a way to compress that information to O(1), I (and Claude Shannon) would be interested. [WAJ] Do you have other determined solutions except the PUB/SUB mechanism that does not exist in current IGP? None of the mechanisms being discussed currently exist. I have no objections to Robert’s BGP propagation ideas if that’s workable. This is simply not the IGP’s job and the IGP is not a dump truck. [WAJ] BGP is used within the internet, adding the false information within its protocol should be examined more carefully. As we have mentioned several times, the overall goals are not only for BGP usecaes, but also the prevailing Tunnel services. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
