Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Luc André Burdet]

Hi Matthew,

Thanks for the review/comment. I took a closer look at RFC8584, specifically 
the section about the DF FSM.

The behaviour at PE1 which has a recovering interface ES1 remains unchanged. 
Effectively PE1 is signalling the equivalent of the DF_TIMER event which leads 
from DF_WAIT to DF_CALC.

The behaviour at PE2 receiving the ES route with SCT extcomm would correspond 
to :

  *   DF_DONE :  RCVD_ES -> DF_CALC   (action #11)
  *   DF_CALC:  CALCULATED -> DF_DONE (action #9)

I find the actions described for #9-11 somewhat vague (maybe even wrong for 
#10?)
   9.   DF_CALC on CALCULATED: Mark the election result for the VLAN or
bundle, and transition to DF_DONE.

   10.  DF_DONE on exiting the state: If a new DF election is triggered
and the current DF is lost, then assume an NDF for the local PE
for the VLAN or VLAN Bundle.

   11.  DF_DONE on VLAN_CHANGE, RCVD_ES, or LOST_ES: Transition to
DF_CALC.


“marking the election result” in action #9 to me stands out in contrast to 
“assume an NDF for the local PE“ elsewhere, which conveys effectively 
programming hardware...


Action#10 could be read to do that but it’s on exiting the state... which we 
have done already to go to DF_CALF on the RCVD_ES.  The text in RFC8584 seems 
to wrongly think any new/updated DF result is available already when exiting 
the state—not on re-entering it from DF_CALC.
Action#10 should be reviewed to be sure it’s not on  **entering** DF_DONE with 
a (new) DF result from DF_CALC.

I don’t mind marking this draft updating 8584 and adding the following:


+   This document introduces an additional delay to the events and

+   transitions defined for the default DF election algorithm in

+   [RFC8584].

   9.   DF_CALC on CALCULATED: Mark the election result for the VLAN or
Bundle.
+  9.1  Where SCT timestamp is present on the RECV_ES event of Action 11,
+   wait the remaining time before continuing to 9.2.
+  9.2  Assume a DF/NDF for the local PE for the VLAN or VLAN Bundle,
and transition to DF_DONE.

   10.  DF_DONE on exiting the state: If a new DF election is triggered
and the current DF is lost, then assume an NDF for the local PE
for the VLAN or VLAN Bundle.


   11.  DF_DONE on VLAN_CHANGE, RCVD_ES, or LOST_ES: Transition to

DF_CALC.


This would be better though:


+   This document introduces an additional delay to the events and

+   transitions defined for the default DF election algorithm in

+   [RFC8584].

   9.   DF_CALC on CALCULATED: Mark the election result for the VLAN or
Bundle.
+  9.1  Where SCT timestamp is present on the RECV_ES event of Action 11,
+   wait the remaining time before continuing to 9.2
+  9.2  Transition to DF_DONE.

+  10.  DF_DONE on **entering** the state: If a new DF election is triggered
and the current DF is lost, then assume an NDF for the local PE
for the VLAN or VLAN Bundle.


Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: Matthew Bocci (Nokia) 
Date: Thursday, November 3, 2022 at 06:33
To: Ali Sajassi (sajassi) , 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: Re: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Authors and WG

A further question about this document. Do you consider that it updates the 
procedures in RFC8584?

The abstract says the following: “This document improves these procedures by 
providing a fast Designated Forwarder (DF) election upon recovery of the failed 
link or node associated with the multihomed Ethernet Segment. “

If so, please add “Updates 8584” to the header.

Thanks

Matthew


From: Bocci, Matthew (Nokia - GB) 
Date: Thursday, 14 July 2022 at 10:39
To: Ali Sajassi (sajassi) , 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: Re: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Ali, WG,

Thank you.

I think there is consensus to publish the draft as a standards track RFC.

Please watch for my shepherd’s review.

Regards

Matthew

From: Ali Sajassi (sajassi) 
Date: Wednesday, 13 July 2022 at 20:01
To: Bocci, Matthew (Nokia - GB) , 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: Re: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
I support publication of this document and I am not aware of any IPR that 
hasn’t been disclosed.

Cheers,
Ali

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, January 31, 2022 at 5:58 AM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Matthew Bocci (Nokia)]

Authors and WG

A further question about this document. Do you consider that it updates the 
procedures in RFC8584?

The abstract says the following: “This document improves these procedures by 
providing a fast Designated Forwarder (DF) election upon recovery of the failed 
link or node associated with the multihomed Ethernet Segment. “

If so, please add “Updates 8584” to the header.

Thanks

Matthew


From: Bocci, Matthew (Nokia - GB) 
Date: Thursday, 14 July 2022 at 10:39
To: Ali Sajassi (sajassi) , 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: Re: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Ali, WG,

Thank you.

I think there is consensus to publish the draft as a standards track RFC.

Please watch for my shepherd’s review.

Regards

Matthew

From: Ali Sajassi (sajassi) 
Date: Wednesday, 13 July 2022 at 20:01
To: Bocci, Matthew (Nokia - GB) , 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: Re: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
I support publication of this document and I am not aware of any IPR that 
hasn’t been disclosed.

Cheers,
Ali

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, January 31, 2022 at 5:58 AM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Bocci, Matthew (Nokia - GB)]

