It did not sound like it. See in orf after capabilities are exchanged simple empty refresh is permit all.
thx R. On Wed, Feb 11, 2026, 10:57 Ketan Talaulikar <[email protected]> wrote: > Robert, I think Aijun is saying the same thing as you. > > Aijun/co-authors, could you please share the diff with the changes so > Robert can confirm? > > I hope it helps us converge. > > Thanks, > Ketan > > > > On Wed, 11 Feb, 2026, 3:18 pm Robert Raszuk, <[email protected]> wrote: > >> Hi Aijun, >> >> For this draft you really do not need to use ORF PERMIT at all. Just >> remove it and we are done. There is not a single use case in the draft >> which would prove that ORF PERMIT is needed to be supported. >> >> Thx, >> R. >> >> On Wed, Feb 11, 2026 at 10:42 AM Aijun Wang <[email protected]> >> wrote: >> >>> Hi, Ketan: >>> >>> >>> >>> [make "permit all" as the default behavior unless prevented by an ORF >>> Entry with DENY.] is more simpler than letting the VPN Prefix ORF >>> originator send one “permit all” entry. >>> >>> >>> >>> If you all agree, we can add some descriptions on the behavior of the >>> VPN Prefix ORF receiver in next version, and also the sender’s behavior(not >>> sending such default entry then). >>> >>> >>> >>> Aijun >>> >>> >>> >>> *From:* [email protected] [mailto: >>> [email protected]] *On Behalf Of *Ketan Talaulikar >>> *Sent:* Wednesday, February 11, 2026 4:03 PM >>> *To:* Wei Wang <[email protected]> >>> *Cc:* Robert Raszuk <[email protected]>; BESS <[email protected]>; idr < >>> [email protected]>; Susan Hares <[email protected]>; Keyur Patel < >>> [email protected]> >>> *Subject:* [Idr] Re: [bess] Re: Re: draft-ietf-idr-vpn-prefix-orf-25 - >>> 1 Week WGLC onchanges (1/29/2026 to 1/5/2026) >>> >>> >>> >>> Hi Wei, >>> >>> >>> >>> Since the goal of this new ORF type is to filter out specific VPN routes >>> and this ORF mechanism is not really like an ACL (an arbitrary order of >>> permit and deny action rules), perhaps the simpler option would be remove >>> the use of PERMIT and make "permit all" as the default behavior unless >>> prevented by an ORF Entry with DENY. >>> >>> >>> >>> I believe this is the simpler option that Robert is suggesting. Is this >>> something that you could consider? >>> >>> >>> >>> Thanks, >>> >>> Ketan >>> >>> >>> >>> >>> >>> On Wed, Feb 11, 2026 at 1:25 PM Wei Wang <[email protected]> wrote: >>> >>> Hi Ketan and Robert, >>> >>> >>> >>> I think Ketan got the point. >>> >>> In order to make the doument more clearly, we would like to add the >>> following description in section 5.1: >>> >>> >>> >>> "The default entry is a special entry where the value of the "Overload >>> VPN routes process method" is not applicable." >>> >>> >>> >>> The operations ADD, REMOVE, and REMOVE-ALL can be applied to the default >>> entry. >>> >>> >>> >>> Best Regards, >>> >>> Wei >>> >>> >>> >>> Original >>> ------------------------------ >>> >>> From: Robert Raszuk <[email protected]> >>> >>> Date: 2026-02-10 21:37 >>> >>> 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: Re: [bess] Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 >>> Week WGLC onchanges (1/29/2026 to 1/5/2026) >>> >>> >>> >>> Hi Ketan, >>> >>> >>> >>> I decoded what draft defines in section 5.2 as procedure when handling >>> PERMIT ORF Message: >>> >>> >>> >>> 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. * >>> >>> >>> >>> The first contradiction in the definition is based on the use of PERMIT >>> with logical AND to Overload = 0 definition which is stated to mean ALL VPN >>> ROUTES matching the filter *MUST BE WITHDRAWN* .. and here filter is >>> RD=0 meaning MATCH ALL. >>> >>> >>> >>> I think authors think that they must address PERMIT even if it does not >>> deliver any value to the draft. I am simply saying not to allow PERMIT in >>> their ORF definition at all. Just use DENY what their draft is all about. >>> >>> >>> >>> In the ORF world PERMIT means to advertise only those routes which match >>> a filter ... so if they like to go by RD it MUST not be 0. But again IMO >>> attracting the routes is not what authors claim as the value of the draft. >>> >>> >>> >>> Kind regards, >>> >>> Robert >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Feb 10, 2026 at 2:28 PM Ketan Talaulikar <*[email protected] >>> <[email protected]>*> wrote: >>> >>> 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] >>> <[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] >>> <[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 >>> <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] <[email protected]>*> >>> >>> Date: 2026-02-06 17:55 >>> >>> To: Ketan Talaulikar <*[email protected] <[email protected]>*> >>> >>> Cc: Wei Wang <*[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: [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]
