Hi, Jeffrey and Robert: Your previous explanation of the usage of "overload bit" is correct, as also explained in its definition of https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-30#section-4 Based on Jeff's comments, how about we make the definition more clearly, as the below change:
Previous Definition: "Overload VPN routes process method (1 bit): if the value is set to 0, it means all overload VPN routes on the sender of VPN Prefix ORF message SHOULD be withdrawn; if the value is set to 1, it means the sender of VPN Prefix ORF message refuse to receive new overload VPN routes. The default value is 0." New Definition: "Overload VPN routes process method (1 bit): if the value is set to 0, it means all overload VPN routes on the sender of VPN Prefix ORF message SHOULD be withdrawn and the receiver of such message SHOULD withdraw the overload VPN routes matching the ORF's type-specific part, defined below". if the value is set to 1, it means the sender of VPN Prefix ORF message refuse to receive new overload VPN routes and the receiver of such message should filter the newly arrived matched VPN routes. The default value is 0." Should we replace also the term "extra" to "newly arrived matched" in section 5.2? And, based on your discussions, should we change back the term "EntryID" to "Sequence"? It seems will be helpful in some situations. Aijun -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeffrey Haas Sent: Thursday, February 26, 2026 10:04 PM To: Robert Raszuk <[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) > 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] _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