Ali, WG,

Thank you.

I think there is consensus to publish the draft as a standards track RFC.

Please watch for my shepherd’s review.

Regards

Matthew

From: Ali Sajassi (sajassi) 
Date: Wednesday, 13 July 2022 at 20:01
To: Bocci, Matthew (Nokia - GB) , 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: Re: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
I support publication of this document and I am not aware of any IPR that 
hasn’t been disclosed.

Cheers,
Ali

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, January 31, 2022 at 5:58 AM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[UTTARO, JAMES]

Support

Thanks,
  Jim Uttaro

From: BESS  On Behalf Of Ali Sajassi (sajassi)
Sent: Wednesday, July 13, 2022 3:02 PM
To: Bocci, Matthew (Nokia - GB) ; 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: Re: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03

I support publication of this document and I am not aware of any IPR that 
hasn't been disclosed.

Cheers,
Ali

From: Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>>
Date: Monday, January 31, 2022 at 5:58 AM
To: 
draft-ietf-bess-evpn-fast-df-recov...@ietf.org<mailto:draft-ietf-bess-evpn-fast-df-recov...@ietf.org>
 
mailto:draft-ietf-bess-evpn-fast-df-recov...@ietf.org>>,
 bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>
Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> 
mailto:bess-cha...@ietf.org>>
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/__;!!BhdT!g3ygNW_RlTjLwaA3FL2Hc6OHuggNWqNl1M-8u7XvTLUYD0M8IrgzNGVMVubYvmEr9XUXRW6ITZeOXFWJFiKhzrpkF7Y$>
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!!BhdT!g3ygNW_RlTjLwaA3FL2Hc6OHuggNWqNl1M-8u7XvTLUYD0M8IrgzNGVMVubYvmEr9XUXRW6ITZeOXFWJFiKh2i8g8iU$>


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Ali Sajassi (sajassi)]

I support publication of this document and I am not aware of any IPR that 
hasn’t been disclosed.

Cheers,
Ali

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, January 31, 2022 at 5:58 AM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Anoop Ghanwani]

Thanks Luc.

I have reviewed the changes and they look good to me.

On Sat, Feb 12, 2022 at 10:45 AM Luc André Burdet 
wrote:

