Paths Limit for Multiple Paths in BGP

[Maria Matejka]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20241002/8866e708/attachment.htm>