[Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on changes (1/29/2026 to 1/5/2026)

[Robert Raszuk <[e-mail]>]

Btw I do not see this document on the implementation report IDR wiki

https://wiki.ietf.org/group/idr/BGP-implementation-report

Is this just an accidental omission ?

Thx,
R.



On Fri, Jan 30, 2026 at 2:49 PM Robert Raszuk <[e-mail]> wrote:

> Hi Aijun,
>
> On Fri, Jan 30, 2026 at 2:37 PM Aijun Wang <[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]> 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]> 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]>
>>> Date: 2026-01-30 02:06
>>> To: Susan Hares <[e-mail]>
>>> Cc: idr <[e-mail]>, Keyur Patel <[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]
>> To unsubscribe send an email to [e-mail]
>>
>>