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 <an...@alumni.duke.edu> Date: Friday, February 4, 2022 at 12:50 To: Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com> 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 <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) <matthew.bo...@nokia.com<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 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<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
