Alvaro, Thank you very much for reviewing. Please see in-line to see the resolution of your comments, with [JORGE].
Thx Jorge -----Original Message----- From: Alvaro Retana <aretana.i...@gmail.com> Date: Tuesday, January 8, 2019 at 9:51 PM To: The IESG <i...@ietf.org> Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" <draft-ietf-bess-evpn-df-election-framew...@ietf.org>, Stephane Litkowski <stephane.litkow...@orange.com>, "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "firstname.lastname@example.org" <email@example.com> Subject: Alvaro Retana's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT) Resent-From: <alias-boun...@ietf.org> Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>, <saja...@cisco.com>, <jdr...@juniper.net>, <kiran.naga...@nokia.com>, <senthil.sathap...@nokia.com> Resent-Date: Tuesday, January 8, 2019 at 9:50 PM Alvaro Retana has entered the following ballot position for draft-ietf-bess-evpn-df-election-framework-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (0) Some of my comments are related to Benjamin's DISCUSS. [JORGE] we are fixing all the issues raised by Benjamin. We'll reply in a separate email. (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. [JORGE] sounds good. We'll "update 7432" in the next revision and will indicate why. (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]. [JORGE] ok, changed to "may" instead of "MAY". (3) "Only one DF Election Extended Community can be sent..." What should a receiver do if more than one community is received? [JORGE] we modified this sub-bullet in the same section / next bullet, hopefully it clarifies: "- The absence of the DF Election Extended Community or the presence of multiple DF Election Extended Communities (in the same route) MUST be interpreted by a receiving PE as an indication of the Default DF Election algorithm on the sending PE, that is, DF Alg 0 and no DF Election capabilities." (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. [JORGE] ok, that's fair. Description changed to: "o RSV / Reserved - Reserved bits for DF Alg specific information." (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? [JORGE] the use of the reserved bits for any future DF Alg is optional, so, a MAY should be fine? I changed the text to: "- 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. In particular, for DF Algs 0 and 1, the reserved bits are not set by the advertising PE and SHOULD be ignored by the receiving PE." (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? [JORGE] If the advertised ext community is not consistent across all the PEs in the Ethernet Segment, the DF Alg falls back to the default DF Alg. This is added in this section and also in the security section. Besides these two bullets have been modified for clarity and completeness. Let us know if you are not ok with it. "- Otherwise if even a single advertisement for the type-4 route is received without the locally configured DF Alg and capability, the Default DF Election algorithm (modulus) algorithm MUST be used as in [RFC7432]. This procedure handles the case where participating PEs in the ES disagree about the DF algorithm and capability to apply. - The absence of the DF Election Extended Community or the presence of multiple DF Election Extended Communities (in the same route) MUST be interpreted by a receiving PE as an indication of the Default DF Election algorithm on the sending PE, that is, DF Alg 0 and no DF Election capabilities." (6) The HRW1999 reference must be Normative. [JORGE] please check out the discussion with Adrian and Satya related to this, where Adrian recommended to move it to informative references. https://www.ietf.org/mail-archive/web/bess/current/msg03740.html (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... [JORGE] fixed, thanks. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess