Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-pref-df-09
Hi Stewart, Thanks for reviewing. Changes are incorporated in version 10 that we just published. Please see my comments in-line with [jorge]. Thx Jorge From: Stewart Bryant via Datatracker Date: Tuesday, August 30, 2022 at 12:41 PM To: rtg-...@ietf.org Cc: bess@ietf.org , draft-ietf-bess-evpn-pref-df@ietf.org , last-c...@ietf.org Subject: Rtgdir last call review of draft-ietf-bess-evpn-pref-df-09 Reviewer: Stewart Bryant Review result: Has Issues I am entering these last call comments as part of the Routing Area review process. I regret that it isthis text is not yet ready to proceed to the next stage of the IETF Review Process. I think that editorial work is needed to clarify the document for the reader. One particular comment is that the authors tend to describe behaviour in terms of bit values and not in terms of bit semantics or bit name when describing the operation of the protocol. In general, people tend to think and code in terms of names rather than 1s and 0s. Detailed comments below === BESS Workgroup J. Rabadan, Ed. Internet-Draft S. Sathappan Intended status: Standards Track Nokia Expires: 7 January 2023T. Przygienda W. Lin J. Drake Juniper Networks A. Sajassi S. Mohanty Cisco Systems 6 July 2022 SB> There are too many front page authors. [jorge] version 10 has moved two authors to the contributors section. 1.1. Problem Statement While the Default DF Alg [RFC7432] or HRW [RFC8584] provide an efficient and automated way of selecting the DF across different Ethernet Tags in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes a new DF Alg and capability to address the above needs. SB> As far as I can see you propose two algorithms and I cannot see in the above how you map each algorithm to a particular set of sub-use-cases. [jorge] I replaced the last sentence with: “This document proposes two new DF Algs (Highest-Preference and Lowest-Preference) which provide the deterministic Designated Forwarder method required, as well as the "Don't Preempt" capability to address the need to control whether a PE can take over an existing Designated Forwarder PE.” === 1.2. Solution requirements d. The solution allows an option to NOT preempt the current DF, even if the former DF PE comes back up after a failure. This is also known as "non-revertive" behavior, as opposed to the [RFC7432] DF election procedures that are always revertive. SB> It is useful to say why. SB> Again in this section the two algorithms need to map to use cases. [jorge] the section has been changed accordingly. == 2. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. SB> Nits does not like the above boilerplate. I would be helpful to other reviewers to address so they do not have to investigate the warning. [jorge] it is fixed now, thanks. === * DF Alg or simply Alg - refers to Designated Forwarder Election Algorithm. SB> “simply Alg” is confusing since it is not clear if simply is part of the name. How about * DF Alg - refers to Designated Forwarder Election Algorithm. This is sometimes shortened to “Alg” in this document. Alternatively consider always using the term DF Alg, or if you want to save space use something like DFA in the text. [jorge] I took your text, thx == 3. EVPN BGP Attributes Extensions This solution reuses and extends the DF Election Extended Community defined in [RFC8584] that is advertised along with the ES route: SB> I think you need some text of the form: by replacing the last two reserved octets of the DF EEC when the DF Alg is se
[bess] Rtgdir last call review of draft-ietf-bess-evpn-pref-df-09
Reviewer: Stewart Bryant Review result: Has Issues I am entering these last call comments as part of the Routing Area review process. I regret that it isthis text is not yet ready to proceed to the next stage of the IETF Review Process. I think that editorial work is needed to clarify the document for the reader. One particular comment is that the authors tend to describe behaviour in terms of bit values and not in terms of bit semantics or bit name when describing the operation of the protocol. In general, people tend to think and code in terms of names rather than 1s and 0s. Detailed comments below === BESS Workgroup J. Rabadan, Ed. Internet-Draft S. Sathappan Intended status: Standards Track Nokia Expires: 7 January 2023T. Przygienda W. Lin J. Drake Juniper Networks A. Sajassi S. Mohanty Cisco Systems 6 July 2022 SB> There are too many front page authors. 1.1. Problem Statement While the Default DF Alg [RFC7432] or HRW [RFC8584] provide an efficient and automated way of selecting the DF across different Ethernet Tags in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes a new DF Alg and capability to address the above needs. SB> As far as I can see you propose two algorithms and I cannot see in the above how you map each algorithm to a particular set of sub-use-cases. === 1.2. Solution requirements d. The solution allows an option to NOT preempt the current DF, even if the former DF PE comes back up after a failure. This is also known as "non-revertive" behavior, as opposed to the [RFC7432] DF election procedures that are always revertive. SB> It is useful to say why. SB> Again in this section the two algorithms need to map to use cases. == 2. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. SB> Nits does not like the above boilerplate. I would be helpful to other reviewers to address so they do not have to investigate the warning. === * DF Alg or simply Alg - refers to Designated Forwarder Election Algorithm. SB> “simply Alg” is confusing since it is not clear if simply is part of the name. How about * DF Alg - refers to Designated Forwarder Election Algorithm. This is sometimes shortened to “Alg” in this document. Alternatively consider always using the term DF Alg, or if you want to save space use something like DFA in the text. == 3. EVPN BGP Attributes Extensions This solution reuses and extends the DF Election Extended Community defined in [RFC8584] that is advertised along with the ES route: SB> I think you need some text of the form: by replacing the last two reserved octets of the DF EEC when the DF Alg is set to Alg TBD. SB> RFC8584 does not specify the value of the the reserved fields, and how they are to be processed. All the notation RSV/Reserved is unclear if this concerns just bits 16..18 or bits 16..18 and bits 40..63. Perhaps you need to use this text to update RFC 8584. == 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|A| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Bitmap field in the DF Election Extended Community SB> Where is the semantics of Bit 0 defined for Alg 2? * Bit 0 (corresponds to Bit 24 of the DF Election Extended Community and it is defined by this document): D bit or 'Don't Preempt' bit (DP hereafter), determines if the PE advertising the ES route requests the remote PEs in the ES not to preempt it as DF. The default value is DP=0, which is compatible with the 'preempt' or 'revertive' behavior in the Default DF Alg [RFC7432]. The DP capability is supported by Alg 2 and Alg TBD, and MAY be
