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 > <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 >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
