[Last-Call] Rtgdir last call review of draft-ietf-bess-evpn-pref-df-09

[Stewart Bryant via Datatracker <[e-mail]>]

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 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

<snip>

   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

<snip>

   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.

========