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<mailto: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
