Scaling BFD support

Toke Høiland-Jørgensen toke at toke.dk
Fri Apr 1 15:58:08 CEST 2022


Douglas Fischer <fischerdouglas at gmail.com> writes:

> 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?
>
> And going a little further... In a quick Brainstorming...
> What would be the techniques that could help a Route-Server or
> Route-Reflector with a thousand BGP Peers to also support a thousand BFD
> sessions effectively and efficiently?
> Perhaps resort to some hardware-based off-loading method? Would eBPF help
> this in any way?

On this last point: it would probably be fairly straight-forward to
implement the echo reflector bit of BFP in eBPF, say in XDP: you'd just
populate a map with the session data, parse the packet as it comes in
and check against that, sending out a reply directly. I imagine that
would scale fairly well.

Can't really do the other direction, though (we don't have a way to
synthesise packet transmission from inside eBPF yet), and obviously some
state propagation would be needed. But I imagine it would be possible to
at least speed things up somewhat using eBPF :)

-Toke


More information about the Bird-users mailing list