Hi, Robert:
I have uploaded the new version which adopt the suggestions from Jeff. For your concerns, I think you may over worried the complex of “overload” bit. According to your suggestions, how about let the other reviewer, AD etc. to comment on this issue, and seek their opinions later? Let’s forward this document then? Aijun From: [email protected] <[email protected]> On Behalf Of Robert Raszuk Sent: Saturday, February 28, 2026 9:20 PM To: Aijun Wang <[email protected]> Cc: Jeffrey Haas <[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) Dear Aijun, 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? Nope. See when your ORF list is not empty (and it is not empty since filters have been pushed to the peer before peer's restart) the peer will not be sending you the routes which you would otherwise get with overload bit set to 1 prior to restart. Reason being that the definition of overload VPN = 1 means in your document not to send NEW routes (NEW meaning post matching ORF rule reception and installation). 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); As Jeff pointed out that refresh message MUST always be sent anyway following the ORF message. So in fact you do not need an extra operational action. However you do need a bit of magic on both sides to keep sending and accepting routes subject to ORF filtering with definition of "I STILL WANT ALL THE MATCHING ROUTES PRIOR TO INSTALLING ON INBOUND AS WELL AS PUSHING ORF FILTER" That to do correctly introduces timing components which we do not have in BGP attached to each path and each filter. Thinking more it is actually completely unclear when would you even use Overload bit = 1 ... as this requires you to predict the future. You do not know if you will ever get new routes. A special case of this when you send RD=0 and Overload set to 1 would mean - do not send me any new routes. Also imagine a case when you push such filter then your peer receives a withdraw ... Well it is matching the filter so will be naturally suppressed - it leads to lot's of ugly scenarios in the network. I do not see in RFC5291 a special case addressing this as the spec does not even allow filtering to be applied on only NEW matching routes post filter reception. 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. Not sure if I read the last two sentences correctly - but if you say that you are ok with using standard ORF behaviour = meaning to remove all matching routes = then we are all in sync. But that means that you really do not need to define the overload bit at all. Moreover if you do so you also do not need Sequence ID. To summarize I strongly request to remove the Overload bit and therefore ordering Sequence ID from your specification. That is my input here. How chairs, shepherd, AD and next reviewers will handle and deal with it remains to be seen. Cheers, Robert From: [email protected] <mailto:[email protected]> [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Robert Raszuk Sent: Saturday, February 28, 2026 2:09 AM To: Jeffrey Haas <[email protected] <mailto:[email protected]> > Cc: Aijun Wang <[email protected] <mailto:[email protected]> >; BESS <[email protected] <mailto:[email protected]> >; idr <[email protected] <mailto:[email protected]> >; Sue Hares <[email protected] <mailto:[email protected]> >; Keyur Patel <[email protected] <mailto:[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]