> Hi Anoop,
>
> Thanks for your detailed review, I have posted -04 addressing these
> comments.
>
>
>
> >>Timestamp Fractional Seconds (17 bits)
>
> This threw me off for a bit...
>
> >> Now that I double check, the figure is wrong!  It uses only 7 bits for
> the Type which looks like it should be 8 bits.  So it looks like Timestamp
> Fractional Seconds should be 16 bits.
>
> ...but you actually hit onto a critical misalignment in the figure !
>
>
>
> I have moved the whole description section up into the encoding/extcomm as
> descriptive text of the fields themselves. Nice catch, thank you !
>
>
>
> Regards,
>
> Luc André
>
>
>
> Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254
> 4814
>
>
>
>
>
> *From: *Anoop Ghanwani 
> *Date: *Friday, February 4, 2022 at 12:50
> *To: *Bocci, Matthew (Nokia - GB) 
> *Cc: *draft-ietf-bess-evpn-fast-df-recov...@ietf.org <
> draft-ietf-bess-evpn-fast-df-recov...@ietf.org>, bess@ietf.org <
> bess@ietf.org>, bess-cha...@ietf.org 
> *Subject: *Re: [bess] WGLC, IPR and Implementation Poll for
> draft-ietf-bess-evpn-fast-df-recovery-03
>
> I support publication of the document as an RFC.  However, I think there
> are some editorial nits that need to be addressed (see below).
>
>
>
> Anoop
>
>
>
> ==
>
>
>
> Abstract
>
>
>
> performed via a simple signaling between the recovered PE
>and each PEs in the multi-homing group.
> ->
> performed via simple signaling between the recovered PE
>and each of the other PEs in the multi-homing group.
>
>
>
>
>
> Multiple sections
>
>
>
> multi-homing Ethernet Segment ->
>
> multi-homed Ethernet Segment
>
>
>
> Ethernet-Segment ->
>
> Ethernet Segment
>
>
>
> There are some instances of use of ES (section 3.2).  Either ES should be
> spelled out and used throughout or, which is what I would do, replace the 2
> instances of ES in Section 3.2 with Ethernet Segment.
>
> It would also be good to provide captions for all figures since it makes
> it easy to reference.
>
>
>
> Section 1
>
> EVPN solution [RFC7432]
> ->
> The EVPN specification [RFC7432]
>
>
>
> and it is performed via a
>simple signaling between the recovered PE and each PE in the multi-
>homing group.
> ->
> and it is performed via
>simple signaling between the recovered PE and each of the other PEs in
> the multi-
>homing group.
>
>
>
>
>
> Section 2
>
> The current state of art (Highest Random Weight)
> ->
> The current state of art HRW (Highest Random Weight)
>
>
>
> duplication of DF roles for a give VLAN is possible.
> ->
> duplication of DF roles for a given VLAN is possible.
>
>
>
>
>
> Section 3.1
>
>
>-  A simple uni-directional signaling is all needed
> ->
>-  A simple uni-directional signaling is all that is needed
>
>
> -  (e.g .NTP, PTP, etc.)
> ->
> -  (e.g. NTP, PTP, etc.)
>
>
>
>
>
> Section 3.2
>
> It would be good to explicitly explain the fields below the figure, e.g.
> Timestamp Seconds (32 bits): ...
> Timestamp Fractional Seconds (17 bits): ... (provide details on how this
> part is created)
> If this is omitted because it is in some other doc, then provide a
> reference.
>
>
>
> [Looks like the figure is wrong about length for Timestamp Fractional
> Seconds which is why it would help to have a description as above.]
>
>
>
> PEs in the ES [there are 2 instances]
>
> ->
>
> PEs attached to the Ethernet Segment
>
>
>
> want the DF type be of HRW
>
> ->
> want the DF type to be HRW
>
>
>
> "The use
>of a 32-bit seconds and 16-bit fractional seconds yields adequate
>precision of 15 microseconds (2^-16 s)."
>
> The figure shows 17 bits for fractional seconds.  Now that I double check,
> the figure is wrong!  It uses only 7 bits for the Type which looks like it
> should be 8 bits.  So it looks like Timestamp Fractional Seconds should be
> 16 bits.
>
>
>
>
>
> Section 3.4
>
>-  PE2, it starts its 3sec peering timer as per RFC7432
> ->
>-  PE2, starts its 3 sec peering timer as per RFC7432
>
>
>
> [RFC7432] aims of favouring traffic black hole over duplicate traffic
> (Missing period at end of sentence.)
>
>
>
> Spell out first use of NDF.
>
>
>
> becomes a no-op
>

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Luc André Burdet]

Hi Anoop,
Thanks for your detailed review, I have posted -04 addressing these comments.

>>Timestamp Fractional Seconds (17 bits)
This threw me off for a bit...
>> Now that I double check, the figure is wrong!  It uses only 7 bits for the 
>> Type which looks like it should be 8 bits.  So it looks like Timestamp 
>> Fractional Seconds should be 16 bits.
...but you actually hit onto a critical misalignment in the figure !

