Hannes -
Thanx for bringing a new voice into the discussion. Please see inline. > -----Original Message----- > From: Hannes Gredler <[email protected]> > Sent: Monday, November 29, 2021 1:27 AM > To: Aijun Wang <[email protected]> > Cc: 'Robert Raszuk' <[email protected]>; 'lsr' <[email protected]>; Les Ginsberg > (ginsberg) <[email protected]>; 'Tony Li' <[email protected]>; 'Shraddha > Hegde' <[email protected]>; Peter Psenak (ppsenak) > <[email protected]> > Subject: Re: [Lsr] BGP vs PUA/PULSE > > On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote: > > [ ... ] > > | Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the > different > | is how to propagate such “DOWN” information. Considering we have > observed > | that all P/PE router in other areas may be interested such information, > | your proposal will require every P/PE router run BGP-LS, which is not the > | aimed deploy scenarios for BGP-LS. > > HG> BGP-LS has been conceived to solve the very problem of providing > visibility of other > area's link state. I fail to see what is out of scope here. > [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".) > | Then, if IGP has such capabilities, why bother BGP? What is the benefit? > > HG> simply put: seperation of concerns. Agreed consensus is to mostly use > the > IGP for topology discovery and put the bulk of carrying reachability > information > into BGP which gives us: > [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. > 1) flow-control capabilities (=by virtue of TCP) and > 2) furthermore operators can scale and isolate the distribution vehicle for a > given AFI/SAFI service > using a dedicated RR infrastructure which does not mess with your bread > and butter service > infra. > > IMO it is not a good idea to put (negative) reachability information back into > the IGP as you > would loose this "seperation of concerns" aspect and potentially de-stabilize > your topology discovery > tool and hence *all* your bread-and-butter services. > [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 > HTH, > > /hannes
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
