Aijun, My review points covering sequence number and clarity of the overload flag are addressed in -31.
I have started a separate thread covering the desired default permit behavior to avoid further confusion in this last call thread. -- Jeff > On Mar 2, 2026, at 09:13, Aijun Wang <[email protected]> wrote: > > 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] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> On > Behalf Of Robert Raszuk > Sent: Saturday, February 28, 2026 9:20 PM > To: Aijun Wang <[email protected] <mailto:[email protected]>> > Cc: Jeffrey Haas <[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) > > 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]