I have moved the whole description section up into the encoding/extcomm as 
descriptive text of the fields themselves. Nice catch, thank you !

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: Anoop Ghanwani 
Date: Friday, February 4, 2022 at 12:50
To: Bocci, Matthew (Nokia - GB) 
Cc: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
, bess-cha...@ietf.org 
Subject: Re: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
I support publication of the document as an RFC.  However, I think there are 
some editorial nits that need to be addressed (see below).

Anoop

==

Abstract

performed via a simple signaling between the recovered PE
   and each PEs in the multi-homing group.
->
performed via simple signaling between the recovered PE
   and each of the other PEs in the multi-homing group.


Multiple sections

multi-homing Ethernet Segment ->
multi-homed Ethernet Segment

Ethernet-Segment ->
Ethernet Segment

There are some instances of use of ES (section 3.2).  Either ES should be 
spelled out and used throughout or, which is what I would do, replace the 2 
instances of ES in Section 3.2 with Ethernet Segment.

It would also be good to provide captions for all figures since it makes it 
easy to reference.


Section 1

EVPN solution [RFC7432]
->
The EVPN specification [RFC7432]

and it is performed via a
   simple signaling between the recovered PE and each PE in the multi-
   homing group.
->
and it is performed via
   simple signaling between the recovered PE and each of the other PEs in the 
multi-
   homing group.



Section 2
The current state of art (Highest Random Weight)
->
The current state of art HRW (Highest Random Weight)

duplication of DF roles for a give VLAN is possible.
->
duplication of DF roles for a given VLAN is possible.


Section 3.1

   -  A simple uni-directional signaling is all needed
->
   -  A simple uni-directional signaling is all that is needed

-  (e.g .NTP, PTP, etc.)
->
-  (e.g. NTP, PTP, etc.)


Section 3.2
It would be good to explicitly explain the fields below the figure, e.g.
Timestamp Seconds (32 bits): ...
Timestamp Fractional Seconds (17 bits): ... (provide details on how this part 
is created)
If this is omitted because it is in some other doc, then provide a reference.

[Looks like the figure is wrong about length for Timestamp Fractional Seconds 
which is why it would help to have a description as above.]

PEs in the ES [there are 2 instances]
->
PEs attached to the Ethernet Segment

want the DF type be of HRW
->
want the DF type to be HRW

"The use
   of a 32-bit seconds and 16-bit fractional seconds yields adequate
   precision of 15 microseconds (2^-16 s)."
The figure shows 17 bits for fractional seconds.  Now that I double check, the 
figure is wrong!  It uses only 7 bits for the Type which looks like it should 
be 8 bits.  So it looks like Timestamp Fractional Seconds should be 16 bits.


Section 3.4

   -  PE2, it starts its 3sec peering timer as per RFC7432
->
   -  PE2, starts its 3 sec peering timer as per RFC7432

[RFC7432] aims of favouring traffic black hole over duplicate traffic
(Missing period at end of sentence.)

Spell out first use of NDF.

becomes a no-op
->
becomes a non-issue.

The usage of
   SCT approach remedies to the exposed problem with the usage of
   peering timer.  The 3 seconds timer window is shorthen to few
   milliseconds.
->
The usage of
   SCT approach remedies the problem with the usage of the
   peering timer.  The 3 second timer window is shortened to a few
   milliseconds.


Section 3.5

modulus based
->
modulo-based

running an baseline DF election
->
running a baseline DF election

shall simply discard unrecognized new SCT BGP extended community.
->
will simply disregard the new SCT BGP extended community.

"...all PEs in the Ethernet-Segment may revert back to the RFC7432 timer 
approach."
Is this a "may" or should it be a "must"?

On Mon, Jan 31, 2022 at 5:58 AM Bocci, Matthew (Nokia - GB) 
mailto:matthew.bo...@nokia.com>> wrote:
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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 an

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Anoop Ghanwani]

I support publication of the document as an RFC.  However, I think there
are some editorial nits that need to be addressed (see below).

Anoop

==

Abstract

performed via a simple signaling between the recovered PE
   and each PEs in the multi-homing group.
->
performed via simple signaling between the recovered PE
   and each of the other PEs in the multi-homing group.


Multiple sections

multi-homing Ethernet Segment ->
multi-homed Ethernet Segment

Ethernet-Segment ->
Ethernet Segment

