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

[Susan Hares <[e-mail]>]

I will add that.

Sue

Sent via the Samsung Galaxy S23 Ultra 5G, an AT&T 5G smartphone
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Robert Raszuk <[e-mail]>
Sent: Friday, January 30, 2026 2:59:29 PM
To: Susan Hares <[e-mail]>
Cc: Ketan Talaulikar <[e-mail]>; Aijun Wang <[e-mail]>; idr <[e-mail]>; Keyur Patel <[e-mail]>
Subject: Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on changes (1/29/2026 to 1/5/2026)

Hi Sue,

I googled for "BGP IDR implementations" and got in return this link:

https://wiki.ietf.org/group/idr/BGP-implementation-report<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_group_idr_BGP-2Dimplementation-2Dreport&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=TaDKwmTE0HMtkW0n3KrLYhx3LS0v8JUxB_PnIKhmqQqCq5GpfjPjiDwu80cNkEPS&s=LoMElytz07SdsFyZSUdyKkyhI2r0G-wplU0GYri4OBU&e=>

I followed and did not find the subject draft listed hence the question.

It would be cool to just say on top that "old" that this page is obsolete
and provide a link to a new page. You don't have to delete it.

Thx,
Robert


On Fri, Jan 30, 2026 at 8:41 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:

Please go through the main page link to implementations.   It has the right link.

https://wiki.ietf.org/en/group/idr/implementations<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_en_group_idr_implementations&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=aCKeJc6M8mg-f-WW5vufMg4mp4NmI1hn_ZvrJzdl-qzeD28Y0WQshRZHxDvdXmv_&s=FDJJhhykNqUHhNNDBcOgRh2-5lguOXpKCMs6U8V29yc&e=>



This web page is listed as the “old implementation page”.

https://wiki.ietf.org/group/idr/BGP-implementation-report<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_group_idr_BGP-2Dimplementation-2Dreport&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=aCKeJc6M8mg-f-WW5vufMg4mp4NmI1hn_ZvrJzdl-qzeD28Y0WQshRZHxDvdXmv_&s=vMZfGSsTeFByjq8W6AD13BG6uOkS7qnHlST6PGsbxho&e=>



There are links on the old page to the new page.

https://wiki.ietf.org/en/group/idr/implementations<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_en_group_idr_implementations&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=aCKeJc6M8mg-f-WW5vufMg4mp4NmI1hn_ZvrJzdl-qzeD28Y0WQshRZHxDvdXmv_&s=FDJJhhykNqUHhNNDBcOgRh2-5lguOXpKCMs6U8V29yc&e=>



Tracing down how to kill this extra page – is not on the top of my queue yet.



Sue

PS - Our IDR chair document priority is (fyi)



1) documents at IESG

2) documents past WG LC,

3) documents in WG LC,

4) Preparing documents that have asked for WG LC documents,

5) WG Adoption calls

6) preparing documents that have asked for adoption

7) Urgent documents (from WG list)





From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 30, 2026 9:31 AM
To: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: Aijun Wang <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; idr <[e-mail]<mailto:[e-mail]>>; Keyur Patel <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on changes (1/29/2026 to 1/5/2026)



So there are multiple pages listing implementation reports in IDR ?



https://wiki.ietf.org/en/group/idr/implementations<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_en_group_idr_implementations&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=aCKeJc6M8mg-f-WW5vufMg4mp4NmI1hn_ZvrJzdl-qzeD28Y0WQshRZHxDvdXmv_&s=FDJJhhykNqUHhNNDBcOgRh2-5lguOXpKCMs6U8V29yc&e=>



https://wiki.ietf.org/group/idr/BGP-implementation-report<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_group_idr_BGP-2Dimplementation-2Dreport&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=aCKeJc6M8mg-f-WW5vufMg4mp4NmI1hn_ZvrJzdl-qzeD28Y0WQshRZHxDvdXmv_&s=vMZfGSsTeFByjq8W6AD13BG6uOkS7qnHlST6PGsbxho&e=>



Why is that ?



Thx,

R.



On Fri, Jan 30, 2026 at 3:26 PM Ketan Talaulikar <[e-mail]<mailto:[e-mail]>> wrote:

https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-vpn-prefix-orf<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_group_idr_implementations_draft-2Dietf-2Didr-2Dvpn-2Dprefix-2Dorf&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=aCKeJc6M8mg-f-WW5vufMg4mp4NmI1hn_ZvrJzdl-qzeD28Y0WQshRZHxDvdXmv_&s=8UfN5ZhQkvaJ1fmcL71GMsfQqtDuRfGCnolJfN-UCXI&e=>



In view of the ongoing discussions, I will note that it is not clear if the implementations supported and tested for L3VPN only or also for EVPN.



Thanks,

Ketan





On Fri, Jan 30, 2026 at 7:52 PM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:



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



https://wiki.ietf.org/group/idr/BGP-implementation-report<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ietf.org_group_idr_BGP-2Dimplementation-2Dreport&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=aCKeJc6M8mg-f-WW5vufMg4mp4NmI1hn_ZvrJzdl-qzeD28Y0WQshRZHxDvdXmv_&s=vMZfGSsTeFByjq8W6AD13BG6uOkS7qnHlST6PGsbxho&e=>



Is this just an accidental omission ?



Thx,

R.







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

Hi Aijun,



On Fri, Jan 30, 2026 at 2:37 PM Aijun Wang <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>

Date: 2026-01-30 02:06

To: Susan Hares <[e-mail]<mailto:[e-mail]>>

Cc: idr <[e-mail]<mailto:[e-mail]>>, Keyur Patel <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>



_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>