Hi Vincent, from what I can assess, you can start with BIRD 2 as the affected parts of the code should be almost untouched. The one major exception I see there, is the validation code. If you find out you'd like to do some refactoring there, please consult v3 before. After you are done with v2, please also try preparing a merge branch for thread-next. It should not be much work. I'll give you pointers for the things to resolve for v3 after I see your code for v2. Hoping that this is OK for you. Have a nice weekend! Maria On 26 October 2024 09:15:58 CEST, Vincent Bernat <bernat@luffy.cx> wrote:
On 2024-10-26 02:14, Ondrej Zajicek wrote:
I would be interested in implementing BGP Flowspec for VPNv4/VPNv6. Hacking flow4/flow6 to be VPNv4/VPNv6 instead of IPv4/IPv6 instead is easy, but I am unsure of the right way to *add* VPNv4/VPNv6. Should I add flowvpn4/flowvpn6 tables or reuse flow4/flow6 and only add "vpn4/vpn6 flow" channels to the BGP protocol?
Hi
I think you would need to add flowvpn4/flowvpn6 tables and also new net_addr subtypes to lib/net.h, as it is a new route type with a slightly different semantic (specifically RD is a part of the table key). That is mostly a copy-and-paste job from the regular flowspec nettypes.
Well, alternatively one could add RD to regular net_addr_flowX, keep it zero for regular flowspec with the argument that flowspec NLRI are huge anyways, so unused u64 for RD does not matter. But for the uniformity i would prefer the first approach.
Different net type leads naturally to different rtables.
Thanks. Should I wait for BIRD 3 or it is OK to start on BIRD 2?
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.