[Idr] Re: [iesg] Re: Roman Danyliw's Discuss on draft-ietf-idr-vpn-prefix-orf-37: (with DISCUSS and COMMENT)

[Susan Hares <[e-mail]>]

Robert:

I have passed over your concerns to the shepherd for this draft, Keyur Patel.   He will be responding to all email threads today.  During our weekly IDR chair’s meeting, we discussed this document and the next steps.

If you have charter input that you did not provide during the WG discussion on the charter, you can raise the issue on the mail list or add an issue to the idr github for the charter.

Sue

PS  - All co-chairs respond to emails during IESG reviews if the main shepherd is in a meeting for a day.  However, once the main shepherd returns, the document shepherd responds.


From: Robert Raszuk <[e-mail]>
Sent: Friday, May 1, 2026 10:31 AM
To: Susan Hares <[e-mail]>
Cc: Ketan Talaulikar <[e-mail]>; Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Idr] Re: [iesg] Re: Roman Danyliw's Discuss on draft-ietf-idr-vpn-prefix-orf-37: (with DISCUSS and COMMENT)

Hi Sue,

Yes this is an ORF extension however applicable to ONLY L2 and L3 VPN SAFIs. Those are the products of BESS WG not IDR.

> In the same way, draft-ietf-bess-ebgp-dmz.

As you know this work is applicable to any SAFI, fits IDR WG charter directly and was splitted into two drafts:

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dlink-2Dbandwidth_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=SGNpUQKMZFK7DWIPkbjGJblf-BEUGy8Tvtg8ZVV1UbLxXNTfxdkOLbkFll1mB9eI&s=ZcFdexOP9JeA47HgnBC2tGZwap8qhSumfwEQFNu-BkU&e=>
https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Debgp-2Ddmz_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=SGNpUQKMZFK7DWIPkbjGJblf-BEUGy8Tvtg8ZVV1UbLxXNTfxdkOLbkFll1mB9eI&s=th1vUgzgG9H2dt0c5xCr-oOgqScl4k_FNt-UArpgo74&e=>

but draft-ietf-idr-vpn-prefix-orf is applicable only to SAFI 5, 128, 70, 65 & 8. None of those SAFIs is a focus of IDR WG.

> PS – You were considered to be in the “rough” for the initial WG LC consensus.

That is correct. And I am going to remain in "rough" till "overload bit = 1" is removed from the document and sequence numbers are renamed back to identifiers.

Kind regards,
Robert


On Fri, May 1, 2026 at 4:16 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Robert:

It defines a new ORF function in the IDR Charter. In the case of a draft that may cross two WGs (a BGP function and a L3VPN function), we cross-post to both WGs.  We discuss with the BESS chairs whether the draft is useful.  This draft was accepted and WG LC with this understanding.  In the same way, draft-ietf-bess-ebgp-dmz.

It appears that this draft will undergo enough changes to require a WG LC on changes in the IDR WG.  We can post this WG LC on changes to BESS and IDR.  We will open the discussion to other comments from BESS.

Sue

PS – You were considered to be in the “rough” for the initial WG LC consensus.

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, May 1, 2026 9:44 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>; Roman Danyliw <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] Re: [iesg] Re: Roman Danyliw's Discuss on draft-ietf-idr-vpn-prefix-orf-37: (with DISCUSS and COMMENT)

Dear Sue,

The subject draft defines 100% a L3VPN VPN extension which is completely outside of the current and new IDR charter.

In fact the new charter explicitly limits IDR authority in respect to any BGP services related work to "advice and collaborate".

Quote:

Given the broad use of BGP across various WGs in the IETF, the IDR WG will provide advice and collaborate closely with other WGs developing or relying on BGP extensions and their BGP-related YANG models. This includes BESS (VPN service-related BGP features),

Maybe this is the main reason why discussion about this draft on IDR WG list did not got too much attention as perhaps only few folks on the list cares about VPN extensions. Such work clearly fits in BESS WG.

Kind regards,
Robert






On Fri, May 1, 2026 at 3:34 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Ketan and Roman:

Agreed that the charter does not specifically state “maintenance” of BGP.  This “organizational context” was not stated in the charter and was deemed inappropriate to include in the 2010 charter.  Times and People change.  To align with the 2026 IESG, I am glad the IESG is reviewing the charter soon.

We are working on milestones in IDR chairs discussion today.  I expect milestones will continue discussion until 5/8 or 5/11 (IDR interim)>

Sue

From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 30, 2026 5:26 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: Roman Danyliw <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [iesg] Re: Roman Danyliw's Discuss on draft-ietf-idr-vpn-prefix-orf-37: (with DISCUSS and COMMENT)

Hi Roman,

I am OK with waiting for the community approval of the proposal charter which is expected to come before the IESG for review soon.

Sue, the current IDR charter does not (literally) list "maintenance" even though the IDR WG has been doing various BGP maintenance and extensions work for a long time. Since the IDR WG is re-chartering, I expect this aspect to be clarified soon.

Thanks,
Ketan


On Thu, Apr 30, 2026 at 2:46 AM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Roman:

Outbound Route Filtering (ORF) has been consider a Core BGP function.  Maintenance of core BGP functions [RFC5291][RFC5202] maintenance is in our 2010 charter.

For the 2026 charter, see the line
Outbound Route Filtering (ORF) mechanisms [RFC5291][RFC5292] for policy-based control of route advertisement.

Please let me know if this answers your question.

Sue Hares
IDR co-chair

-----Original Message-----
From: Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 29, 2026 12:54 PM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: Roman Danyliw's Discuss on draft-ietf-idr-vpn-prefix-orf-37: (with DISCUSS and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-idr-vpn-prefix-orf-37: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
for more information about how to handle DISCUSS and COMMENT positions.




----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

To the IDR WG Chairs and responsible AD: I need your help understanding how
this document fits into the approved scope of work.  The currently approved
charter from 2010 is -05.

As an experimental draft, I don’t see how it fits into the “The IDR working
group will work on correctness, robustness and scalability of the BGP protocol,
as well as clarity and accuracy of the BGP document set.”

In examining, bulleted list after “The group will also work on extensions
beyond these areas when specifically added to the charter”, this document also
doesn’t seem to fit into any of them.  There is a reference to ORF in the
context of “Define AS_PATH based Outbound Route Filtering”, but that doesn’t
seem to match (and there is a draft-ietf-idr-aspath-orf-13 seemingly expired
from 2016 and a milestone marked as complete).

I note that there is a draft -05-00 version of the charter.  It has the scoping
text of “Outbound Route Filtering (ORF) mechanisms [RFC5291][RFC5292] for
policy-based control of route advertisement” which seems to fit the intent of
this document.

Perhaps this document could wait for community approval of the new chartered
text.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Peter Yee for the GENART review.
_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>