Hi Les, Just to summarize my personal take on this thread in the light of your last email.
#1 - I am not ok with the ephemeral nature of the advertisements. (I proposed an alternative). #2 - I am not ok with spreading the information everywhere including all P and PE routers which do not need it. #3 - 1 days ago you said: "The legitimate question is whether folks see it as appropriate to have an IGP based solution for the problem." So bringing a BGP alternative seems to be very much in line with your guidance for this thread. #4 - I am not sure it is OK for IGP to advertise a bunch of area local info to every IGP node. The fact that it was pushed through IETF with brute force does not make it a great protocol evolution. Maybe now it is time to close that gate ? Kind regards, Robert [LES:] BGP-LS only advertises what the IGPs themselves advertise. > > In this case, both IGP proposals involve ephemeral advertisements - so > even if we were to define BGP-LS support for these new advertisements - > they wouldn't persist long enough to be reflected in BGP-LS. > > So, I really don’t know why we are discussing BGP-LS in the context of > this thread. > > (This seems to be one example of what Acee correctly identified as this > discussion going "off track".) > > > [LES:] I am not convinced either side can claim "consensus" in this > discussion. That is a work in progress. 😊 > > However, when you say IGPs are (exclusively?) for topology discovery - it > seems to suggest that IGP shouldn’t be advertising prefix reachability at > all. Hopefully, that is not what you intend. > > > > One of the points that still baffles me is the assertion of an > architectural violation in the IGP proposals. > > > > It is OK for IGPs to advertise all prefixes covered by a summary (i.e., do > not summarize). > > It is OK for IGPs to advertise multiple summaries (e.g., multiple /24s > instead of a single /16). > > It is even OK for IGPs to advertise some prefixes covered by a summary > along with the summary (don’t know if any implementations do this - but > they could). > > None of this is an "architectural violation". > > > > But advertising a summary and signaling the loss of reachability to a > specific prefix covered by the summary is seen by some as an architectural > violation. > > Sorry, I still don't understand this argument. > > > > You can not like the approach. You can be concerned about scaling > properties (more on that below). You can question the effectiveness of > ephemeral advertisements. > > These kinds of objections/concerns I can easily understand - even if we > don’t agree on their significance. > > But claiming that "IGPs are not supposed to do this"?? > > Not grokking this. > > > > We have not added any new information to the IGP itself. We are only > suggesting a new form of advertisement to signal some information already > known to the IGP, but which is currently not advertised (in some > deployments) by the configuration of summaries. > > [LES:] The questions of scale (as I have previously commented) are very > legitimate - and more has to be specified before an IGP solution would be > considered ready for deployment. But there are tools easily applicable to > address this (rate limiting, embedded summarization, perhaps others). > > The more significant point is to focus on the goal - which in this usage > is improved convergence time. > > When the network is largely stable, convergence improvements can be > achieved w/o risk. > > When widespread failures occur, real time signaling of any type is > unlikely to provide improved convergence - which is why the IGPs today > shift the focus from convergence to stability by slowing down the rate of > updates sent and SPFs performed. This is STILL true even in the fast > convergence/FRR era. > > I see no reason why the same tools should not be used in this case. > > > > Les >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
