Hi, Thank you Wei. Version -29 addresses all of my concerns and comments discussed on the list.
Kind regards, Robert On Sat, Feb 14, 2026 at 2:50 AM Wei Wang <[email protected]> wrote: > Hi Robert, > > Thanks for your comments, they have been addressed in -v29. Please check: > https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-29 > > Best Regards, > Wei > > > Original > ------------------------------ > From: Robert Raszuk <[email protected]> > Date: 2026-02-13 19:07 > To: Aijun Wang <[email protected]> > Cc: Ketan Talaulikar <[email protected]>, Wei Wang < > [email protected]>, BESS <[email protected]>, idr <[email protected]>, Susan > Hares <[email protected]>, Keyur Patel <[email protected]> > Subject: [bess] Re: [Idr] Re: Re: Re: draft-ietf-idr-vpn-prefix-orf-25 - > 1 Week WGLC onchanges (1/29/2026 to 1/5/2026) > > Hi, > > Three comments: > > 1) > > I would also recommend to edit section 4 where you say: > > Match (1 bit): the value is PERMIT or DENY as described in [RFC5291]. > > You can just add one sentence - > > For the purpose of this document only DENY value is allowed so this bit > MUST be set to 1. > > 2) > > I like that you have also removed EVPN from Route Type IANA section. > > 3) > > I do not like - IMO this is wrong change between -27 and -28 that you have > removed this sentence from RD definition. Please add it back - it is very > useful and orthogonal to discussion about PERMIT. > > "If the RD is set to 0, it indicates all VPN prefixes." > > Many thx, > R. > > > > On Fri, Feb 13, 2026 at 9:06 AM Aijun Wang <[email protected]> > wrote: > > Hi, Robert: > > > > OK. > > > > We have removed the explicit “permit all” related description in the > updated version > https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-28 > > If there is no further comments, we will wait for the AD’s forward to the > IESG evaluation, > > > > Aijun > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Robert Raszuk > *Sent:* Thursday, February 12, 2026 7:38 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Ketan Talaulikar <[email protected]>; Wei Wang < > [email protected]>; BESS <[email protected]>; idr <[email protected]>; Susan > Hares <[email protected]>; Keyur Patel <[email protected]> > *Subject:* [bess] Re: [Idr] Re: Re: Re: draft-ietf-idr-vpn-prefix-orf-25 > - 1 Week WGLC onchanges (1/29/2026 to 1/5/2026) > > > > Hi Aijun, > > > > The idea of ORF was born based on BGP inbound policies as a local > optimisation where and when applicable. > > > > BGP policy is used to match and drop or modify matched entries. Unmatched > entries pass through normally. > > > > Even if you look at second paragraph of RFC5291 it clearly expresses such > intent as main use case for ORF encoding. > > > > This document defines a BGP-based mechanism that allows a BGP speaker > > to send to its BGP peer a set of Outbound Route Filters (ORFs). The > > peer would then apply *these filters*, in addition to its locally > > configured outbound filters (if any), to constrain/filter its > > outbound routing updates to the speaker > > > > So DENY what is matching the DENY filter and send everything else. Empty > Route Refresh has a meaning of null DENY - so send all - especially useful > when you exchange ORF capabilities for a given SAFI but are not sending any > DROP or PERMIT filters yet. > > > PERMIT on the other hand has the opposite meaning ... send only what I am > asking you to send. > > > > Best, > > R. > > > > > > > > > > On Thu, Feb 12, 2026 at 11:12 AM Aijun Wang <[email protected]> > wrote: > > Hi, Robert: > > > > Is there any document that describes the action “There is no need to > "tell" this to "ORF receiver" to send routes which are not mentioned in > DENY entries.”? > > > > If there is such description in current RFCs, we can refer to it. > > If there is no such description in current RFCs, should we explicit > declare it in this document? > > > > Aijun > > > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Robert Raszuk > *Sent:* Thursday, February 12, 2026 4:47 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Ketan Talaulikar <[email protected]>; Wei Wang < > [email protected]>; BESS <[email protected]>; idr <[email protected]>; Susan > Hares <[email protected]>; Keyur Patel <[email protected]> > *Subject:* [bess] Re: [Idr] Re: Re: Re: draft-ietf-idr-vpn-prefix-orf-25 > - 1 Week WGLC onchanges (1/29/2026 to 1/5/2026) > > > > Hi Aijun, > > > > > What we need is to tell the VPN Prefix ORF receiver, that, after > blocking all the > > > VPN routes that are identified by the corresponding “VPN Prefix ORF > entries”, > > > it should allow all other VPN routes pass. > > > > That is how ORF DENY works by design. There is no need to "tell" this to > "ORF receiver" to > > send routes which are not mentioned in DENY entries. > > > > > Then, we should standardize such implicit default “permit all” behavior > as the > > > last resort on the “VPN Prefix ORF” receiver. > > > > No need. ORF entries as Ketan already mentioned are no ACLs with default > deny all at the end :-) > > > > In any case what is currently in the draft is not allowing it anyway. > > > > Best, > > R. > > > > > > On Thu, Feb 12, 2026 at 2:05 AM Aijun Wang <[email protected]> > wrote: > > Hi, Robert: > > > > The “permit all” action from “empty refresh message” is different from the > “default permit all” within the ORF entries. > > > > What we need is to tell the VPN Prefix ORF receiver, that, after blocking > all the VPN routes that are identified by the corresponding “VPN Prefix ORF > entries”, it should allow all other VPN routes pass. > > Then, we should standardize such implicit default “permit all” behavior as > the last resort on the “VPN Prefix ORF” receiver. > > > > Aijun > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Robert Raszuk > *Sent:* Wednesday, February 11, 2026 7:08 PM > *To:* Ketan Talaulikar <[email protected]> > *Cc:* Aijun Wang <[email protected]>; Wei Wang < > [email protected]>; BESS <[email protected]>; idr <[email protected]>; Susan > Hares <[email protected]>; Keyur Patel <[email protected]> > *Subject:* [bess] Re: [Idr] Re: Re: Re: draft-ietf-idr-vpn-prefix-orf-25 > - 1 Week WGLC onchanges (1/29/2026 to 1/5/2026) > > > > 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]> > 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]> 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]> > wrote: > > 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. > > *[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]> 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]> 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]> > > Date: 2026-01-30 22:44 > > To: BESS <[email protected]> > > Cc: idr <[email protected]>, Robert Raszuk <[email protected]>, Susan Hares < > [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) > > > > 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]> 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] > To unsubscribe send an email to [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] > > > > > > _______________________________________________ > 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]
