diff options
| author | Donatas Abraitis <donatas@opensourcerouting.org> | 2025-01-25 20:28:26 +0200 |
|---|---|---|
| committer | Donatas Abraitis <donatas@opensourcerouting.org> | 2025-01-28 11:06:31 +0200 |
| commit | 71c81ec6889016eb293c61afad8d892b8baddd15 (patch) | |
| tree | 8ab9d217df1e98b79783385a7d1f8aafcda7f022 /pbrd/pbr_debug.h | |
| parent | 815b09b8e131ab4da1705ef09bc71f419022bab1 (diff) | |
Revert "bgpd: Handle Addpath capability using dynamic capabilities"
This reverts commit 05cf9d03b345393b8d63ffe9345c42debd8362b6.
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>
Diffstat (limited to 'pbrd/pbr_debug.h')
0 files changed, 0 insertions, 0 deletions
