s/ 1 days ago you said/ 11 days ago you said/ Apologies, R.
On Mon, Nov 29, 2021 at 11:53 PM Robert Raszuk <rob...@raszuk.net> wrote: > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
