bgpd: Implement Link-Local Next Hop capability #17871
Conversation
Signed-off-by: Donatas Abraitis <[email protected]>
Signed-off-by: Donatas Abraitis <[email protected]>
Signed-off-by: Donatas Abraitis <[email protected]>
…er-peer Signed-off-by: Donatas Abraitis <[email protected]>
ton31337
force-pushed
the
feature/bgp_link_local_capability
branch
from
0d5556e to
d69fa2f
Compare
|
I've read the proposed draft and I'm not sure I am happy with the error handling aspect of it and how it works with older versions ( it's not specific enough imo ) |
ton31337
force-pushed
the
feature/bgp_link_local_capability
branch
from
d69fa2f to
ffc0a8e
Compare
Related: https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability TL;DR; use 16 bytes long next-hops for point-to-point (unnumbered) links instead of sending 32 bytes (::/LL, GUA/LL, LL/LL combinations). For backward compatiblity we should handle even 32 bytes existing next hops. Signed-off-by: Donatas Abraitis <[email protected]>
ton31337
force-pushed
the
feature/bgp_link_local_capability
branch
from
ffc0a8e to
db853cc
Compare
|
interface based peering is already supposed to do this. Why not just use that for this feature? As I understand it if we peer with a older version of FRR then it would still work. In other words why do we need a new knob when we have one already? |
you mean "neighbor X interface ..."? |
|
yes exactly. |
|
That would be probably fine. But I'm thinking what if I want to drop this capability (for some backward compatible SNAFU), but keep the session UP? |
Implementing https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability.
=> frrbot skipped intentional according to our conventions.