WIP: BIER extension for OSPFv3 #16
Conversation
|
Rebase on 9806948 |
nrybowski
force-pushed
the
bier_ospfv3
branch
2 times, most recently
from
b147a94 to
bd3277e
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #16 +/- ##
==========================================
- Coverage 63.40% 63.07% -0.34%
==========================================
Files 178 179 +1
Lines 29704 30018 +314
==========================================
+ Hits 18833 18933 +100
- Misses 10871 11085 +214 ☔ View full report in Codecov by Sentry. |
|
I'm not sure to understand why the BGP test suite is failing (https://github.com/holo-routing/holo/actions/runs/10468201712/job/28988566615?pr=16), I can't reproduce locally .. |
|
The PR is still missing some integration tests and sanity check upon BIER TLV reception but it should be ready for a first review. |
There was a problem hiding this comment.
@nrybowski Amazing work! I'm really happy seeing progress on this front (SR ❤️ BIER).
I've left a few review comments below, all of which should be easy to address.
The TLV format is the same as for OSPFv2 hence implementing RFC8444 on the basis laid down by this PR should be straightforward.
That's great. I can see the OSPFv3-specific changes are pretty small, and most of the OSPF BIER code being added is version-agnostic (including the TLV code). Hoping we can get BIER support for OSPFv2 in the future too :)
I'm not sure to understand why the BGP test suite is failing (https://github.com/holo-routing/holo/actions/runs/10468201712/job/28988566615?pr=16), I can't reproduce locally ..
This was fixed on the master branch. Please rebase to solve the problem.
The PR is still missing some integration tests and sanity check upon BIER TLV reception but it should be ready for a first review.
I think this PR is already a huge step forward. I wouldn't mind seeing those tests and sanity checks implemented in a separate PR later on.
| description | ||
| "Enables bier protocol extensions."; | ||
| } | ||
| leaf advertise { |
There was a problem hiding this comment.
Question: is there a case where one might want to enable the "advertise" leaf but not the "receive" leaf, or vice-versa?
There was a problem hiding this comment.
Draft-09 does not really detail the goal of such switches.
I guess that they control the behavior of the BFR, e.g. a BFR that only advertises its prefixes could be an egress-only (i.e., a leaf in multicast trees). But this seems error prone as other BFRs must be aware that this specific BFR is not able to forward multicast traffic. A BFR configured with "receive" could be an ingress-only or a "passive" probe that collects the BIRTs for monitoring purpose.
Furthermore, draft-08 added those values in an additional sub-domain container, which is not reflected in the current implementation ..
The "sub-domain" container controls the routing-protocol instance's
advertisement of the relevant BIER information of the BIER subdomain
and the processing of received the relevant BIER information of the
BIER subdomain.
- Add YANG augmentations from draft-ietf-bier-bier-yang-07 OSPF-side - Partial implementation of draft-ietf-bier-ospfv3-extensions-07 Signed-off-by: Nicolas Rybowski <[email protected]>
Signed-off-by: Nicolas Rybowski <[email protected]>
Signed-off-by: Nicolas Rybowski <[email protected]>
Signed-off-by: Nicolas Rybowski <[email protected]>
Signed-off-by: Nicolas Rybowski <[email protected]>
Signed-off-by: Nicolas Rybowski <[email protected]>
- Handle BIER enable / disable by re-installing routes in the BIRT / purging the BIRT, and re-originating self-LSA to advertise the update - Handle BIER sub-domain configuration events by re-originating self-LSA - Handle BIER encapsulation configuration events by re-originating self-LSA Signed-off-by: Nicolas Rybowski <[email protected]>
nrybowski
force-pushed
the
bier_ospfv3
branch
from
9f775ce to
3764c57
Compare
|
Rebase on c370052 to fix CI failure on BGP tests. |
Signed-off-by: Nicolas Rybowski <[email protected]>
nrybowski
force-pushed
the
bier_ospfv3
branch
from
36b4e80 to
39cf602
Compare
Signed-off-by: Nicolas Rybowski <[email protected]>
Signed-off-by: Nicolas Rybowski <[email protected]>
See holo-routing#16 (comment) for details Signed-off-by: Nicolas Rybowski <[email protected]> Suggested-by: Renato Westphal <[email protected]>
This PR adds BIER extensions for OSPFv3 as defined by draft-ietf-bier-ospfv3-extensions-07. The TLV format is the same as for OSPFv2 hence implementing RFC8444 on the basis laid down by this PR should be straightforward.
It relies on #10 for the addition of the BIER YANG model.
TODO