Scaling BFD support

[Mikhail Grishin]

Arnold Nipper пишет 24.06.2022 12:32:
> On 23.06.2022 23:41, Douglas Fischer wrote:
>
>> Are there any public docs or references of that workshop?
>>
>
> Not yet, Douglas
>
>>
>> Sincerely, what caught my attention was the "Auth: none" part.
>> 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.
>>
>
> Well, on an IX LAN, you should know how is talking to you ;-) Requring 
> auth doesn't add any security IMO.
>
>>
>> But the good part is that the interval is not crazily small as some 
>> wanted.
>> This reduces the number of pps the deamon has to deal with.
>>
>> Using the biggest IXP in number os participants as a reference.
>> Assuming all participants active BFD, there are 2500 BFD session per 
>> server per protocol(v4+v6)
>> Assuming that the minimum interval(500ms) is always used(worst case 
>> scenario).
>> 2750*2*=11.000pps
>> I don't know if that is feasible for an engine without any 
>> improvements of performance.
>>
>
> The smaller IXes may go for 500ms. The bigger ones probably will not 
> do. And unlike BGP, BFD always goes with the higher interval timer.

Hi,

It also up for customers wishes. We provide selective BFD timers.
Some of IXP members local , some 1000+ kilometers away. Some "requires" 
sub-second failure detection (you need to think about your 
infrastructure to support this).

95+% agree with our default values.

Wbr, Mikhail.

>
>
> Arnold
>>
>> Em qui., 23 de jun. de 2022 às 08:52, Arnold Nipper <arnold at nipper.de 
>> <mailto:arnold at nipper.de>> escreveu:
>>
>>     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>
>>     <mailto: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>
>>      >     <mailto:santiago at crfreenet.org 
>> <mailto:santiago at crfreenet.org>>)
>>      >     OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,
>>      > wwwkeys.pgp.net <http://wwwkeys.pgp.net> <http://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 <mailto:arnold at nipper.de>
>>     mobile: +49 172 2650958
>>
>>
>>
>> -- 
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>
>