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 Thanks, Ketan On Fri, Jan 30, 2026 at 7:20 PM Robert Raszuk <[email protected]> wrote: > Hi Aijun, > > On Fri, Jan 30, 2026 at 2:37 PM Aijun Wang <[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]> 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]> 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]> >>> Date: 2026-01-30 02:06 >>> To: Susan Hares <[email protected]> >>> Cc: idr <[email protected]>, Keyur Patel <[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] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ > Idr 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]
