Completely agree. But my concern with this is actually about the sender side. It took two of us a while to digest the real meaning of the "overload" bit. Do you really think that senders of such ORF entries will use it correctly together with the right sequence number(s) ?
It is also important to observe here that the ultimate result of sending overload bit = 0 with some match criteria can be accomplished today by sending overload bit to 1 with the same match criteria and triggering "clear bgp soft in" (request refresh). from the ORF sender side. That means that adding "overload bit" to the spec is redundant to the currently built in protocol mechanism. Kind regards, Robert On Thu, Feb 26, 2026 at 2:30 PM Jeffrey Haas <[email protected]> wrote: > > > On Feb 26, 2026, at 08:21, Robert Raszuk <[email protected]> wrote: > > And that is not so much my preference ... just trying to simplify things > which perhaps only accidentally could get complex. > > > An underlying headache of all policy, not just ORFs, is that ordering is > important. Even if there's a desire to optimize things that may have > apparent unnecessary ordering, when two sets of match criteria can overlap > with different actions, the order MUST be clear. > > For this particular ORF, if the overload bit were not part of the > proposal, the match criteria can be arbitrarily ordered internally by the > implementation for maximum efficiency without concern. However, that's not > the case. Given the currently 5 different match criteria that are defined > in the draft, it is trivial to construct examples of overlaps that would > result in the routes being impacted by the overload bit differently. > > Ordering addresses this trivially. Implementations are free to optimize > once the ordering is clear. > > -- Jeff > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
