Framework for Ethernet VPN Designated Forwarder Election Extensibility
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana No Objection
(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
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
(Adam Roach; former steering group member) No Objection
I have one minor comment that the authors may wish to consider. §1.2.1: > 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
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
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 ) 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.  https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE
(Ben Campbell; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thank you for resolving my DISCUSS (and COMMENT) points!
(Deborah Brungard; former steering group member) No Objection
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
Thank you for the document - it addresses the real deployment problems encountered in the field.
(Mirja Kühlewind; former steering group member) No Objection
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
(Suresh Krishnan; former steering group member) No Objection
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?