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]_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
