Dear Authors of draft-ietf-idr-vpn-prefix-orf, As a WG member if you still want to proceed with this document I would recommend to go back and significantly modify proposed encoding.
Such modification should treat all TLVs as equal class citizens including (if you insist) RD - but making it optional. Moreover to address typed NLRIs, addition of new TLV carrying the Route-Type should be added. With this and other recommended changes the document could go back to WG review. Kind regards, Robert On Fri, Jan 30, 2026 at 3:45 PM Ketan Talaulikar <[email protected]> wrote: > 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]
