[RFC v3] OSPFv3 LSA Extensibility RFC 8362

[acooks-at-bda]

This adds support for RFC 8362 OSPFv3 LSA Extensibility.

The PR is for review and comment on Work In Progress. It is a continuation of the work in PR #16532

Compared to the previously posted work, this PR includes:

• making callback structs static const so that they are placed in .rodata section, in response to a previous review comment
• E-Network-LSA origination
• E-Inter-Area-Prefix and E-Inter-Area-Router LSA origination
• updated SPF calculation based on E-LSAs
• additional topotests
• bug fixes, of course

Known deficiencies include:

• Routes are not installed for OSPF6_PATH_TYPE_EXTERNAL2

New E-LSAs can be enabled by adding ospf6 extended-lsa-support elsa or ospf6 extended-lsa-support both to the router ospf6 config. The default is to only send the legacy LSAs.

I understand that the proposed changes are not easily reviewable or acceptable as is. This is the progress we've made, and we seek suggestions for improvement, and guidance for what might be upstreamable.

Thank you for your consideration.

[eqvinox]

@acooks-at-bda — we just discussed this on the weekly community call and unfortunately the consensus (primarily @aceelindem , @riw777 and myself) is that the cost of making everything be callbacks with void pointers is too high. "Cost" here is first and foremost about code maintainability concerns and safety against bugs.

(i.e. all patterns similar to https://github.com/FRRouting/frr/pull/17343/files#diff-160d7849a335ef56a04caa4e090e4a2cea7272f14fde626613c1c93dfe62d95dR290 )

The best path to continue here is to have a discussion and/or brainstorming about how to structure the code in a good way…

[acooks-at-bda]

@acooks-at-bda — we just discussed this on the weekly community call and unfortunately the consensus (primarily @aceelindem , @riw777 and myself) is that the cost of making everything be callbacks with void pointers is too high. "Cost" here is first and foremost about code maintainability concerns and safety against bugs.

(i.e. all patterns similar to https://github.com/FRRouting/frr/pull/17343/files#diff-160d7849a335ef56a04caa4e090e4a2cea7272f14fde626613c1c93dfe62d95dR290 )

The best path to continue here is to have a discussion and/or brainstorming about how to structure the code in a good way…

Thanks, I understand that this is the TSC position. It is consistent with the feedback provided on previous PRs.

In opening this PR, I had hoped to:

• demonstrate that the pattern is needed and hoped that it would be obvious when considering the magnitude of change required to implement this feature;
• get insightful suggestions for specific improvements;
• get support for any subset of this work that could be made ready for merge;
• share the work we've done so far and show that we're getting somewhere.

I can understand the maintainers' position, really. I would also reject this change if I was the maintainer, for these reasons: There doesn't appear to be any pressing need for it. It's a large, risky change. The changed code flow obscures the core algorithm. It's probably riddled with bugs. It's coming from new contributors with no previous engagement or announcement or experience in this area. It's not clear who these people are or they will stick around to support it. Etcetera.

We did this work, because we need it in order to implement other things like:

• multi topology routing
• two-part metrics for OSPFv3
• Traffic Engineering Extensions to OSPF Version 3

We are now continuing with these other things, which will take our attention away from making this change upstreamable.

Without any specific advice like "go and look at how it was done in XYZ" or "follow this pattern instead:...", we honestly don't know how to make this change any more acceptable. We don't see the alternative you see. For months we've been looking for a way to do this without using callbacks and dreading being told nothing more than "don't use callbacks". Again.

Frankly, the existing ospf6d code is not in great shape. The existing style of very long functions with deep nesting is not easy to read or change and is not a style that can be built on for E-LSAs. Function pointers are already used for a few other things in the ospf6d code - and they are not the problem.

The ospf6d implementation is years behind the OSPFv3 RFCs. It seems unloved, and unless you can find someone to care about it and trust them to breathe some life into it, perhaps the next stage of its lifecycle should be to rewrite it in Rust.