Hello Authors, I see that you have just posted v26 - 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. Most importantly, I was not aware of IPv4/IPv6 AFI being used with either VPLS or EVPN SAFIs. Can you please provide a reference? 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? Thanks, Ketan On Wed, Feb 4, 2026 at 12:54 PM Wei Wang <[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]> > Date: 2026-02-03 17:47 > To: Wei Wang <[email protected]> > Cc: Ketan Talaulikar <[email protected]>, BESS <[email protected]>, idr < > [email protected]>, Susan Hares <[email protected]>, Keyur Patel < > [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]>* > > > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
