Hi Les, thank you for the detailed clarifications. Please find my follow-up notes in-lined below under the GIM>> tag.
Regards, Greg On Mon, Jan 10, 2022 at 3:19 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > 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. > GIM>> If I understand the scenario correctly, N represents the number of PEs, not the number of routers in ASes. If that is the case, what could be a good estimate for N? > > > 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. > GIM>> That is very helpful information, thank you. Then, we can expect that a one-second interval for the transmission of a BFD Control packet would be acceptable and guarantee failure detection within three seconds. If that is the case, I'll note that many platforms support thousands of BFD sessions at 3.3 msec intervals. It appears to me that the case we're discussing produces/processes 330 times fewer BFD packets per session. Should somewhat help with the scaling, would you agree? > > > 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) <ginsberg= > [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]> *On Behalf Of *Tony Li > *Sent:* Monday, January 3, 2022 1:09 PM > *To:* Christian Hopps <[email protected]> > *Cc:* Peter Psenak (ppsenak) <[email protected]>; Les Ginsberg (ginsberg) > <[email protected]>; Robert Raszuk <[email protected]>; Shraddha Hegde < > [email protected]>; Aijun Wang <[email protected]>; Hannes > Gredler <[email protected]>; lsr <[email protected]> > *Subject:* Re: [Lsr] BGP vs PUA/PULSE > > > > > > > > On Jan 3, 2022, at 11:23 AM, Christian Hopps <[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] > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
