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. 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. > 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. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
