[bess] Re: Working Group Last Call on draft-ietf-bess-ebgp-dmz extended to 30 March, 2026.

[[e-mail]]

Hi Jeff, folks

I just posted the draft update


-----Original Message-----
From: Jeffrey Haas <[e-mail]> 
Sent: Tuesday, March 31, 2026 5:50 PM
To: BESS <[e-mail]>
Cc: [e-mail]; idr-chairs <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-bess-ebgp-dmz extended to
30 March, 2026.

This concludes the WGLC comment period.  Here is my assessment:

Supports advancing the document for publication:
Zafar Ali, Cisco
Jeff Tantsura, Nvidia (as coauthor)
Krishnaswamy Ananthamurthy, Cisco
Mankamana Mishra, Cisco
Jishnu Roy, HPE
Kaliraj Vairavakkali, HPE - specifically as with INFORMATIONAL status.
Julian Lucek, HPE

Does not support advancing the document for publication:
None.

Issues raised:
Kaliraj notes:
> 4.2. for consistency reason, all BGP paths of a prefix MUST use a
contributing bandwidth based on the same source (e.g.: all paths are using
contributing bandwidth from the same function).

I see that Reshma has taken this up and is responding the raised point from
Stephane.

Implementation Reports:
No implementation reports were sent as part of last call.  That said, I'm
personally aware of at least one implementation and will prod that party to
publicly respond.  It would be good if more than one implementation report
were submitted, but this isn't required by BESS practices.

Assessment:
My assessment as shepherd is that we have light support for advancing the
document and no requests to not publish at this time.  My recommendation
would be that once the point flagged by Kaliraj has been addressed that the
chairs request publication.

Once the BESS chairs have made their assessment, I'll update the shepherd
report for this document.

As a comment on the related WGLC for RFC 4360-bis in IDR, support has been
very light and no objections have been filed.  There are two minor comments
flagged during that last call to be assessed by the shepherd, Keyur.


-- Jeff (acting as shepherd)


> On Mar 23, 2026, at 11:24, Jeffrey Haas <[e-mail]> wrote:
> 
> While we have received a few positive replies about advancing this draft
to publication, response is very light and difficult to use to gauge
consensus.  
> 
> Similar to the RFC 4360 draft, we're extending the last call to 30 March.
> 
> Please respond to this thread as to whether this document SHOULD or SHOULD
NOT proceed to publication.
> 
> -- Jeff
> 
> 
>> On Mar 3, 2026, at 12:07, Jeffrey Haas <[e-mail]> wrote:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/
>> 
>> As the shepherd for the DMZ draft, this starts a working group last call
for draft-ietf-bess-ebgp-dmz..  This last call ends on 16 March.
>> 
>> Please indicate to the mailing list whether you think this document is
ready to advance to publication or not.
>> 
>> The shepherd writeup for this document is located here:
>>
https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/shepherdwriteup/
>> 
>> Note that we are still waiting for an IPR attestation from Arie Vayner.
Other working group members that are aware of undisclosed IPR are requested
to attest to it as part of IETF BCP 78/79.
>> 
>> As per BESS practices, this last call is also polling for the existence
of implementations of this draft.  See this prior note on the practice:
>> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw/
>> 
>> Please also note that there is a related last call happening in IDR
relating to RFC 4360-bis.  As BESS WG members are aware, the DMZ work was
motivated to address the transitivity aspects of the BGP link-bandwidth
extended community as part of the DMZ aggregation procedures.  The link
bandwidth draft has completed IDR last call and has been sent to the IESG
for publication.  The related work to address originating non-transitive BGP
extended communities was moved into the RFC 4360-bis work.
>> 
>> Thus, if you believe DMZ should progress, please respond to the IDR last
call on 4360-bis to help both works advance together.
>> 
>> https://mailarchive.ietf.org/arch/msg/idr/fftaCU5jpiYynWFfgex0dkjXB4E/
>> 
>> -- Jeff
>> 
>