<div dir="ltr">Hello Arnold<br>Thank you for the information!<br><br>Are there any public docs or references of that workshop?<br><br><br>Sincerely, what caught my attention was the "Auth: none" part.<br>On a room with more than thousand persons, confirm if the voice you rear is really from the person you think it is makes sense to me.<br><br><br>But the good part is that the interval is not crazily small as some wanted.<br>This reduces the number of pps the deamon has to deal with.<br><br>Using the biggest IXP in number os participants as a reference.<br>Assuming all participants active BFD, there are 2500 BFD session per server per protocol(v4+v6)<br>Assuming that the minimum interval(500ms) is always used(worst case scenario).<br>2750*2*=11.000pps<br>I don't know if that is feasible for an engine without any improvements of performance.<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 23 de jun. de 2022 às 08:52, Arnold Nipper <<a href="mailto:arnold@nipper.de">arnold@nipper.de</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Douglas<br>
<br>
there was a workshop on "BFD at IXes" at the recent Euro-IX Forum in <br>
Tampere.<br>
<br>
These are the parameters the participants agreed upon<br>
<br>
* Interval: 500ms - 1500ms<br>
* Multiplier: 3 or 5<br>
* Passive: on<br>
* Idle_tx: 3x Interval<br>
* Auth: none<br>
<br>
<br>
Greetings<br>
Arnold<br>
<br>
On 18.06.2022 13:47, Douglas Fischer wrote:<br>
> Hello all!<br>
> <br>
> Just passing here to see if any moves on this BFD Scaling occurred.<br>
> <br>
> This week some friends that are involved in the operation of a really <br>
> big IXP told me that they were having problems with some "funny" <br>
> participants of its IXP that adjusted their BGP Timer to numbers like 5/15.<br>
> On an environment with thousands of peers, I'm sure you can imagine the <br>
> CPU impact of that.<br>
> <br>
> Now you are probably asking:<br>
> What that has to do with Scale the BFD capacities on BIRD?<br>
> <br>
> Well...<br>
> Those 'j'enius are probably adjusting the timers to have some kind of <br>
> control of some communication issue occurs between his router and the RS.<br>
> They just "forget" that on that level of reduction, it compromises the <br>
> processing capacity of the RS.<br>
> <br>
> If BFD engine could support session for every participant at IXP, or at <br>
> least for those that wants that kind of resource.<br>
> Then would be reasonable to lock the timers of BGP Session in 60/180.<br>
> <br>
> <br>
> Em sex., 1 de abr. de 2022 às 13:41, Ondrej Zajicek <br>
> <<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a> <mailto:<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>>> escreveu:<br>
> <br>
> On Fri, Apr 01, 2022 at 08:44:50AM -0300, Douglas Fischer wrote:<br>
> > The question raised by colleague Irene reminded me of a topic<br>
> that may or<br>
> > may not be the focus of BIRD's development.<br>
> ><br>
> > I imagine that the biggest supporters of SMP/Multi-Core/Thread-Safe<br>
> > evolution on BIRD are Operators of Route-Servers of large IXPs, and<br>
> > operators of large-scale Route-Reflectors.<br>
> ><br>
> > Although BFD has its greatest use in the transport network and<br>
> Underlay, it<br>
> > is increasingly common to see the use of BFD in BGP Internet.<br>
> ><br>
> > I'm personally overly excited about what BIRD version 3 is<br>
> demonstrating in<br>
> > terms of vertical scalability.<br>
> ><br>
> > But I keep imagining that, even having scalability in the BGP<br>
> engine, it is<br>
> > almost prohibitive to use BFD in a scenario with a thousand BGP<br>
> Peers.<br>
> ><br>
> > Is there any view from the IBRD development team for this matter?<br>
> > Or even... Is there any open project focused on BFD that can<br>
> address this?<br>
> <br>
> Hmm, that is a good point. It would make sense to have multiple BFD<br>
> threads, but i think that it is more a question of improving I/O loop<br>
> performance in BIRD, as thousand peers with 100ms period is about 10<br>
> kpps<br>
> UDP rate, which should be manageable even from a single thread. We<br>
> should<br>
> make some effort to do some benchmarking for BFD.<br>
> <br>
> -- <br>
> Elen sila lumenn' omentielvo<br>
> <br>
> Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a><br>
> <mailto:<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>>)<br>
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,<br>
> <a href="http://wwwkeys.pgp.net" rel="noreferrer" target="_blank">wwwkeys.pgp.net</a> <<a href="http://wwwkeys.pgp.net" rel="noreferrer" target="_blank">http://wwwkeys.pgp.net</a>>)<br>
> "To err is human -- to blame it on a computer is even more so."<br>
> <br>
> <br>
> <br>
> -- <br>
> Douglas Fernando Fischer<br>
> Engº de Controle e Automação<br>
<br>
<br>
-- <br>
Keep calm, keep distance, keep connected!<br>
<br>
Arnold Nipper<br>
email: <a href="mailto:arnold@nipper.de" target="_blank">arnold@nipper.de</a><br>
mobile: +49 172 2650958<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>