[bess] Meeting minute IETF 118

[Mankamana Mishra (mankamis)]

All,
https://datatracker.ietf.org/meeting/118/materials/minutes-118-bess-202311061200-01

meeting minutes have been uploaded. If there is any comment please send me .

Mankamana
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG Last Call for draft-ietf-bess-bgp-sdwan-usage-17

[Ayan Banerjee]

Support WG LC.

Thanks,
Ayan

On Thu, Nov 16, 2023 at 3:49 AM Matthew Bocci (Nokia) <
matthew.bo...@nokia.com> wrote:

> This email begins a second working group last call for 
> draft-ietf-bess-bgp-sdwan-usage-17
> - BGP Usage for SD-WAN Overlay Networks
> 
>
>
>
> A little bit of history: A previous version was adopted, completed WG last
> call, and publication requested as an Informational RFC. v15 of this draft
> was reviewed by the IESG and found to have a restrictive clause in the
> boilerplate. This has now been removed and the document re-adopted by the
> working group. We are now going through a quick WG last call.
>
>
>
> An IPR poll was completed on the previous version of the draft for which
> we requested publication.
>
>
>
> Please review the draft and post any comments to the BESS mailing list.
>
>
>
> This poll will close on Friday 24th November.
>
>
>
> Regards
>
>
>
> Matthew
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Matthew Bocci (Nokia)]

WG

I haven’t seen any concerns regarding this draft being marked as updating RFC 
8584. I will therefore proceed with the document shepherd’s write up and 
publication request process.

Regards

Matthew

From: Matthew Bocci (Nokia) 
Date: Friday, 13 October 2023 at 17:49
To: Luc Andre Burdet (lburdet) , Adrian Farrel 
, rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07
Authors, Working Group,

I would like to gauge the consensus of the group on the question below about 
the draft updating 8584. The meaning of “updates” is perhaps a little 
ambiguous, and the interpretation I had used when suggesting that we should 
mark the draft as updating 8584 was that it makes some changes to the 
procedures in 8584. Specifically, these changes are described in the 
introduction section of the draft, as follows:

“This document updates the state machine described in Section 2.1 of
   [RFC8584], by optionally introducing delays between some events, as
   further detailed in Section 2.2.  The solution is based on a simple
   one-way signaling mechanism.”


Are there any concerns about interoperability between a 8584-only compliant 
implementation, and one that also implements 
draft-ietf-bess-evpn-fast-df-recovery?

Thanks

Matthew



From: Luc Andre Burdet (lburdet) 
Date: Monday, 10 July 2023 at 19:46
To: Adrian Farrel , rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi Adrian,

Thank you for your valuable comments, and apologies for the late reply/update. 
I have incorporated all changes into -v08 which I hope address your feedback: 
some comments are replied to below:


I note that the topic of "updates" was raised by matthew in his review,
and that 2.2 is clear about the changes. I note, however, that the
decision to make this an Update happened after WG last call, and I
wonder whether the owrking group is fully on board with the implication
that any future implementation claiming conformance to 8584 will be
required to implement this specification. There is a difference between
an Update and an additional procedure.

[LAB] It is worth noting that the delay introduced (change to 8584) is by 
default 0 i.e. no change to RFC8584 when the extcomm is not present.
An implementation which does not support this adding a delay of 0 and one 
supporting it but with a delay of 0 would display similar behaviours ?  I can 
defer to Matthew and the WG on this.


Why bit 3? I know the answer is "because that's the bit our
implementation uses" and I'm fine with that and I'm not asking for any
change, but it makes me suspicious about what happened to bits 0 and 2.
Why aren't they used? Is someone squatting on them?

[LAB] yes bits 0 and 2 are in-use already for Preference-Based DF indication;  
Bit 2 is iirc from an old version of this document which was also requesting a 
H=handshake bit, no longer is.  We felt it best to just leave this one at 3 
instead of shifting down. (Bit 5 is also in-use for Port-Mode in another 
document)



I see some challenges here.
The first is when a PE joins the segment while DF election is ongoing
among the other PEs.
The second is what happens if the SCT BGP extended community is present
when the T-bit is not set.
The third is what happens if the T-bit is set but no SCT BGP extended
community is provided.
All of these are easy to describe.

Does the backwards compatibility not describe these already i.e. “SHALL revert 
back to 7432” ?

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Adrian Farrel via Datatracker 
Date: Saturday, May 27, 2023 at 15:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07
Reviewer: Adrian Farrel
Review result: Has Issues

Hello

I have been selected to do a Routing Directorate early review of this draft..
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery. I
reviewed revision -07.

The Routing Directorate will, on request from the working group chair, perform
an early review of a draft before it is submitted for publication to the IESG.
The early review can be performed at any time during the draft's lifetime as a
working group document. The purpose of the early review depends on the stage
that the document has reached.

I reviewed revision -07 of this draft after the completion of WG last call and
shepherd review, but before the WG makes a publication request. The purpose of
a review at this stage is to improve the quality before AD review and so reduce
the AD workload as 

Re: [bess] WG Adoption and IPR poll for draft-sajassi-bess-evpn-ip-aliasing-09

[Gunter van de Velde (Nokia)]

I support adoption. 
The draft has multiple implementations and addresses an important extension to 
the RFCs 9135 and 9136

Be well,
Gunter Van de Velde

-Original Message-
From: BESS  On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Monday, November 13, 2023 12:51 PM
To: 'BESS' 
Cc: 'bess-cha...@ietf.org' ; 
draft-sajassi-bess-evpn-ip-alias...@ietf.org
Subject: [bess] WG Adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Hi,

This email begins a two-week WG adoption and IPR poll for 
draft-sajassi-bess-evpn-ip-aliasing-09 
(https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-09).

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document will not progress 
without answers from all the authors and contributors.

If you are not listed as an author or a contributor, then please explicitly 
respond to the IPR poll only if you are aware of any IPR that has not yet been 
disclosed in conformance with IETF rules.

This poll for adoption closes on Monday, 27th of November, 2023.

Thanks.
Jeffrey

Juniper Business Use Only

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] The BESS WG has placed draft-sajassi-bess-evpn-ip-aliasing in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The BESS WG has placed draft-sajassi-bess-evpn-ip-aliasing in state
Call For Adoption By WG Issued (entered by Zhaohui Zhang)

The document is available at
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ip-aliasing/

Comment:
The call started on 11/13 and ends on 11/27.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess