| Hi: Robert:
If we all can agree that the default action for this ORF type is “permit all”, and doing so doesn’t violate the specifications in RFC5291, it will be simpler than sending explicit “permit all” entry.
Or, we add explicitly in the document to emphasize such default behavior for this ORF type? Hi Aijun,
RFC5291 does not define any sequence numbers for ORF entries. So this is already a major departure from the ORF specification.
For this proposal you can just define that since you are sending only DENY entries the implicit is PERMIT for all other routes and still do not need to send anything.
Last but not least the definition of use of PERMIT has been broken in the spec so it would need to be fixed first, but again I don't think we need it. 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 confusing ... and semantically incorrect. Namely at least use of "Overload" needs to be redefined for the purpose of PERMIT ALL.
Many thx, R.
Hi, Robert: If we take into accounts the “Sequence” value in the encoding of the VPN Prefix ORF entry, then the “PERMIT ALL” is located at the end of the entry, as indicated in the previous version of this draft: https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-27: ……a default last-resort entry SHOULD be installed in advance in the VPN Prefixes ORF table, with the RD set to 0 and the corresponding Sequence set to 0xFFFFFFFF That is to say, to update the list of ORF entry, we need not remove all of them, and install again the new set. Should we update back to include this default entry? Doing so, we need not clarify the RFC 5291. Aijun From: Robert Raszuk [mailto:[email protected]]
Sent: Tuesday, February 24, 2026 6:44 AM
To: Jeffrey Haas <[email protected]>
Cc: Aijun Wang <[email protected]>; BESS <[email protected]>; idr <[email protected]>; Sue Hares <[email protected]>; Keyur Patel <[email protected]>
Subject: Re: [Idr] [bess] Re: Re: Re: Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WGLC onchanges (1/29/2026 to 1/5/2026) Yes, that was my first point. Then let's consider your second point ... Imagine a session where I want to push you my inbound DROP policy to DENY 1.1.1.1/24 (just talking general case not RDs but this is for illustration only). So according to your quoted text to get the rest of the entire BGP IPv4 table I would need to include PERMIT ALL. So my ORF would look like Now in T+ 5 I want to also send you DENY 2.2.2.2/24 ... Well if so I would need to remove everything and send full ORF list again this time containing as otherwise it would not be very effective as it would look like this: So I think RFC5291 needs a clarification stating that the text you quoted does not apply to cases where you send only DENY ORF entries. Robert, You have ignored the "non-empty" portion of the text I cited. If your point is that I should have stated instead: The default policy of a NON-EMPTY ORF is deny. The relevant point here is that once you have any ORF entry (all of which are generally deny per the procedures for this ORF type) you need an entry to act as a permit for everything else. If you have no deny filters, deleting the entire ORF (REMOVE-ALL) will accomplish the permit without having the default permit entry. -- Jeff
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: 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. I apologize for my prior inattention to this thread, however: 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.
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. 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. 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. 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. 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. 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? 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. Subject: Re: [bess] Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WGLC onchanges (1/29/2026 to 1/5/2026) |
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 If Overload = 0 which means ALL VPN ROUTES matching the filter MUST BE WITHDRAWN if Seq=0xFFFFFFFF (so this MUST be last ORF entry) if length=8 (so there must not be any optional TLVs) if RD=0 (meaning apply to all VPN prefixes for a given AFI/SAFI) 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. 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. 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. And please also see the in-line replies. Subject: [bess] Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC onchanges (1/29/2026 to 1/5/2026) |
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 ... 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. In section 5.2 I am finding extremely hard to parse description regarding using match filters with PERMIT. 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 If Overload = 0 which means ALL VPN ROUTES matching the filter MUST BE WITHDRAWN if Seq=0xFFFFFFFF (so this MUST be last ORF entry) if length=8 (so there must not be any optional TLVs) if RD=0 (meaning apply to all VPN prefixes for a given AFI/SAFI) 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. 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". 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. I think a "EVPN Route Type TLV" can be added in Section 4 to control the filter of EVPN routes. Subject: Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC onchanges (1/29/2026 to 1/5/2026) |
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. 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. Subject: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on changes (1/29/2026 to 1/5/2026) |
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? 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. 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. 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 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. 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. Subject: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on changes (1/29/2026 to 1/5/2026) |
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: +-------+-------------------------------+ +-------+-------------------------------+ | |MPLS-labeled VPN address | +------+--------------------------------+ +------+--------------------------------+
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. 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. 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]
|
