Hi Wei, Thanks for the updated version - it addresses the comments that I had raised.
Coming to Robert's concern with the use of PERMIT, I would like to share my understanding to cross-check if I have made a mistake in my reading. The only ORF entry with PERMIT allowed is the "last" catch-all entry that says to permit everything that has not been denied by previous (DENY) rules. If such an entry is always required, then I found the use of the SHOULD to give a conflicting meaning. Besides the above, any other ORF entry with PERMIT MUST be discarded. So, everything else is about denying/filtering out matching routes and the operations are ADD, REMOVE or REMOVE ALL for those rules. But the ADD/REMOVE/REMOVE-ALL should also apply to the "default" PERMIT rule as well? Robert, I am not sure if I've understood your point correctly, and please correct me if I'm wrong. Thanks, Ketan On Tue, Feb 10, 2026 at 2:44 PM Robert Raszuk <[email protected]> wrote: > Hi Wei, > > You missed the most important comment. As currently defined, use of ORF > PERMIT is self contradicting. Version -27 still has the bad text in section > 5.2. > > My recommendation is to either remove use of ORF PERMIT from your proposal > (easy edit and you are not using it really for anything useful) or fix it > and use PERMIT correctly which will require a lot of work and text to be > added to the draft. > > Kind regards, > Robert > > > > On Tue, Feb 10, 2026 at 9:05 AM Wei Wang <[email protected]> wrote: > >> Hi Ketan and Robert, >> >> Thanks for your comments and suggestions! We have uploaded the -v27 to >> address your comments. ( >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-27) >> And please also see the in-line replies. >> >> Best Regards, >> Wei >> Original >> ------------------------------ >> From: Robert Raszuk <[email protected]> >> Date: 2026-02-06 17:55 >> To: Ketan Talaulikar <[email protected]> >> Cc: Wei Wang <[email protected]>, BESS <[email protected]>, idr < >> [email protected]>, Susan Hares <[email protected]>, Keyur Patel < >> [email protected]> >> Subject: [bess] Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week >> WG LC onchanges (1/29/2026 to 1/5/2026) >> >> Hi, >> >> Thank you for posting version -26 of this document. >> >> I see that you still did not want to make sending RD optional. Oh well I >> do believe making it as optional TLV would make this extension more >> practical and much more useful. And the most interesting point is >> that functionality wise you still support the case of RD = 0 (meaning >> irrespective of RD value) apply the filter. >> >> So instead of sending 8 octets of 0 you could just not send it at all. >> *[WW]: We still hope to keep the "RD" in the "VPN Prefix ORF >> type-specific encoding", becasue the key point of VPN Prefix ORF mechanism >> is to identify the source of overwhelmed VPN routes:* >> *1) In scenario that is unique RD per PE, RD soely can identify the >> source of overwhelmed VPN routes correctly* >> *2) In scenario that is unique RD per VPN, RD + Source PE can identify >> such source.* >> >> *Anyway, carrying RD can control the advertisements of VPN routes in more >> granular manner.* >> >> >> Please see some more review comments ... >> >> 1) >> >> Why do both figures have identical descriptions yet showing different >> pictures ? >> >> Figure 1: VPN Prefix ORF type-specific encoding >> Figure 2: VPN Prefix ORF type-specific encoding >> >> I guess it should be instead: >> >> Figure 1: VPN Prefix ORF common part encoding >> Figure 2: VPN Prefix ORF type-specific encoding >> *[WW]: You're correct. This typo is modifiedI in -v27.* >> >> 2) >> >> In section 5.2 I am finding extremely hard to parse description regarding >> using match filters with PERMIT. >> >> Quote: >> >> If the "Match" bit is "PERMIT", and is the "default" entry (the >> overload VPN routes process method equal to 0, sequence equal to >> 0xFFFFFFFF, length is equal to 8, and Route Distinguisher is equal to >> 0), the entry SHOULD be installed. Otherwise, if the "Match" bit is >> "PERMIT", the entry MUST be discarded and a warning MUST be sent to >> the operator. >> >> So that literally translates to: >> >> *If ORF Match filter is set to PERMIT * >> *AND * >> *If Overload = 0 which means ALL VPN ROUTES matching the filter MUST BE >> WITHDRAWN * >> *AND * >> *if Seq=0xFFFFFFFF (so this MUST be last ORF entry)* >> *AND * >> *if length=8 (so there must not be any optional TLVs) * >> *AND * >> *if RD=0 (meaning apply to all VPN prefixes for a given AFI/SAFI)* >> *then * >> *INSTALL the entry. * >> >> This is so confusing ... and semantically incorrect. >> >> First PERMIT must not mean WITHDRAW - this is contradicting the intention >> to use PERMIT filters ... Please see reasons for PERMIT vs DENY is >> described in RFC5291: >> >> The "Match" component is used to support matching granularity on a >> per ORF entry basis. It can be either PERMIT or DENY. The semantics >> of PERMIT is to ask the peer to pass updates for the set of routes >> that match the ORF entry. The semantics of DENY is to ask the peer >> not to pass updates for the set of routes that match the ORF entry. >> >> then >> >> Sending RD = 0 makes sense only with some optional TLVs which the above >> prohibits to send along with PERMIT. >> >> So bottom line you have not defined the use of PERMIT correctly. Perhaps >> you can just say black on white that you are not supporting PERMIT ORF >> filters at all in your specification. >> *[WW]: Thank you to point out it. I think we can remove "the overload VPN >> routes process method equal to 0".* >> >> Thx, >> Robert >> >> On Thu, Feb 5, 2026 at 7:06 AM Ketan Talaulikar <*[email protected] >> <[email protected]>*> wrote: >> >> Hello Authors, >> >> I see that you have just posted v26 - >> *https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-26 >> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-26>* >> >> There are some issues in the table below (similar in the text as well) >> and some suggestions: >> >> +-----------+-------------------------+ >> | AFI | SAFI | >> +-----------+-------------------------+ >> |IPv4/IPv6 |MCAST-VPN | >> | |MCAST-VPLS | >> | |VPLS | >> | |BGP EVPNs | >> | |MPLS-labeled VPN address | >> +-----------+-------------------------+ >> |L2VPN |BGP EVPNs | >> +-----------+-------------------------+ >> >> >> Please give this table a number. Would be good to specifically list the >> AFI and SAFI values here for clarity and give a reference to their base >> RFCs. >> *[WW]: OK. These is added in -v27.* >> >> Most importantly, I was not aware of IPv4/IPv6 AFI being used with either >> VPLS or EVPN SAFIs. Can you please provide a reference? >> *[WW]: After double checking, the VPLS, EVPN and MCAST-VPLS SAFIs should >> be used with L2VPN. This is changed in -v27. * >> >> Also, I see that you have introduced a filter TLV for Route Types for >> EVPN. A similar problem exists for other types of VPNs having typed NLRIs >> as pointed out by Robert. Isn't a similar mechanism required for those >> address families? Therefore, shouldn't this mechanism be generic to VPNs >> with typed NLRIs? >> *[WW]: Yes, I think this TLV can be used for others routes that carry the >> Route type field. So we remove the description stating that this TLV is >> restricted to EVPN routes.* >> >> Thanks, >> Ketan >> >> >> On Wed, Feb 4, 2026 at 12:54 PM Wei Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Robert, >> >> I think a "EVPN Route Type TLV" can be added in Section 4 to control the >> filter of EVPN routes. >> >> Best Regards, >> Wei >> >> Original >> ------------------------------ >> From: Robert Raszuk <*[email protected] <[email protected]>*> >> Date: 2026-02-03 17:47 >> To: Wei Wang <*[email protected] <[email protected]>*> >> Cc: Ketan Talaulikar <*[email protected] <[email protected]>*>, >> BESS <*[email protected] <[email protected]>*>, idr <*[email protected] >> <[email protected]>*>, Susan Hares <*[email protected] <[email protected]>*>, Keyur >> Patel <*[email protected] <[email protected]>*> >> Subject: Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC >> onchanges (1/29/2026 to 1/5/2026) >> >> Hi Wei, >> >> Ad 2 - You can not if you have a single interface from the customer. >> >> Ad 3 - It would be an optional TLV of course. but providing required >> control. >> >> Ad 4 - I am not sure if private development counts as an implementation >> for the purposes of IDR document progression. But I will refer to chairs >> and AD to judge on that. >> >> Cheers, >> R. >> >> On Tue, Feb 3, 2026 at 3:21 AM Wei Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Ketan and Robert, >> >> 1. If all the types of EVPN routes are under one VRF and there is no >> threshold control mechanism for each of these types, we can only treat them >> all together, although some of them may be more importnace than >> others. >> >> 2. If we want to control these EVPN routes seperately, we can put them >> into different VRFs, via the configuration of RTs of each VRF, then the >> mechanism that is described in this document can apply and needs not be any >> changed. >> >> 3. We also think that add route types within the encoding is not >> practical, because other NLRI types don't have the "route type" field. >> >> 4. The implementations of this draft has been done via FRR, but we >> haven't committed it. >> >> >> Best Regards, >> Wei >> >> Original >> ------------------------------ >> From: Ketan Talaulikar <*[email protected] <[email protected]>*> >> Date: 2026-01-30 22:44 >> To: BESS <*[email protected] <[email protected]>*> >> Cc: idr <*[email protected] <[email protected]>*>, Robert Raszuk <*[email protected] >> <[email protected]>*>, Susan Hares <*[email protected] <[email protected]>*>, >> Keyur Patel <*[email protected] <[email protected]>*> >> Subject: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on >> changes (1/29/2026 to 1/5/2026) >> >> I concur with Robert. >> >> This mechanism introduces a mandatory RD filter. I won't get into the >> debate of the operational value and efficacy of this mechanism - that is >> for operators to report on. I don't see a technical issue with L3VPN. >> >> The same cannot be said about EVPN (and I have not yet considered the >> expanded applicability proposed by the authors to MVPN and VPLS). >> >> Let me elaborate on the issue with using this with EVPN. >> - The goal of this mechanism is to prevent overload of VPN routes from a >> specific PE+VPN-context >> - The primary and mandatory filter is the RD (there are others but they >> supplement RD) >> - Let's say there is an overload of MAC+IP routes and this mechanism >> kicks in. Would that affect the AD per ES route with the same RD? What >> would be its implication? >> >> The question is how this would affect/impact different types of EVPN >> route types given its primary RD filter? >> >> May I request someone from the BESS WG to review this specific aspect >> (broader review is also welcome!) : >> *https://www.ietf.org/archive/id/draft-ietf-idr-vpn-prefix-orf-25.html >> <https://www.ietf.org/archive/id/draft-ietf-idr-vpn-prefix-orf-25.html>* >> >> Thanks, >> Ketan >> >> >> On Fri, Jan 30, 2026 at 7:20 PM Robert Raszuk <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Aijun, >> >> On Fri, Jan 30, 2026 at 2:37 PM Aijun Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi, Robert: >> >> The document doesn’t filter the VPN prefixes solely based on RD, it bases >> mainly the RT and other additional TLVs. >> RD is only one additional parameter that can be used to assist the filter >> of the overflow VPN prefixes routes. >> >> >> The way the draft is written it is actually the other way around. Other >> optional parameters may augment RD based filtering. >> >> See this: >> >> Optional TLVs: Carries potential additional information to provide >> extensibility for the VPN Prefix ORF mechanism. Its format is >> shown in Figure 6. >> >> Btw there is no "Figure 6" :). >> >> And as we all know all other "optional parameters" can also be sent today >> with other mechanisms for filtering routes. >> >> Thx, >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Aijun Wang >> China Telecom >> >> On Jan 30, 2026, at 19:36, Robert Raszuk <*[email protected] >> <[email protected]>*> wrote: >> >> >> Dear Wei and WG, >> >> Ad 1 - Nope this does not address my comment as you still can not >> distinguish with current encoding of your draft to which NLRI types given >> RD applies. So as of today it is not applicable to any AFI/SAFIs with typed >> NLRIs (specifically to EVPNs). >> >> Ad 2 - ok. >> >> Ad 3 - I have a different opinion. >> >> But rereading your document there is one more fundamentally incorrect >> section: >> >> >> >> >> >> *3.2. Address Prefix ORF Using Address Prefix ORF to filter VPN routes >> requires a pre- configuration, but it is impossible to know in advance >> which prefix may exceed the predefined threshold.* >> >> Please note that RD is part of the prefix. The above comment in section >> 3.2 is wrong as it neglects the fact that prefix ORF contains a length >> field. So Address Prefix ORF as defined in RFC5292 when used *with the >> length of 64* is exactly RD based ORF. In fact it is even more flexible >> as subject doc if you use Minlen and Maxlen fields correctly :). >> >> So using plain vanilla RFC5292 which is already implemented and shipping >> completely removes the need to progress the subject document any further. I >> don't understand why we are last calling something which has already been >> standardized and in general form published as RFC in 2008. >> >> Kind regards, >> Robert >> >> On Fri, Jan 30, 2026 at 3:54 AM Wei Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Robert, >> >> Thanks for your comments. And please see my in-line replies. If these >> modifications can address your concerns, we will update this draft based on >> them. >> >> Best Regards, >> Wei >> >> Original >> ------------------------------ >> From: Robert Raszuk <*[email protected] <[email protected]>*> >> Date: 2026-01-30 02:06 >> To: Susan Hares <*[email protected] <[email protected]>*> >> Cc: idr <*[email protected] <[email protected]>*>, Keyur Patel <*[email protected] >> <[email protected]>*> >> Subject: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on >> changes (1/29/2026 to 1/5/2026) >> >> Dear WG, >> >> As recommended moving my three comments to this thread: >> >> 1) >> >> > KT> My point was that simply filtering on the RD can accidentally >> affect Route Types 1 >> > (as an example) and have severe implications on EVPN services. This is >> not an issue >> > with CP-ORF but specific to this new mechanism. Please consider at >> least warning >> > about this? >> >> IMO warning is not enough. >> >> I would rather either suggest extending the encoding to cover AFI/SAFIs >> with typed NLRIs or make the clear statement that this draft is not >> applicable to AFI/SAFIs with typed NLRIs at all. >> *[WW]: We can add a table about the **AFI and SAFI types applicable to >> this mechanism in Section 4 as follow:* >> >> *+-------+-------------------------------+* >> *| AFI | SAFI |* >> *+-------+-------------------------------+* >> *|IPv4/ |MCAST-VPN |* >> *|IPv6 |MCAST-VPLS |* >> *| |VPLS |* >> *| |BGP EVPNs |* >> *| |MPLS-labeled VPN address |* >> *+------+--------------------------------+* >> *|L2VPN |BGP EVPNs |* >> *+------+--------------------------------+* >> >> 2) >> >> Also I think there is typo in this sentence: >> >> However, each existing solution has its own limitation as described in >> Section 4. >> it should be >> However, each existing solution has its own limitation as described in >> Section 3. >> *[WW] Thank you! We will modify it in the updated version.* >> 3) >> >> I would also like to see in this specification a clear note or section >> stating that this document violates Proposed Standard RFC4364 as RFC4364 >> clearly defines in section 4.1 what RD is all about: >> >> >> >> >> >> >> * An RD is simply a number, and it does not contain any inherent >> information; it does not identify the origin of the route or the set of >> VPNs to which the route is to be distributed. The purpose of the RD is >> solely to allow one to create distinct routes to a common IPv4 address >> prefix. Other means are used to determine where to redistribute the >> route (see Section 4.3).* >> >> RD should never be used for import, export or any sort of filtering and >> it's sole role is to make prefixes unique. >> *[WW]: I think the usage of RD in this document doesn't conflict with the >> description in RFC4364. RD is just a distinguisher carried by VPN routers. >> It is a part of VPN Prefix. We just use this distinguisher to filter the >> VPN routes. It is simliar with that we do the prefixes filter via the >> shorter, common part of the related prefixes.* >> >> Kind regards, >> Robert >> >> >> On Thu, Jan 29, 2026 at 2:41 PM Susan Hares <*[email protected] >> <[email protected]>*> wrote: >> >> Greetings: >> >> >> >> draft-ietf-idr-vpn-prefix-orf-25 has made changes during the AD review. >> >> >> >> This begins a 1-week WG last call on the changes. >> >> If you have concerns regarding the changes, please respond to this >> message. >> >> >> >> If no concerns or objections are raised, this document will enter into >> IETF LC. >> >> >> >> Cheerily, IDR Chairs >> >> [Sue for Keyur Patel (shepherd) >> >> >> >> >> >> >> _______________________________________________ >> Idr mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] <[email protected]>* >> >> >> _______________________________________________ >> Idr mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] <[email protected]>* >> >> _______________________________________________ >> Idr mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] <[email protected]>* >> >> >> >> _______________________________________________ >> Idr mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] <[email protected]>* >> >> >>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
