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) <
matthew.bocci@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
> <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
>