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 <[email protected]> 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 | [email protected] | Tel: +1 613 254 > 4814 > > > > > > *From: *Anoop Ghanwani <[email protected]> > *Date: *Friday, February 4, 2022 at 12:50 > *To: *Bocci, Matthew (Nokia - GB) <[email protected]> > *Cc: *[email protected] < > [email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]> > *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) < > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
