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 2023 T. 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 used with DF Alg 0 or 1. The procedures of the DP capability for DF Alg 0 or 1 are out of the scope of this document. SB>I am confused by the following text. SB> I think that you need to explain more clearly what behaviour is defined in RFC8584 and continues here, what behaviour has changed and what new behaviour is introduced. Also, where is Alg2 defined. * Bit 1: AC-DF or AC-Influenced DF Election, as explained in [RFC8584]. When set to 1, it indicates the desire to use AC- Influenced DF Election with the rest of the PEs in the ES. The AC-DF capability bit MAY be set along with the DP capability and DF Alg 2 or Alg TBD. - DF Preference (defined in this document): defines a 2-octet value that indicates the PE preference to become the DF in the ES. The allowed values are within the range 0-65535, and the default value MUST be 32767. This value is the midpoint in the allowed Preference range of values, which gives the operator the flexibility of choosing a significant number of values, above or below the default Preference. The DF Preference field is specific to DF Alg 2 and DF Alg TBD, and does not represent any Preference value for other Algs. If the DF Alg is different than Alg 2 or Alg TBD, these two octets can be encoded differently. SB> The last sentence is confusing and I think redundant. Those octets are defined for the case Alg2 and Alg TBD, but clearly the are not defined for anything that precedes this design and any future design is free to give them new semantics. SB> As far as I can see the text has not said whether 0 is more preferred than 65535 or the other way about. ============ a. vES1 and vES2 are now configurable with three optional parameters that are signaled in the DF Election extended community. These parameters are the Preference, Preemption option (or "Don't Preempt Me" option) and DF Alg. We will represent these parameters as (Pref,DP,Alg). Let's assume vES1 is configured as (500,0,Highest-Pref) in PE1, and (255,0,Highest-Pref) in PE2. SB> Where does the 0 come from in your notation? ======== c. According to [RFC8584], each PE will run the DF election algorithm upon expiration of the DF Wait timer. In this case, each PE runs the Highest-Preference DF Alg for each ES as follows: * The PE will check the DF Alg value in each ES route, and assuming all the ES routes are consistent in this DF Alg and the value is 2 (Highest-Preference), the PE will run the procedure in this section. Otherwise, the procedure will fall back to [RFC7432] Default Alg. SB> I think that it is confusing to use packet identifier values (2) rather than the name of the identifier value. =========== d. Assuming some maintenance tasks had to be executed on, E.g., PE3, the operator could set vES2's Preference to E.g., 50 so that PE2 is forced to take over as DF for vES2 (irrespective of the DP capability). Once the maintenance task on PE3 is over, the operator could decide to leave the existing preference or configure the old preference back. SB> On which PE does the advertisement change? e. In case of equal Preference in two or more PEs in the ES, the DP bit and the lowest IP of the candidate PEs are used as tie- breakers. SB> That is the lowest IP address I assume. That is easy on IPv4. Are there any issues with doing this in IPv6? After selecting the PEs with the highest Preference value, an implementation MUST first select the PE advertising the DP bit set, and then select the PE with the lowest IP address (if the DP bit selection does not yield a unique candidate). SB> Of perhaps more intuitively if more that one PE is advertising itself as the preferred forwarder. The PE's IP address is the address used in the candidate list and it is derived from the Originating Router's IP address of the ES route. Some examples of the use of the DP bit and IP address tie-breakers follow: * If vES1 parameters were (500,0,Highest-Pref) in PE1 and (500,1,Highest-Pref) in PE2, PE2 would be elected due to the DP bit. * If vES1 parameters were (500,0,Highest-Pref) in PE1 and (500,0,Highest-Pref) in PE2, PE1 would be elected, assuming SB> s/assuming/if/ SB> Although it might be better to describe both cases. PE1's IP address is lower than PE2's. f. The Preference is an administrative option that MUST be configured on a per-ES basis from the management plane, but MAY also be dynamically changed based on the use of local policies. SB> It is confusing to jump from the global statement above direct to a number example without explaining first what is happening. For instance, on PE1, ES1's Preference can be lowered from 500 to 100 in case the bandwidth on the ENNI port is decreased a 50% (that could happen if e.g. the 2-port LAG between PE1 and the Aggregation Network loses one port). Policies MAY also trigger dynamic Preference changes based on the PE's bandwidth availability in the core, specific ports going operationally down, etc. The definition of the actual local policies is out of scope of this document. The default Preference value is 32767. =========== 4.2. Use of the Lowest-Preference Algorithm In addition to the Highest-Preference Alg described in Section 4.1 this document defines the Lowest-Preference Alg. SB> I think that it would be clearer to describe the section algorithm as the generic selection algorithm rather than binding it to HP and then have this almost “dummy” section. In this case, and using the example of vES1 in Figure 3, if the Lowest-Preference Alg is configured in all the PEs in the ES, PE2 will be the DF due to its lower Preference. SB> I can see why you might have an HP choice, but you should explain use case for the lowest preference. Indeed since this text introduces both it would be useful to see text explaining why one is chosen over the other. =========== * In addition, assuming VLAN-based service interfaces and that the PEs are attached to all Ethernet Tags in the range 1-4000, both PE1 and PE2 will be configured with (Ethernet Tag-range,low), E.g., (2001-4000, low). SB> I think that this needs to be described in general terms first and then the case study included. ========== 4.4. The Non-Revertive Capability As discussed in Section 1.2 (d), a capability to NOT preempt the existing DF (for all the Ethernet Tags in the ES) is required and therefore added to the DF Election extended community. This option will allow a non-revertive behavior in the DF election. Note that, when a given PE in an ES is taken down for maintenance operations, before bringing it back, the Preference may be changed in order to provide a non-revertive behavior. SB> Doesn’t this result in long term instability/inconsistency in the network configuration if you change the value each time you do maintenance? ======== 1. A "Don't Preempt Me" capability is defined on a per-PE/per-ES basis, as described in Section 3. If "Don't Preempt Me" is disabled (default behavior), the advertised DP bit will be 0. SB> I feel that it is better to talk about bit states in terms of semantics rather than binary values like 0 and 1. If "Don't Preempt Me" is enabled, the ES route will be advertised with DP=1 ("Don't Preempt Me"). All the PEs in an ES SHOULD be consistent in their configuration of the DP capability, however this document does not enforce the consistency across all the PEs. In case of inconsistency in the support of the DP capability in the PEs of the same ES, non-revertive behavior is not guaranteed. However, PEs supporting this capability will still attempt this procedure. =========== 5. Security Considerations This document describes a DF Election Algorithm that provides absolute control (by configuration) over what PE is the DF for a given Ethernet Tag. While this control is desired in many situations, a malicious user that gets access to the configuration of a PE in the ES may change the behavior of the network. In other DF Algs such as HRW, the DF Election is more automated and cannot be determined by configuration. The non-revertive capability described in this document may be seen as a security improvement over the regular EVPN revertive DF Election: an intentional link (or node) "flapping" on a PE will only cause service disruption once, when the PE goes to NDF state. SB> What is NDF? The document also describes how a local policy can override the Highest-Preference Alg for a range of Ethernet Tags in the ES. If the local policy is not consistent across all PEs in the ES and there is an Ethernet Tag that ends up with an inconsistent use of Highest- Preference or Lowest-Preference in different PEs, black-holing or packet duplication may occur for that Ethernet Tag. SB> There may be some security considerations that need to be taken into account when you manipulate parameters in the middle of mainatance as is proposed in the text. ====== 6. IANA Considerations SB> It helps everyone if you specify the namespace (Border Gateway Protocol (BGP) Extended Communities) and then the registry and then set out your request just like it would appear in the registry itself: Bit Name Ref 2 Highest Preference This RFC Etc This document solicits the allocation of the following values: * DF Alg = 2 in the [RFC8584] "DF Alg" registry, with name "Highest- Preference Algorithm". * DF Alg = TBD in the same "DF Alg" registry, with name "Lowest- Preference Algorithm". * Bit 0 in the [RFC8584] DF Election Capabilities registry, with name "D (Don't Preempt) Capability" for Non-revertive ES. ========