On Tue, May 09, 2023 at 09:49:18AM +0200, Rogier Krieger wrote:
> Thanks for the rapid response and proposal.
> I'd wanted to test yesterday but had to postpone.
>
> On Mon, May 8, 2023 at 12:18 PM Claudio Jeker <cje...@diehard.n-r-g.com>
> wrote:
> > Here is a possible solution where a perfect match aborts the detection
> > loop. Now this only works if the labels are in the right order ("in"
> > before "invalid").
>
> This is similar to what I had in mind, but shorter than what I'd thought of.
> I'll test on -current first and report back. After, I'll adapt for
> -release after (i.e. the equivalent of r1.124 for parser.c [1]).
>
>
> > I wonder if chaning "invalid" to "notvalid" or "noteligible" would be a
> > better fix for now...
>
> Personally, I like the flexibility of keyword freedom, given the small
> one-time price to pay of sorting.
> Sorting may make maintenance a little easier too; at least I've seen
> several recent commits elsewhere to that end.
Right now I favour to rename the keyword since it is simpler. The idea is
to use "disqualified" as keyword. This has some additional benefits since
invalid is rather overloaded (ovs, avs use invalid and then there is error
which is a different kind of invalid).
The routes 'bgpctl show rib invalid' displays are Loc-RIB entries which
can not be selected in the decision process because of various reasons.
--
:wq Claudio
