Hi, Robert:
When the BGP restart or router reload, should any ORF table be cleared, and then the overall VPN Prefix Route control process happens from the beginning? If we rely on the soft restart feature to refresh the BGP route, all the BGP routes from the neighbor will be advertised again(although the matched offensive/overload” VPN routes will be filtered); If we utilize the overload bit(equal to 0), the receiver of BGP VPN Prefix ORF need only withdraw the “matched offensive/overload” VPN routes. We think the latter is more reasonable. Aijun From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Saturday, February 28, 2026 2:09 AM To: Jeffrey Haas <[email protected]> Cc: Aijun Wang <[email protected]>; BESS <[email protected]>; idr <[email protected]>; Sue Hares <[email protected]>; Keyur Patel <[email protected]> Subject: [bess] Re: [Idr] Re: Re: Re: Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WGLC onchanges (1/29/2026 to 1/5/2026) 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] <mailto:[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]
