Donatas Abraitis 4338e21aa2 Revert "bgpd: Handle Addpath capability using dynamic capabilities" ... This reverts commit 05cf9d03b3. TL;DR; Handling BGP AddPath capability is not trivial (possible) dynamically. When the sender is AddPath-capable and sends NLRIs encoded with AddPath ID, and at the same time the receiver sends AddPath capability "disable-addpath-rx" (flag update) via dynamic capabilities, both peers are out of sync about the AddPath state. The receiver thinks already he's not AddPath-capable anymore, hence it tries to parse NLRIs as non-AddPath, while they are actually encoded as AddPath. AddPath capability itself does not provide (in RFC) any mechanism on backward compatible way to handle NLRIs if they come mixed (AddPath + non-AddPath). This explains why we have failures in our CI periodically. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>		2025-01-25 20:51:16 +02:00
..
r1	tests: Check if ENHE capability can be handled dynamically	2025-01-14 22:46:51 +02:00
r2	Revert "bgpd: Handle Addpath capability using dynamic capabilities"	2025-01-25 20:51:16 +02:00
__init__.py	tests: Check if we can handle software version capability dynamicaly	2023-08-03 17:08:32 +03:00
test_bgp_dynamic_capability_enhe.py	tests: Fix test_bgp_dynamic_capability_enhe topotest	2025-01-18 23:07:37 +02:00
test_bgp_dynamic_capability_fqdn.py	tests: Refactoring FRR test suites	2024-07-15 13:09:32 +05:30
test_bgp_dynamic_capability_graceful_restart.py	tests: Refactoring FRR test suites	2024-07-15 13:09:32 +05:30
test_bgp_dynamic_capability_orf.py	tests: Refactoring FRR test suites	2024-07-15 13:09:32 +05:30
test_bgp_dynamic_capability_path_limit.py	Revert "bgpd: Handle Addpath capability using dynamic capabilities"	2025-01-25 20:51:16 +02:00
test_bgp_dynamic_capability_role.py	tests: Refactoring FRR test suites	2024-07-15 13:09:32 +05:30
test_bgp_dynamic_capability_software_version.py	tests: Refactoring FRR test suites	2024-07-15 13:09:32 +05:30