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

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 <laburdet.ietf@gmail.com>
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.ietf@gmail.com  |  Tel: +1 613 254
> 4814
>
>
>
>
>
> *From: *Anoop Ghanwani <anoop@alumni.duke.edu>
> *Date: *Friday, February 4, 2022 at 12:50
> *To: *Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>
> *Cc: *draft-ietf-bess-evpn-fast-df-recovery@ietf.org <
> draft-ietf-bess-evpn-fast-df-recovery@ietf.org>, bess@ietf.org <
> bess@ietf.org>, bess-chairs@ietf.org <bess-chairs@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) <
> 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
>
>