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

From: John E Drake <[email-masked]>
Date: Tue, 1 Feb 2022 14:51:57 +0000

Support and not aware of any IPR

Yours Irrespectively,

John

Juniper Business Use Only
From: Bocci, Matthew (Nokia - GB) <[email-masked]>
Sent: Monday, January 31, 2022 8:58 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
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$>

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 1 Feb 2022 15:35:40 +0000

Support the publication of draft.

Mankamana

From: Bocci, Matthew (Nokia - GB) <[email-masked]>
Date: Monday, January 31, 2022 at 5:58 AM
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03
Hi WG,

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

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Tue, 1 Feb 2022 16:02:01 +0000

Hi everyone,

I’m not aware of any relevant undisclosed IPR.

Thanks.
Jorge

Date: Monday, January 31, 2022 at 2:58 PM

Thank you,
Matthew & Stephane

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Tue, 1 Feb 2022 19:14:16 +0000

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)" <[email-masked]>
Date: Monday, January 31, 2022 at 08:58
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03
Resent-From: <[email-masked]>
Resent-To: Patrice Brissette <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Ali Sajassi <[email-masked]>
Resent-Date: Monday, January 31, 2022 at 08:58

Hi WG,

Thank you,
Matthew & Stephane

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 1 Feb 2022 20:39:05 -0500

I support publication.

Thanks

Gyan
On Tue, Feb 1, 2022 at 2:14 PM Patrice Brissette (pbrisset) <pbrisset=
[email-masked]> wrote:

> *http://e-vpn.io <http://e-vpn.io>*
>
> *http://go2.cisco.com/evpn <http://go2.cisco.com/evpn>*
>
>
>
>
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" <[email-masked]>
>
>
> *Date: *Monday, January 31, 2022 at 08:58
> *To: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *WGLC, IPR and Implementation Poll for
> draft-ietf-bess-evpn-fast-df-recovery-03
> *Resent-From: *<[email-masked]>
> *Resent-To: *Patrice Brissette <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>, Ali Sajassi <
> [email-masked]>
> *Resent-Date: *Monday, January 31, 2022 at 08:58
>
>
>
> Hi WG,
>
>
>
> 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.
>
> 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/>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 4 Feb 2022 09:50:07 -0800

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"?

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 4 Feb 2022 10:08:47 -0800

Yes/support

Cheers,

Jeff

From: Bocci, Matthew (Nokia - GB)
Sent: Monday, January 31, 2022 5:58 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [bess] WGLC, IPR and Implementation Poll for draft-ietf-bess-evpn-fast-df-recovery-03

Hi WG,

Thank you,

Matthew & Stephane

[1] draft-ietf-bess-evpn-fast-df-recovery-03 - Fast Recovery for EVPN DF Election