Skip to main content

Framework for Ethernet VPN Designated Forwarder Election Extensibility


(Martin Vigoureux)

No Objection

(Ben Campbell)
(Spencer Dawkins)

Note: This ballot was opened for revision 07 and is now closed.

Alvaro Retana No Objection

Comment (2019-01-08 for -07)
(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...

Warren Kumari No Objection

Comment (2019-01-09 for -07)
Thanks to Benjamin for the thorough review - he covered many of the items I was going to ask.

Unfortunately this leaves me with only nits to contribute:
"The default algorithm for DF election defined by [RFC7432] at the granularity of (ESI,EVI) ..." - EVI is not expanded on first use (and it would be easier for the reader than having to go read 7432 just to expand an acronym).

"Note that while [RFC7432] elects a DF per <ES, EVI>, this document elects a DF per <ES, BD>." -- same.

Just as an edit: I noticed that the Shepherd writeup mentioned that one of the contributors hasn't ACKed the IPR question - not sure if that is still the case.

(Martin Vigoureux; former steering group member) Yes

Yes (for -07)


(Adam Roach; former steering group member) No Objection

No Objection (2019-01-09 for -07)
I have one minor comment that the authors may wish to consider.


>  It is well-known that for good
>  hash distribution using the modulus operation, the modulus N should
>  be a prime-number not too close to a power of 2 [CLRS2009].

I suppose this refers to the explanation in [CLRS2009] §11.3.1. The
description there is pretty hand-wavy and not completely accurate except under
certain (admittedly common) conditions -- in which this case is not included.
You may wish to consider instead citing "The Art of Computer Programming (Vol.
3)" by Knuth, as it captures a lot more of the nuance behind why this rule of
thumb is frequently true, and covers the general case. There is probably a set
of considerations to take into account for Ethernet Tags with an even
distribution, but only because you have a relatively small set of potential
inputs -- not for any of the reasons cited in [CLRS2009]. Quoting Knuth:

  In general, we want to avoid values of M that divide r^k+a or r^k−a, where k
  and a are small numbers and r is the radix of the alphabetic character set
  (usually r=64, 256 or 100), since a remainder modulo such a value of M tends
  to be largely a simple superposition of key digits. Such considerations
  suggest that we choose M to be a prime number such that r^k!=a(modulo)M or
  r^k!=−a(modulo)M for small k & a.

I see that Benjamin has made a related comment. I share his objection to
the way point #2 is phrased, and think it needs to be reworded to properly
capture the subtleties implied by the preceding passage.

(Alexey Melnikov; former steering group member) No Objection

No Objection (2019-01-09 for -07)
1.2.2. Traffic Black-Holing on Individual AC Failures

   As discussed in section 2.1 the Default DF Election algorithm defined
   by [RFC7432] takes into account only two variables in the modulus
   function for a given ES: the existence of the PE's IP address on the
   candidate list and the locally provisioned Ethernet Tags.

This document doesn't have section 2.1.

1.3. The Need for Extending the Default DF Election in EVPN

   Section 2.2 describes some of the issues that exist in the Default DF
   Election procedures. In order to address those issues, this document

This document doesn't have section 2.2 either.

(Alissa Cooper; former steering group member) No Objection

No Objection (2019-01-09 for -07)
I know there has already been a bunch of discussion about whether this document should formally update RFC 7432. I wanted to ask specifically about Section 3.1. I may be completely misunderstanding this since I did not give RFC 7432 a thorough read, but it appears as though Section 3.1 specifically articulates details applicable to RFC 7432 (independent of what this draft specifies in 3.2 and later sections) that were not included in that RFC. That seems like it warrants the "Updates" relationship, because then people reading RFC 7432 in the future will know to look at this document for updates, and can at least find the FSM and its description there. There is not consensus about what "Updates" means (as evidenced by recent discussion instigated by the IESG [1]) and I don't think this is worth dying on a hill over, just wanted to raise that specifically in case people hadn't considered it.

The introduction of this document is unusually long (more than a third of the substantive content of the document). You might consider having 1.1 start a new section rather than having 1.1, 1.2, and 1.3 be subsections of the introduction.


(Ben Campbell; former steering group member) No Objection

No Objection (for -07)


(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2019-01-24)
Thank you for resolving my DISCUSS (and COMMENT) points!

(Deborah Brungard; former steering group member) No Objection

No Objection (2019-01-09 for -07)
I can be swayed either way on the update discussion. I usually prefer to be
conservative with using "update" so the reader of the original RFC does not
have to parse many updates to understand what is applicable when
implementing the original RFC. While others view it as applying to the
new RFC and its relationship with the original. What's important (to me)
is to clearly describe the update in the abstract for the reader to decide
to read or not.

(Ignas Bagdonas; former steering group member) No Objection

No Objection (2019-01-10 for -07)
Thank you for the document - it addresses the real deployment problems encountered in the field.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2019-01-10 for -07)
First one minor editorial comment:
Sec 3.2 "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]."
I believe you meant a single advertisement is received without the configured DF Alg and capability (or a different one I guess), and not that the advertisement is not received at all (because that might be hard to check), right? Maybe you can rephrase this sentence a bit to make the intention more clear!

However, think about this further, I wondering if there is something here that such be discussed in the security considerations, e.g. how easy would it be for an attacker to disturb the algo selection and cause a fallback to the default scheme...?

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -07)


(Suresh Krishnan; former steering group member) No Objection

No Objection (2019-01-09 for -07)
Given the drawbacks this document mentions regarding the default DF election algorithm defined in RFC7432, I also think it would be better for this document to update RFC7432 so that implementers are aware that there are better alternatives out there.

* Section 3.2:

Who actually advertises Type 0 in the DF Alg field given that the legacy RFC7432 implementations do not use this extended community at all?