Hi, One more note in respect to your below comment:
*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.* So in order to support overload bit with request to filter *ONLY NEW MATCHING BEST PATHS* your implementation after receiving ORF tracks was that best path already in my ADJ-RIB-OUT before I received ORF entry and if so I will continue to advertise it to the peer. How do you deal with BGP restart or router reload ? Suddenly history is gone, tracking is gone and you suppress advertisements as now everything is NEW to you ? Well sender still expects you to keep advertising what he had before ... Do you think it is cool to advertise different sets of routes (assuming input is identical) to a peer before and after BGP restart or box reload ? In order to support the ORF semantics with apply filter to ONLY NEW BEST PATHS BGP would need to support origination timestamp, so should ORF have one as well. I think we are making a dangerous precedent here with this "overload bit" extension in BGP. Kind regards, Robert On Fri, Feb 27, 2026 at 6:39 PM Robert Raszuk <[email protected]> wrote: > Hi Jeff, > > >> > 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 >> > > Not this side ... I am talking about BGP speaker which is a route receiver > side (ORF msg sender side). > > The semantics of clear soft in is pretty well defined and if my policy now > prohibits to receive some routes as defined in the filter I pushed to the > peer the expectations is that I will refresh my Adj Rib-In according to new > filters in place irrespective on what the peer will be blasting me with. > > If you are talking about the case that in spite of installing some filters > I now need to keep history on a per path basis and leak some paths which > were received and installed prior to applying the inbound filter to me this > means just pure mess. > > Cheers, > Robert. >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
