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 Routing Area Directorate (rtgdir)
Deadline 2018-12-18
Requested 2018-12-05
Requested by Martin Vigoureux
Draft last updated 2018-12-07
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 Adrian Farrel
State Completed
Review review-ietf-bess-evpn-df-election-framework-06-rtgdir-lc-farrel-2018-12-07
Reviewed rev. 06 (document currently at 09)
Review result Has Nits
Review completed: 2018-12-07


I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ? 
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. 

Document: draft-ietf-bess-evpn-df-election-framework-06.txt 
Reviewer: Adrian Farrel
Review Date: 2018-12-07
IETF LC End Date: 2018-12-18 
Intended Status: Standards Track 


This document is basically ready for publication, but has nits that should be considered prior to publication. 


This document addresses issues in the default election algorithm used for Designated Forwarder Election in EVPN (RFC 7432 and RFC 8124) by defining a new election algorithm and a capability to influence the election result for a VLAN, depending on the state of the associated Attachment Circuit.

This is an exceptionally clear and well written document. The authors and the working group are to be congratulated.

During my review I observed a number of small issues and editorial nits. I don't believe any of these is cause for discussion in the working group, but it would be sensible to resolve them before publication.

Thanks and Happy Christmas,
It's Christmas.
Buy someone you love a book of fairy tales.
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.


Major Issues:
 No major issues found


Minor Issues:

HRW1999 is provided as a normative reference, and from the text I can
see why. But no URL (stable or otherwise) is given for the reference.
Using my favorite search engine, I looked for and found a copy of
the referenced document on the IEEE site behind a paywall. I don't
think that will do at all. However, there is a version at
That appears to be dated 1998, but otherwise could be the same paper.


When I read in Section 3...

   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.

... I wondered whether this document is updating 7432 in that respect.

Other features later in the document (such as section 5) confirm this.


Notwithstanding the mention of backward compatiblity in section 6, I
think it would be a good idea to include a very short section 3.2.1.

3.2.1.  Backward Compatibility

   Legacy implementations (i.e., those that predate this specification)
   will not advertise the DF Election Extended Community.  That means
   that all other participating PEs will not receive DF preferences and
   will revert to the defailt algorithm without AC-Influenced DF

   Similarly, a legacy implementation receiving a DF Election Extended 
   Community will ignore it and will continue to use the default


On first reading, I missed an important subtlty in 3.2. The paragraph...

     - Otherwise 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 as in [RFC7432]. really important because it handles what to do if different 
participating PEs disagree about which algorithm to use.  Your text is
perfectly fine and adequate, but the "locally configured" sort of hid
it from me first time around.

Maybe add a sentence to the end of the bullet point to say...

"This procedure handles the case where participating PEs disagree about
the DF algorithm and capability to apply."


Section 4 introduces 8124 for the first time. It's good that this is
applicable to private wire EVPN as well as 7432 EVPN. Maybe bring this
into focus in the Introducion?

It does make me wonder whether you are also updating 8124.


I think section 7 is good. Since you note that the "unfair" situation
may be created maliciously, should you note that there is also scope for
a downgrade attach where the advertisement from one PE is hidden, the
preferred algorithm is modified to any unexpected value, or any 
unexpected bit in the capabilities bitfield is set? I think such an
attack assumes either a subversion of the PE (perhaps via its 
configuration) or modification of the BGP message. Thus, it is not a
probable if adequate existing security mechanisms are used.



The RFC Editor will require that the first section in the document is
the Introduction.


You use VNI and I-SID without expansion.




s/procedure Generally,/procedure.  Generally,/


3.2 has 

   For the DF election procedures to be consistent and unanimous, it is
   necessary that all the participating PEs agree on the DF Election
   algorithm and capabilities to be used.

This is exactly the type of statement I was hoping for when I opened the
document, so thanks. But... :-)

This depends slightly on the definition of "all participating PEs". You
don't need all PEs in the EVPN to use the same algorithm, only the PEs
that share multi-homing connections. 

You also use the term in 2.1 and other places in the document, so
perhaps I am worrying too much.


s/the state of the server states/the server states./
s/on Unix utilities rand and srand/on the Unix utilities rand and srand/


I am not sure why you describe Wrand2 in section 4.2 because you 
immediately decide to not use it. Maybe you can just describe Wrand and
observe that does the job?


   s/HRW solves the disadvantage/HRW solves the disadvantages/