Scaling BFD support

[Arnold Nipper]

Douglas

there was a workshop on "BFD at IXes" at the recent Euro-IX Forum in 
Tampere.

These are the parameters the participants agreed upon

  * Interval: 500ms - 1500ms
  * Multiplier: 3 or 5
  * Passive: on
  * Idle_tx: 3x Interval
  * Auth: none


Greetings
Arnold

On 18.06.2022 13:47, Douglas Fischer wrote:
> Hello all!
> 
> Just passing here to see if any moves on this BFD Scaling occurred.
> 
> This week some friends that are involved in the operation of a really 
> big IXP told me that they were having problems with some "funny" 
> participants of its IXP that adjusted their BGP Timer to numbers like 5/15.
> On an environment with thousands of peers, I'm sure you can imagine the 
> CPU impact of that.
> 
> Now you are probably asking:
> What that has to do with Scale the BFD capacities on BIRD?
> 
> Well...
> Those 'j'enius are probably adjusting the timers to have some kind of 
> control of some communication issue occurs between his router and the RS.
> They just "forget" that on that level of reduction, it compromises the 
> processing capacity of the RS.
> 
> If BFD engine could support session for every participant at IXP, or at 
> least for those that wants that kind of resource.
> Then would be reasonable to lock the timers of BGP Session in 60/180.
> 
> 
> Em sex., 1 de abr. de 2022 às 13:41, Ondrej Zajicek 
> <santiago at crfreenet.org <mailto:santiago at crfreenet.org>> escreveu:
> 
>     On Fri, Apr 01, 2022 at 08:44:50AM -0300, Douglas Fischer wrote:
>      > The question raised by colleague Irene reminded me of a topic
>     that may or
>      > may not be the focus of BIRD's development.
>      >
>      > I imagine that the biggest supporters of SMP/Multi-Core/Thread-Safe
>      > evolution on BIRD are Operators of Route-Servers of large IXPs, and
>      > operators of large-scale Route-Reflectors.
>      >
>      > Although BFD has its greatest use in the transport network and
>     Underlay, it
>      > is increasingly common to see the use of BFD in BGP Internet.
>      >
>      > I'm personally overly excited about what BIRD version 3 is
>     demonstrating in
>      > terms of vertical scalability.
>      >
>      > But I keep imagining that, even having scalability in the BGP
>     engine, it is
>      > almost prohibitive to use BFD in a scenario with a thousand BGP
>     Peers.
>      >
>      > Is there any view from the IBRD development team for this matter?
>      > Or even... Is there any open project focused on BFD that can
>     address this?
> 
>     Hmm, that is a good point. It would make sense to have multiple BFD
>     threads, but i think that it is more a question of improving I/O loop
>     performance in BIRD, as thousand peers with 100ms period is about 10
>     kpps
>     UDP rate, which should be manageable even from a single thread. We
>     should
>     make some effort to do some benchmarking for BFD.
> 
>     -- 
>     Elen sila lumenn' omentielvo
> 
>     Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org
>     <mailto:santiago at crfreenet.org>)
>     OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,
>     wwwkeys.pgp.net <http://wwwkeys.pgp.net>)
>     "To err is human -- to blame it on a computer is even more so."
> 
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação


-- 
Keep calm, keep distance, keep connected!

Arnold Nipper
email: arnold at nipper.de
mobile: +49 172 2650958
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220623/f60e5b0c/attachment.sig>