[bess] Alvaro Retana's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-evpn-df-election-framework-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) Some of my comments are related to Benjamin's DISCUSS.

(1) The FSM in §3.1 applies to rfc7432, the introductory text (in that section)
says as much, and even the text in §1 calls it "a formal definition and
clarification".  I understand that the new procedures are not intended to
update rfc7432 (which is fine), but the fact that this document says that an
"implementation MUST comply with a behavior equivalent to the one outlined in
this FSM" seems like an Update to rfc7432 to me.  Note that the Update can, and
should, be qualified in the Abstract/Introduction, so you can explicitly
indicate what is being Updated and what isn't.

(2) The MAYs in this paragraph (§1.3) are not needed because they are used to
state a fact:

o HRW and AC-DF mechanisms are independent of each other. Therefore,
  a PE MAY support either HRW or AC-DF independently or MAY support
  both of them together. A PE MAY also support AC-DF capability along
  with the Default DF election algorithm per [RFC7432].

(3) "Only one DF Election Extended Community can be sent..."  What should a
receiver do if more than one community is received?

(4) §3.2 -- I'm confused about this text:

  - DF Algs 0 and 1 can be both used with bit AC-DF set to 0 or 1.

  - In general, a specific DF Alg MAY determine the use of the
    reserved bits in the Extended Community, which may be used in a
    different way for a different DF Alg.

(a) This text is assigning a function to the "reserved bits", so they are
really not reserved.  The description should be updated (from "Reserved bits
for future use") to reflect that their interpretation depends on the DF Alg.

(b) Form that text, what I get is that a new algorithm can define the meaning
of the bits.  Is that correct?  If so, (1) s/a specific DF Alg MAY determine
the use/a specific DF Alg MUST/SHOULD determine the use ...and... (2) for DF
Algs 0 and 1, what happens if any of the other bits are set?

(5) §3.2: "if even a single advertisement for the type-4 route is not received
with the locally configured DF Alg and capability, the Default DF Election
algorithm (modulus) algorithm MUST be used"  Given that the PEs advertise only
their preferred algorithm/capability, it is possible that it also supports
other algorithm/capability combinations, which may have been advertised.  I
assume that it is up to the implementation if they want to update their
advertisement.  Do you want to say anything about this?  Are there potential
downsides to an implementation changing their preferred combination?

(6) The HRW1999 reference must be Normative.

(7) [nit] There are a couple of references to other sections on this document
that don't exist: §1.2.2 points to section 2.1, §1.3 to 2.2...