> On Feb 26, 2026, at 08:43, Robert Raszuk <[email protected]> wrote: > > 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) ?
The only thing we can do ensure the specification is clear and there's good operational guidance. Beyond that, implementations must deal with things that are insane as best they can. > > 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. Not quite. Recall that the ORF programming operation is finalized with the soft refresh - even if the implementation is permitted in the RFC to do a soft "diff" mode. It is also possible, if not probable, for an implementation of the "don't send any more" overload behavior to track "was this in my rib-out already"? As long as the resultant match of re-running the ORF is still value 1 to not send any more, you simply use the prior announcement state - if your implementation can track such things. If your implementation can't track such things (e.g., mine can), then your implementation probably cannot fully support value 1. -- Jeff _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
