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