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

[Robert Raszuk <[e-mail]>]

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://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/

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]> 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]>
> *Sent:* Friday, May 1, 2026 9:44 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)
>
>
>
> 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]> 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]>
> *Sent:* Thursday, April 30, 2026 5:26 AM
> *To:* Susan Hares <[e-mail]>
> *Cc:* Roman Danyliw <[e-mail]>; The IESG <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [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]> 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]>
> Sent: Wednesday, April 29, 2026 12:54 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Susan Hares <[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]
> To unsubscribe send an email to [e-mail]
>
>