Hi, Tony:
From: [email protected] <[email protected]> On Behalf Of Tony Li Sent: Tuesday, November 23, 2021 12:52 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Gyan Mishra <[email protected]>; Christian Hopps <[email protected]>; Aijun Wang <[email protected]>; lsr <[email protected]>; Acee Lindem (acee) <[email protected]>; Tony Przygienda <[email protected]> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Les, It is not clear to me why having the IGP advertise information that it already knows is considered an “architectural violation”. It is even less clear to me since it would not be considered a violation if an operator didn’t configure a summary and the IGP advertised all the individual prefixes it knew about all the time. (Whether that is a wise choice in a given deployment is another matter.) The IGP knows many things. I object to adding things to the LSDB that aren’t already there. [WAJ] Then, how to explain the newly defined “Dynamic Flooding LSA” in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-09, which is not already in LSDB before? If people want to leak things outside of the area, I object to that. I know that people do it already. Yes, there are valid cases where it’s necessary and there are tools to do it. People abuse the privilege and then wonder why their IGP has indigestion. Go figure. 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? As to scale, you are making the assumption that a solution cannot be provided without introducing significant scale issues – but I don’t think that is the case. I don’t want to use this thread to advocate for one candidate solution over another – I think that is best addressed in some subsequent thread. Just want to point out that the solution does not have to have the same scale characteristics as having no summaries. 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? Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
