>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.mate...@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
