Greg – The obvious issue is scale. Since you need a full mesh you are talking about N**2 behavior – so it doesn’t take many nodes to require thousands of BFD sessions.
In terms of detect time, we are trying to get an order of magnitude improvement from normal BGP session timers – so we are aiming for a modest number of seconds. Les From: Greg Mirsky <[email protected]> Sent: Monday, January 10, 2022 1:30 PM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Tony Li <[email protected]>; Christian Hopps <[email protected]>; Robert Raszuk <[email protected]>; Aijun Wang <[email protected]>; Shraddha Hegde <[email protected]>; Hannes Gredler <[email protected]>; lsr <[email protected]>; Peter Psenak (ppsenak) <[email protected]> Subject: Re: [Lsr] BGP vs PUA/PULSE Hi Les, thank you for bringing the real-life scenarios to the discussion. In your opinion, what prevents an operator from monitoring a remote PE using a multi-hop BFD? Do you have an estimated number of such sessions each PE must handle? What could be the required guaranteed failure detection time? Best regards, Greg On Mon, Jan 10, 2022 at 1:08 PM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Chris/Tony – We have received requests from real customers who both need to summarize AND would like better response time to loss of reachability to individual nodes. If they could operate at the necessary scale without summarizing they would have already – so telling customers to simply make sure they don’t use summaries isn’t helpful. There are then two ways to respond: 1)Sorry, when you use summaries you lose the ability to receive state information about individual prefixes covered by the summary. There is nothing we can do to help you. This seems to be what the two of you are saying. 2)We can provide a way to improve response time for the loss of reachability to individual destinations covered by a summary, but its use will be limited to isolated failures. Failures which affect a significant number of destinations at the same time will realize no benefit from the solution. If this limitation is acceptable then we have proposals that we think will be useful. That’s what we are trying to do. Les From: Tony Li <[email protected]<mailto:[email protected]>> On Behalf Of Tony Li Sent: Monday, January 3, 2022 1:09 PM To: Christian Hopps <[email protected]<mailto:[email protected]>> Cc: Peter Psenak (ppsenak) <[email protected]<mailto:[email protected]>>; Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; Robert Raszuk <[email protected]<mailto:[email protected]>>; Shraddha Hegde <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>>; Hannes Gredler <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] BGP vs PUA/PULSE On Jan 3, 2022, at 11:23 AM, Christian Hopps <[email protected]<mailto:[email protected]>> wrote: And I'm saying if a prefix is important enough to merit a bunch of new protocol extensions and state, then it's important enough to simply be left out of the summarization in the first place. And then people get what they want, w/o protocol changes/upgrades, and it's using time tested and hardened IGP code and designs. +1 T _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
