[bess] Adam Roach's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
Adam Roach 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: -- 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. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Adam Roach's No Objection on draft-ietf-bess-mvpn-expl-track-12: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-bess-mvpn-expl-track-12: 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-mvpn-expl-track/ -- COMMENT: -- Thanks for the work everyone did on this document. --- Please expand the following acronyms upon first use and in the abstract; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - MVPN - Multicast VPN - I-PMSI - ??? - P2MP - Point-to-Multipoint ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Adam Roach's No Objection on draft-ietf-bess-fat-pw-bgp-03: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-bess-fat-pw-bgp-03: 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-fat-pw-bgp/ -- COMMENT: -- Thanks for the work on this document. I have two very small editorial nits: > Abstract > > This draft defines protocol extensions required to synchronize flow > label states among PEs when using the BGP-based signaling procedures. Please expand "PE". §3: > A PE MAY support the configuration of the flow label (T and R bits) > on a per-service (e.g. VPLS VFI) basis. Please add a comma after "e.g." ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Adam Roach's No Objection on draft-ietf-bess-evpn-overlay-10: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-bess-evpn-overlay-10: 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-overlay/ -- COMMENT: -- Please expand the following acronyms upon first use; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - VXLAN - NVGRE - POD - GRE - Generic Routing Encapsulation - GENEVE - NV - ARP - Address Resolution Protocol - RR - Resource Record - ECMP - Equal-Cost Multipath - PIM-SM - Protocol Independent Multicast - PIM-SSM - BIDIR-PIM - IP-VRF - LSP - Label Switched Path - iBGP Also, please be consistent about capitalization of "ToR" versus "TOR", "VxLAN" versus "VXLAN", and "NvGRE" versus "NVGRE". ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Adam Roach's No Objection on draft-ietf-bess-evpn-etree-13: (with COMMENT)
On 10/27/17 6:06 PM, Ali Sajassi (sajassi) wrote: Ali> updated the section to make it more clear - please refer to rev14 of this draft. Thanks -- I'll take a look. When do you expect to upload the -14 version to the i-d repository? /a ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Adam Roach's No Objection on draft-ietf-bess-evpn-etree-13: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-bess-evpn-etree-13: 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-etree/ -- COMMENT: -- Section 3.3.2 says: The PEs implementing an E-Tree service need not perform MAC learning when the traffic flows between Root and Leaf sites are mainly multicast or broadcast. Does this mean to say "mainly"? I would have expected "only", as in section 4.3. In particular, if "mainly" is correct, I'm unsure how unicast traffic is supposed to be handled. Is it simply flooded out (modulo filters) in the same way as broadcast traffic? If that's the intention, I think some additional text here saying as much would be useful. Section 5.1: The reserved bits SHOULD be set to zero by the transmitter and SHOULD be ignored by the receiver. The "SHOULD" here seems that it might make assigning meaning to these bits in the future problematic. If implementations decide to either assign local meaning to these bits, or decide that they don't need to be initialized, then future IETF specs that try to use them might be in for some pretty nasty deployment surprises. If these need to be "SHOULD" instead of "MUST," please add some motivating text to the document for the sake of people who might want to extend the protocol in the future. The IANA handling of "Composite Tunnel" seems problematic: although several values in this "Reserved for Composite Tunnel" range have well-defined values (e.g., 0x81 means "RSVP-TE P2MP LSP with composite tunnel"), they look unallocated/reserved in the resulting table. I think what you really want to do here is update the introductory text for the table to make it clear that values now take the range 0x00 - 0x7F and modify 0x7B through 0x7F as you've proposed doing. On top of this, I have the same concerns as Warren does regarding the impact of this change on in-the-field use of experimental tunnel types. I think the only reasonable way to retrofit this mechanism onto the existing system would be to to say that the "Composite Tunnel" bit MUST be ignored for tunnel types 0x7B-0x7E, and possibly allocate some additional experimental codepoints (e.g., 0x77-0x7A) so that people can run experiments with tunnel types that also include composite tunnel behavior. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Adam Roach's Discuss on draft-ietf-bess-evpn-vpws-13: (with DISCUSS and COMMENT)
On 5/11/17 07:33, Alvaro Retana (aretana) wrote: On 5/11/17, 1:19 AM, "Adam Roach" <a...@nostrum.com> wrote: Adam: Hi! -- DISCUSS: -- Looking at the Shepherd write up and the Ballot, I see no mention of the normative reference to RFC 7348, which is informational and part of the Independent Submission stream. As I mention in my comments below, I can't fully follow the technical contents of this document, but this seems like a red flag to me and -- as far as I can tell -- it hasn't been discussed yet. It's possible that the reference just ended up in the wrong section (and should actually be informative), but it's not immediately obvious on a casual examination whether that's true. This document was originally scheduled for the Apr/27 Telechat, but as a result of Alia’s DISCUSS [1], the reference to rfc7348 was changed to Normative. The WG was cc’ed during the discussion, and I then reran the IETF LC with the downref explicitly mentioned [2]. I have no concerns about it. Yes, the Shepherd’s write-up should have been updated. Thanks for the clarification. I'm clearing my discuss. /a ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Adam Roach's Discuss on draft-ietf-bess-evpn-vpws-13: (with DISCUSS and COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-bess-evpn-vpws-13: Discuss 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-vpws/ -- DISCUSS: -- Looking at the Shepherd write up and the Ballot, I see no mention of the normative reference to RFC 7348, which is informational and part of the Independent Submission stream. As I mention in my comments below, I can't fully follow the technical contents of this document, but this seems like a red flag to me and -- as far as I can tell -- it hasn't been discussed yet. It's possible that the reference just ended up in the wrong section (and should actually be informative), but it's not immediately obvious on a casual examination whether that's true. -- COMMENT: -- I strongly second Mirja's comment requesting positive confirmation from the WG that is is collectively aware of the associated IPR declarations. >From https://www.rfc-editor.org/materials/abbrev.expansion.txt: > It is common in technical writing to abbreviate complex technical terms > by combining the first letters. The resulting abbreviations are often > called acronyms. Editorial guidelines for the RFC series generally > require expansion of these abbreviations on first occurrence in a > title, in an abstract, or in the body of the document. These guidelines go on to point out which acronyms are common enough not to require expansion on first use. The following acronyms are not considered common, and require expansion on first use *and* in the title (I'm being very careful to cite only those which are *not* expanded on first use, so each of these should be actionable): - VPWS - EVPN - P2P - MAC (which is, itself, ambiguous without an expansion on first use) - PE - CE - L2 - DF - iBGP - eBGP I don't think "encap" is a word. I have not made a complete effort to understand the technical aspects of this document as its acronym use is literally too thick for me to read and comprehend its contents. I presume it is readable to its community of interest (as three implementations already exist); but finding ways to write in prose instead of acronyms where possible would be highly welcome. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
