[Idr] Re: [bess] Re: Re: Re: Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WGLC onchanges (1/29/2026 to 1/5/2026)

[Robert Raszuk <[e-mail]>]

Jeff,

> The default policy of an ORF is deny.

Not really ... Was not sure where discussing this draft hence had to check.
If you read section 6 it says:

   for a given

   AFI/SAFI the intersection between these two sets is non-empty, the
   speaker SHOULD NOT advertise to the peer any routes with that
   AFI/SAFI *prior to receiving from the peer any ROUTE-REFRESH message
   carrying that AFI/SAFI, where the message could be either without any
   ORF entries, *


That clearly means that empty ROUTE-REFRESH relaxes peer to send all it has
in spite of negotiating ORF

Now the question comes if I advertise you one DENY entry does it mean you
need to stop sending me the entire table if I do not include PERMIT all ..
well I do not think so.

Thx,
R.



On Mon, Feb 23, 2026 at 11:10 PM Jeffrey Haas <[e-mail]> wrote:

> I apologize for my prior inattention to this thread, however:
>
> RFC 5291, Section 6:
>
>    If a particular route maintained by a BGP speaker does not match any
>    of the ORF entries of any of the (non-empty) ORFs associated with a
>    particular peer, then this route SHOULD NOT be advertised to the
>    peer.
>
>
> The default policy of an ORF is deny.
>
> This is why the entry of last resort was added into the text in a prior
> round.
>
> -- Jeff
>
>
>
>
> On Feb 12, 2026, at 06:37, Robert Raszuk <[e-mail]> wrote:
>
> 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 <[e-mail]>
> 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:* [e-mail] [mailto:[e-mail]]
>> *On Behalf Of *Robert Raszuk
>> *Sent:* Thursday, February 12, 2026 4:47 PM
>> *To:* Aijun Wang <[e-mail]>
>> *Cc:* Ketan Talaulikar <[e-mail]>; Wei Wang <
>> [e-mail]>; BESS <[e-mail]>; idr <[e-mail]>; Susan
>> Hares <[e-mail]>; Keyur Patel <[e-mail]>
>> *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 <[e-mail]>
>> 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:* [e-mail] [mailto:[e-mail]]
>> *On Behalf Of *Robert Raszuk
>> *Sent:* Wednesday, February 11, 2026 7:08 PM
>> *To:* Ketan Talaulikar <[e-mail]>
>> *Cc:* Aijun Wang <[e-mail]>; Wei Wang <
>> [e-mail]>; BESS <[e-mail]>; idr <[e-mail]>; Susan
>> Hares <[e-mail]>; Keyur Patel <[e-mail]>
>> *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 <[e-mail]>
>> 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, <[e-mail]> 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 <[e-mail]>
>> 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:* [e-mail] [mailto:[e-mail]]
>> *On Behalf Of *Ketan Talaulikar
>> *Sent:* Wednesday, February 11, 2026 4:03 PM
>> *To:* Wei Wang <[e-mail]>
>> *Cc:* Robert Raszuk <[e-mail]>; BESS <[e-mail]>; idr <
>> [e-mail]>; Susan Hares <[e-mail]>; Keyur Patel <
>> [e-mail]>
>> *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 <[e-mail]> 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 <[e-mail]>
>>
>> Date: 2026-02-10 21:37
>>
>> To: Ketan Talaulikar <[e-mail]>
>>
>> Cc: Wei Wang <[e-mail]>, BESS <[e-mail]>, idr <
>> [e-mail]>, Susan Hares <[e-mail]>, Keyur Patel <
>> [e-mail]>
>>
>> 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 <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail] <[e-mail]>*>
>>
>> Date: 2026-02-06 17:55
>>
>> To: Ketan Talaulikar <*[e-mail] <[e-mail]>*>
>>
>> Cc: Wei Wang <*[e-mail] <[e-mail]>*>, BESS <*[e-mail]
>> <[e-mail]>*>, idr <*[e-mail] <[e-mail]>*>, Susan Hares <*[e-mail]
>> <[e-mail]>*>, Keyur Patel <*[e-mail] <[e-mail]>*>
>>
>> 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 <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail] <[e-mail]>*>
>>
>> Date: 2026-02-03 17:47
>>
>> To: Wei Wang <*[e-mail] <[e-mail]>*>
>>
>> Cc: Ketan Talaulikar <*[e-mail] <[e-mail]>*>,
>> BESS <*[e-mail] <[e-mail]>*>, idr <*[e-mail]
>> <[e-mail]>*>, Susan Hares <*[e-mail] <[e-mail]>*>, Keyur
>> Patel <*[e-mail] <[e-mail]>*>
>>
>> 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 <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail] <[e-mail]>*>
>>
>> Date: 2026-01-30 22:44
>>
>> To: BESS <*[e-mail] <[e-mail]>*>
>>
>> Cc: idr <*[e-mail] <[e-mail]>*>, Robert Raszuk <*[e-mail]
>> <[e-mail]>*>, Susan Hares <*[e-mail] <[e-mail]>*>,
>> Keyur Patel <*[e-mail] <[e-mail]>*>
>>
>> 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 <*[e-mail]
>> <[e-mail]>*> wrote:
>>
>> Hi Aijun,
>>
>>
>>
>> On Fri, Jan 30, 2026 at 2:37 PM Aijun Wang <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail]
>> <[e-mail]>*> 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 <*[e-mail] <[e-mail]>*>
>>
>> Date: 2026-01-30 02:06
>>
>> To: Susan Hares <*[e-mail] <[e-mail]>*>
>>
>> Cc: idr <*[e-mail] <[e-mail]>*>, Keyur Patel <*[e-mail]
>> <[e-mail]>*>
>>
>> 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 <*[e-mail]
>> <[e-mail]>*> 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 -- *[e-mail] <[e-mail]>*
>> To unsubscribe send an email to *[e-mail] <[e-mail]>*
>>
>>
>>
>> _______________________________________________
>> Idr mailing list -- *[e-mail] <[e-mail]>*
>> To unsubscribe send an email to *[e-mail] <[e-mail]>*
>>
>> _______________________________________________
>> Idr mailing list -- *[e-mail] <[e-mail]>*
>> To unsubscribe send an email to *[e-mail] <[e-mail]>*
>>
>>
>>
>>
>>
>> _______________________________________________
>> Idr mailing list -- *[e-mail] <[e-mail]>*
>> To unsubscribe send an email to *[e-mail] <[e-mail]>*
>>
>>
>>
>>
>>
>> _______________________________________________
> Idr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>