<div dir="ltr"><div>>With that, there should be <em>some</em> definition of how to choose
the paths to send, to avoid getting straightforward implementations
sending “just some” N routes they find.</div><div><br></div><div>Correct, technically (and correctly too) the best path algorithm should be looped as much as numbers of paths is negotiated (same is in FRRouting).</div><div><br></div><div>>Otherwise,
this is going to be a performance nightmare.</div><div><br></div><div>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 :)</div><div><br></div><div>Thanks!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2024 at 3:42 PM Maria Matejka <<a href="mailto:maria.matejka@nic.cz">maria.matejka@nic.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-1477968534964014030"><u></u>


  
  
  
  

<div>
<p>Hello Donatas!</p>
<p>On Wed, Oct 02, 2024 at 02:29:40PM +0300, Donatas Abraitis wrote:</p>
<blockquote>
<p>I hope this is the right place to ask for feature requests.</p>
</blockquote>
<p>Yes, it is!</p>
<blockquote>
<p>Would you mind adding this [1]draft to your TODO (/ feature)
list?</p>
</blockquote>
<p>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.</p>
<p>With that, there should be <em>some</em> 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:</p>
<ul>
<li>while <code>N > 0</code>:
<ul>
<li>run the standard best route selection algorithm</li>
<li>remove the selected route from the original set</li>
<li>if the selected route passes export filters:
<ul>
<li>put the selected route into the final set</li>
<li><code>N -= 1</code></li>
</ul></li>
</ul></li>
</ul>
<p>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.</p>
<p>There are thoughts on actually implementing this in BIRD.<br>
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.</p>
<blockquote>
<p>I’ve heard some [2]people are already missing (= would benefit) this
draft.</p>
</blockquote>
<p>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.</p>
<p>Thank you for your message, have a nice day!<br>
Maria</p>
<p>–<br>
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
</div>

</div></blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Donatas<br></div>