Paths Limit for Multiple Paths in BGP

[Donatas Abraitis]

>With that, there should be *some* definition of how to choose the paths to
send, to avoid getting straightforward implementations sending “just some”
N routes they find.

Correct, technically (and correctly too) the best path algorithm should be
looped as much as numbers of paths is negotiated (same is in FRRouting).

>Otherwise, this is going to be a performance nightmare.

For sure this is slower, but the same stuff is already done by Cisco,
FRRouting and/or Juniper where they have a knob to send an arbitrary number
of paths (without this capability, decided by the sender (not by the
receiver)). That's a trade-off between memory, CPU :)

Thanks!

On Wed, Oct 2, 2024 at 3:42 PM Maria Matejka <maria.matejka at nic.cz> wrote:

> Hello Donatas!
>
> On Wed, Oct 02, 2024 at 02:29:40PM +0300, Donatas Abraitis wrote:
>
> I hope this is the right place to ask for feature requests.
>
> Yes, it is!
>
> Would you mind adding this [1]draft to your TODO (/ feature) list?
>
> After reading the draft, I understand that the actual algorithm on how to
> choose the set of paths to be sent, is outside the scope of the document. I
> consider this a major problem which may lead to hard-to-fix long-term
> traffic loops between differing implementations.
>
> With that, there should be *some* definition of how to choose the paths
> to send, to avoid getting straightforward implementations sending “just
> some” N routes they find. One option is like this:
>
>    - while N > 0:
>       - run the standard best route selection algorithm
>       - remove the selected route from the original set
>       - if the selected route passes export filters:
>          - put the selected route into the final set
>          - N -= 1
>
> This can result in announcing up to N routes when 1 route gets updated, so
> one has to expect some funny behavior with this feature. But it is stable,
> can be reasonably tested, and it won’t yield random funny network mess
> dependent on the order of announcement arrival.
>
> There are thoughts on actually implementing this in BIRD.
> Regarding the current development priorities, this is expected to be
> implemented (if it actually happens) in BIRD 3 only, and only after we
> implement some more structural changes in the route storage. Otherwise,
> this is going to be a performance nightmare.
>
> I’ve heard some [2]people are already missing (= would benefit) this draft.
>
> Maybe the first suggestion for them is to reach out to us with the
> underlying problem which they are trying to solve, as there may be
> different solutions than implementing a not-well-defined feature.
>
> Thank you for your message, have a nice day!
> Maria
>
> –
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>


-- 
Donatas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20241002/5245c852/attachment.htm>