Here are my comments. ==
Procedural (Chairs can make a call on which of these must be addressed) - Draft is missing IANA considerations and security considerations sections.. - 6 front page authors may cause issues as the draft moves forward. - pg 8 >>> It is work in progress with authors of [BGP-LINK- BW] to allow for this attribute to be used as transitive in inter-AS scenarios. >>> Has this issue been resolved? It seems like it should be resolved one way or another before the draft is allowed to progress to RFC. Editorial - general Suggest adding a section for acronyms. Many are used and they are not all well known and some like BW have a new meaning in this draft. Link bundle, LAG bundle, LAG are all used interchangeably. Suggest use only LAG. Load balance, load-balance, load sharing, load-sharing used interchangeably. Suggest use "load balance" everywhere. What is the difference between EXT-COMM and extended community? Suggest use "extended community" everywhere. In the terminology section, "LOCAL" and "REMOTE" PE are defined, yet throughout the doc, a mix of LOCAL/local and REMOTE/remote are used. Suggest make consistent and use non-capitalized versions. These are well-understood terms. - pg 2 There are 2 section 3.1's. - pg 4 Missing period at end of 3rd bullet. - pg 5 In title for section 1.1, "PE CE" -> "PE-CE" "Consider a CE1" -> "Consider CE1" "link bundle represented" -> "the LAG represented" "it's bandwidth" -> "its bandwidth" "it MUST add a link" -> "it must add a link" (MUST should only be used for something this spec is mandating, not an observation.) - pg 6 "hosts MUST also be load-balanced" -> "hosts must also be load balanced" (there are 2 instances of this, one at the top of the page, one at the bottom) In title for section 1.2, "PE CE" -> "PE-CE" - pg 7 "with Lx being the number of links / bandwidth..." -> "with Lx being the total bandwidth across all links..." "Solution proposed..." -> "The solution proposed..." "who's overlay..." -> "whose overlay" -pg 8 "advertise a additional..." -> "advertise an additional..." -pg 10 "link-bandwidth" -> "link bandwidth" - pg 12 "compute a random hash..." -> "computes a random hash..." "IP address of PE at ordinal i" -> "IP address of PE(i)" "PE that has the highest hash..." -> "The PE that has the highest hash..." "one per-bandwidth..." -> "one per bandwidth..." - pg 14 "[WEIGHTED-HRW] document describes..." -> "[WEIGHTED-HRW] describes..." - pg 16 "PE_CE" -> "PE-CE" There appears to be a formatting issue with the 2nd bullet in section 6. Missing periods at the end of the first 3 bullets. - pg 17 Section 7 title "with non-EVPN routing" -> "With Non-EVPN Routing" Missing periods at end of bullets. On Fri, Feb 7, 2020 at 11:27 PM Anoop Ghanwani <an...@alumni.duke.edu> wrote: > I decided to look at the draft and will send my mostly editorial comments > in a day or so. Sorry for the delay. > > But what I find really surprising is that the draft made it through WGLC > without IANA considerations or security considerations sections. I thought > those were mandatory. I haven't been to an IETF meeting in a while. Has > something changed? > > Anoop > > On Tue, Feb 4, 2020 at 5:54 AM <slitkows.i...@gmail.com> wrote: > >> This poll is now closed without any objection to progress. >> >> However (expect if I have missed it), I haven’t heard about any >> implementation. >> >> >> >> Is there any known implementation ? If NO, is the WG against progressing >> the document without an implementation ? >> >> >> >> Feedback required by the end of the week. >> >> >> >> Thanks, >> >> >> >> >> >> >> >> *From:* slitkows.i...@gmail.com <slitkows.i...@gmail.com> >> *Sent:* vendredi 17 janvier 2020 09:56 >> *To:* bess@ietf.org; draft-ietf-bess-evpn-unequal-lb.auth...@ietf.org >> *Cc:* bess-cha...@ietf.org >> *Subject:* WGLC , IPR and implementation poll for >> draft-ietf-bess-evpn-unequal-lb-03 >> >> >> >> Hi WG, >> >> >> >> This email starts a two weeks Working Group Last Call on >> draft-ietf-bess-evpn-unequal-lb-03 >> [2] >> >> >> >> Please review the draft and send any comments to the BESS list. Also, >> please indicate if you support publishing the draft as a standards track >> RFC. >> >> >> >> This poll runs until Fri 31th January 2019. >> >> >> >> We are also polling for knowledge of any undisclosed IPR that applies to >> this Document, to ensure that IPR has been disclosed in compliance with >> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> If you are listed as an Author or a Contributor of this Document please >> respond to this email and indicate whether or not you are aware of any >> relevant undisclosed IPR. The Document won't progress without answers from >> all the Authors and Contributors. >> >> There is currently no IPR disclosed. >> >> We are also polling for any existing implementation as per [1]. Please >> indicate if you are aware of any implementations. >> >> Thank you, >> >> Stephane >> >> >> >> [1] >> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw >> >> [2] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-unequal-lb/ >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