There are some instances of use of ES (section 3.2).  Either ES should be
spelled out and used throughout or, which is what I would do, replace the 2
instances of ES in Section 3.2 with Ethernet Segment.

It would also be good to provide captions for all figures since it makes it
easy to reference.


Section 1

EVPN solution [RFC7432]
->
The EVPN specification [RFC7432]

and it is performed via a
   simple signaling between the recovered PE and each PE in the multi-
   homing group.
->
and it is performed via
   simple signaling between the recovered PE and each of the other PEs in
the multi-
   homing group.



Section 2

The current state of art (Highest Random Weight)
->
The current state of art HRW (Highest Random Weight)

duplication of DF roles for a give VLAN is possible.
->
duplication of DF roles for a given VLAN is possible.



Section 3.1

   -  A simple uni-directional signaling is all needed
->
   -  A simple uni-directional signaling is all that is needed

-  (e.g .NTP, PTP, etc.)
->
-  (e.g. NTP, PTP, etc.)


Section 3.2

It would be good to explicitly explain the fields below the figure, e.g.
Timestamp Seconds (32 bits): ...
Timestamp Fractional Seconds (17 bits): ... (provide details on how this
part is created)
If this is omitted because it is in some other doc, then provide a
reference.

[Looks like the figure is wrong about length for Timestamp Fractional
Seconds which is why it would help to have a description as above.]

PEs in the ES [there are 2 instances]
->
PEs attached to the Ethernet Segment

want the DF type be of HRW
->
want the DF type to be HRW

"The use
   of a 32-bit seconds and 16-bit fractional seconds yields adequate
   precision of 15 microseconds (2^-16 s)."

The figure shows 17 bits for fractional seconds.  Now that I double check,
the figure is wrong!  It uses only 7 bits for the Type which looks like it
should be 8 bits.  So it looks like Timestamp Fractional Seconds should be
16 bits.


Section 3.4

   -  PE2, it starts its 3sec peering timer as per RFC7432
->
   -  PE2, starts its 3 sec peering timer as per RFC7432

[RFC7432] aims of favouring traffic black hole over duplicate traffic
(Missing period at end of sentence.)

Spell out first use of NDF.

becomes a no-op
->
becomes a non-issue.

The usage of
   SCT approach remedies to the exposed problem with the usage of
   peering timer.  The 3 seconds timer window is shorthen to few
   milliseconds.
->
The usage of
   SCT approach remedies the problem with the usage of the
   peering timer.  The 3 second timer window is shortened to a few
   milliseconds.



Section 3.5

modulus based
->
modulo-based

running an baseline DF election
->
running a baseline DF election

shall simply discard unrecognized new SCT BGP extended community.
->
will simply disregard the new SCT BGP extended community.

"...all PEs in the Ethernet-Segment may revert back to the RFC7432 timer
approach."
Is this a "may" or should it be a "must"?

On Mon, Jan 31, 2022 at 5:58 AM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:

> Hi WG,
>
>
>
> This email starts a two-week Working Group Last Call on 
> draft-ietf-bess-evpn-fast-df-recovery-03
> [1].
>
>
>
> This poll runs until Monday 14th February 2022.
>
>
>
> 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. The Document won't progress without answers from
> all the Authors and Contributors.
>
> There is currently no IPR disclosed.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> We are also polling for any existing implementation as per [2]. Please
> indicate if you are aware of any implementations.
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
> [1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF
> Election
> 
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> 

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Gyan Mishra]

I support publication.

Thanks

Gyan
On Tue, Feb 1, 2022 at 2:14 PM Patrice Brissette (pbrisset)  wrote:

