Last Call Review of draft-ietf-bess-evpn-df-election-framework-06
review-ietf-bess-evpn-df-election-framework-06-secdir-lc-housley-2018-12-08-00

Request Review of draft-ietf-bess-evpn-df-election-framework
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-12-18
Requested 2018-12-04
Authors Jorge Rabadan, satyamoh@cisco.com, Ali Sajassi, John Drake, Kiran Nagaraj, Senthil Sathappan
Draft last updated 2018-12-08
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 Russ Housley
State Completed
Review review-ietf-bess-evpn-df-election-framework-06-secdir-lc-housley-2018-12-08
Reviewed rev. 06 (document currently at 09)
Review result Has Nits
Review completed: 2018-12-08

Review
review-ietf-bess-evpn-df-election-framework-06-secdir-lc-housley-2018-12-08

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-bess-evpn-df-election-framework-06
Reviewer: Russ Housley
Review Date: 2018-12-09
IETF LC End Date: 2018-12-18
IESG Telechat date: unknown

Summary: Has Nits


Major Concerns: None


Minor Concerns:

Please spell out EVPN on first use.  I suspect that "Ethernet VPN" is
good enough since "VPN" is quite well known.

The Abstract seems to be overly complete, so it reads more like an
Introduction.  I suggest someting like:

   An alternative to the default Designated Forwarder (DF) selection
   algorithm in Ethernet VPN (EVPN) networks is defined. The DF is the
   Provider Edge (PE) router responsible for sending broadcast, unknown
   unicast and multicast (BUM) traffic to multi-homed Customer Equipment
   (CE) on a particular Ethernet Segment (ES) within a VLAN. In addition,
   the capability to influence the DF election result for a VLAN based
   on the state of the associated Attachment Circuit (AC) is specified.

I suggest that the original Abstract text become Section 2.

Section 3 says:

   ...  In addition, since the specification in EVPN
   [RFC7432] does leave several questions open as to the precise final
   state machine behavior of the DF election, section 3.1 describes
   precisely the intended behavior.

This seems like an update to RFC 7432.  If that is the intent, please
update the Introduction and the Title Page Heading to say so.


Nits:

Section 2.2.1:  s/multi homed/multi-homed/

Section 4:  s/the state of the server states/the server states./