Last Call Review of draft-ietf-bess-evpn-df-election-framework-06

Request Review of draft-ietf-bess-evpn-df-election-framework
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-12-18
Requested 2018-12-04
Draft last updated 2018-12-14
Completed reviews Rtgdir Last Call review of -06 by Adrian Farrel (diff)
Genart Last Call review of -06 by Francesca Palombini (diff)
Secdir Last Call review of -06 by Russ Housley (diff)
Genart Telechat review of -07 by Francesca Palombini (diff)
Assignment Reviewer Francesca Palombini
State Completed
Review review-ietf-bess-evpn-df-election-framework-06-genart-lc-palombini-2018-12-14
Reviewed rev. 06 (document currently at 09)
Review result Ready with Nits
Review completed: 2018-12-14


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-bess-evpn-df-election-framework-06
Reviewer: Francesca Palombini
Review Date: 2018-12-14
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.

Major issues: N/A

Minor issues:

I agree with the reviewers comments saying that this document should update RFC7432 and RFC8124. In particular, quoting RFC2232 (

   [...] A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.


      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

(Yes, RFC2232 is obsolete, but I could not find the same text in the more recent RFC7322)

Nits/editorial comments: 

  "but they do not require
   any changes to the EVPN Route exchange and have minimal changes to
   their content per se."

* what does their refer to?

* Section 2.2.2: expand MAC-VRF on first usage for readability (or add a reference to its definition)

* Figure 3: add a definition for ANY STATE (the figure is clear, but for consistency I would add that in the text as well)

* Figure 3: add "or" between VLAN_CHANGE, RCVD_ES, LOST_ES (again, not necessary, suggested for readability of the figure)

* Section 3.1: the term "re-entering" needs clarifying: I would consider a loop as re-entering the state, but from bullet 8. it seems like you don't.

* suggestion for figure 4 (otherwise it looks like there are 2 fields Bitmap of 1B each):

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     | Type=0x06     | Sub-Type(0x06)| RSV |  DF Alg |    Bitmap     ~
     ~               |            Reserved                           |

* Section 3.2: why was Bit 0 left unassigned in Bitmap?

* IANA considerations: I think you want to specify that the policy for Alg 31 is Experimental use (right now the text describing the policy only says "RFC required", with no distinction for different values).