> I support publication and am not aware of undisclosed IPR.
>
>
>
> Implementation has been shipped on Cisco IOS-XR.
>
> Regards,
>
> Patrice Brissette, Principal Engineer
>
> Cisco Systems
>
>
>
> *http://e-vpn.io <http://e-vpn.io>*
>
> *http://go2.cisco.com/evpn <http://go2.cisco.com/evpn>*
>
>
>
>
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" 
>
>
> *Date: *Monday, January 31, 2022 at 08:58
> *To: *"draft-ietf-bess-evpn-fast-df-recov...@ietf.org" <
> draft-ietf-bess-evpn-fast-df-recov...@ietf.org>, "bess@ietf.org" <
> bess@ietf.org>
> *Cc: *"bess-cha...@ietf.org" 
> *Subject: *WGLC, IPR and Implementation Poll for
> draft-ietf-bess-evpn-fast-df-recovery-03
> *Resent-From: *
> *Resent-To: *Patrice Brissette , ,
> , , Ali Sajassi <
> saja...@cisco.com>
> *Resent-Date: *Monday, January 31, 2022 at 08:58
>
>
>
> Hi WG,
>
>
>
> This email starts a two-week Working Group Last Call on 
> draft-ietf-bess-evpn-fast-df-recovery-03
> [1].
>
>
>
> This poll runs until Monday 14th February 2022.
>
>
>
> 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. The Document won't progress without answers from
> all the Authors and Contributors.
>
> There is currently no IPR disclosed.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> We are also polling for any existing implementation as per [2]. Please
> indicate if you are aware of any implementations.
>
>
>
> Thank you,
>
> Matthew & Stephane
>
>
>
> [1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF
> Election
> <https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
>
> [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
>
>
>
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Patrice Brissette (pbrisset)]

I support publication and am not aware of undisclosed IPR.

Implementation has been shipped on Cisco IOS-XR.
Regards,
Patrice Brissette, Principal Engineer
Cisco Systems

http://e-vpn.io
http://go2.cisco.com/evpn




From: "Bocci, Matthew (Nokia - GB)" 
Date: Monday, January 31, 2022 at 08:58
To: "draft-ietf-bess-evpn-fast-df-recov...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Resent-From: 
Resent-To: Patrice Brissette , , 
, , Ali Sajassi 
Resent-Date: Monday, January 31, 2022 at 08:58

Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Luc André Burdet]

I support publication and am not aware of undisclosed IPR
Cisco IOS-XR has implemented the procedures in this draft

Regards,
Luc André

Luc André Burdet |  Cisco  |  laburdet.i...@gmail.com  |  Tel: +1 613 254 4814


From: BESS  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, February 1, 2022 at 10:13
To: "Bocci, Matthew (Nokia - GB)" , 
"draft-ietf-bess-evpn-fast-df-recov...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: Re: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03

I’ve reread the draft and support publication.
Thanks,
Acee

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, January 31, 2022 at 9:00 AM
To: "draft-ietf-bess-evpn-fast-df-recov...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03

Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Rabadan, Jorge (Nokia - US/Sunnyvale)]

Hi everyone,

I’m not aware of any relevant undisclosed IPR.

Thanks.
Jorge

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, January 31, 2022 at 2:58 PM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Mankamana Mishra (mankamis)]

Support the publication of draft.

Mankamana

From: Bocci, Matthew (Nokia - GB) 
Date: Monday, January 31, 2022 at 5:58 AM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Cc: bess-cha...@ietf.org 
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Acee Lindem (acee)]

I’ve reread the draft and support publication.
Thanks,
Acee

From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Monday, January 31, 2022 at 9:00 AM
To: "draft-ietf-bess-evpn-fast-df-recov...@ietf.org" 
, "bess@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03

Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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

Re: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[John E Drake]

Support and not aware of any IPR

Yours Irrespectively,

John



Juniper Business Use Only
From: Bocci, Matthew (Nokia - GB) 
Sent: Monday, January 31, 2022 8:58 AM
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: WGLC, IPR and Implementation Poll for 
draft-ietf-bess-evpn-fast-df-recovery-03

[External Email. Be cautious of content]

Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/__;!!NEt6yMaO-gk!RDo1jBQ_9TVQufIGl4q2LkZntpl8u_71IcEWLppGsI3bAeWWBMjbrVzjCZDGiWk$>
[2] 
https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!!NEt6yMaO-gk!RDo1jBQ_9TVQufIGl4q2LkZntpl8u_71IcEWLppGsI3bAeWWBMjbrVzjRJ6-XX8$>


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

[bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

[Bocci, Matthew (Nokia - GB)]

Hi WG,

This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-fast-df-recovery-03 [1].

This poll runs until Monday 14th February 2022.

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. The Document won't progress without answers from all the 
Authors and Contributors.
There is currently no IPR disclosed.

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

We are also polling for any existing implementation as per [2]. Please indicate 
if you are aware of any implementations.

Thank you,
Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF 
Election
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw


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