Hi Les, Great, we are finally getting some focus !
Stating as an open question to use IGP or not for signalling PE disappearance seems to me not proper in light of the facts that IGP can do it already today by leaking. IMO we are debating two proposals - both ephemeral - both introducing even more opaque data to be flooded by IGP. I guess this is the crux of the issue. IGPs should flood topology without any subscription. 100%. But we are not debating that. We are debating the scope of opaque information distribution by IGPs. Opaque to the topology computation. That along with leaking should be subscription based. Yes IGPs can help with that easily. I think both are completely different paradigms and we should not put them in the same basket. Many thx, Robert On Tue, Nov 30, 2021 at 12:08 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of * Robert Raszuk > *Sent:* Monday, November 29, 2021 2:54 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Aijun Wang <wangai...@tsinghua.org.cn>; Shraddha Hegde < > shrad...@juniper.net>; Tony Li <tony...@tony.li>; Hannes Gredler < > han...@gredler.at>; lsr <lsr@ietf.org>; Peter Psenak (ppsenak) < > ppse...@cisco.com> > *Subject:* Re: [Lsr] BGP vs PUA/PULSE > > > > s/ 1 days ago you said/ 11 days ago you said/ > > > > *[LES:] Thanx for the correction. **😊* > > > > 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). > > > > *[LES:] So are you agreeing that an IGP solution should be pursued??* > > *This thread is (or should be) about whether the WG wants to pursue an IGP > based solution at all.* > > *If we have consensus on that, then we can discuss (in another thread > hopefully) whether either of the two current proposals is a good starting > point – or whether a yet to be defined new IGP proposal is best.* > > *We aren’t there yet.* > > > > #2 - I am not ok with spreading the information everywhere including all P > and PE routers which do not need it. > > > > *[LES:] Understood. But IGPs should not be used to provide a subscription > service. That is definitely inconsistent with the nature of a link state > protocol.* > > *So, if your preferred solution is a subscription service, then you are > saying “not an IGP solution”.* > > > > #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. > > > > *[LES:] Having a BGP solution is a legitimate consideration, but its > relevance to this thread is only whether it precludes an IGP solution.* > > *Some folks (including me) believe both may prove to be useful.* > > *But actual discussion of a BGP solution belongs in IDR (as Acee recently > emphasized).* > > *Please try to keep this thread focused on the question of whether an IGP > solution should/should not be pursued.* > > > > #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 ? > > > > *[LES:] This seems to be a variant of point #2 – and my response is the > same.* > > > > * Les* > > > > > > 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
