On Sun, May 7, 2017, 7:35 PM Robert Raszuk <[email protected]> wrote:
> Hi Warren, > > In the draft you have reviewed EVPN term is use interchangeably with term > [RFC7432] which in turn is also already listed and defined in the Normative > References section (2nd from the top). > Yes, and I read RFC7432 when I first reviewed this document - but I only knew that was the one to read after grepping though RFCs for "EVPN" -- is there any reason for the authirs *not* to make things easier for your readers by saying: " This document describes how EVPN [RFC7432] can be ..."? > Personally if you assume that the reader of this document is not familiar > with EVPN I would also recommend to read few other L2 VPN related documents > as prerequisite before jumping to this one: > > - RFC 7209 and all VPN related documents included in its references > > - RFC 7432 and all VPN related documents included in its references > > - all VPN related documents included in references of > draft-ietf-bess-evpn-vpws > That sounds like a fine idea - perhaps the authors should add something like "Readers of this document are expected to be familiar with RFC7209 and RFC7432." Mainly I don't understand why we wouldn't want to make it easier for someone new to the technology... W > - only then the draft in question itself. > > Kind regards, > Robert. > > > On Sun, May 7, 2017 at 7:05 PM, Warren Kumari <[email protected]> wrote: > >> Warren Kumari has entered the following ballot position for >> draft-ietf-bess-evpn-vpws-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-vpws/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> [ For -11 / -12 ] >> This document is very heavy on the acronyms, and could do with some >> expanding of these -- for example, the document starts out with "This >> document describes how EVPN can be used...". I'm no MPLS VPN person, so >> much time was spent searching to try figure out what everything meant. >> >> I also agree with Spencer's "In multihoming scenarios, both B and P flags >> MUST NOT be both set. " being hard to parse, and disagree with Acee that >> is it clear. >> >> [ For -13 ] >> The draft was revised to address Alia's DISCUSS, and also Spencer's >> "traditional way" and "both B and P flags MUST NOT be both set" comment, >> but still does not expand EVPN; I also agree with Spencer that it would >> be helpful to expand P2P on first use. I reread the document and have >> some additional comments - note that these are are only comments, but I >> think that they would make the document more readable... >> >> 1: Introduction: >> "that in EVPN terminology would mean a single pair of Ethernet Segments >> ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing >> failure and 'Ethernet Segments (ES)' was intended? If not, >> >> You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick >> with one. >> >> 1.1: Terminology: >> "EVI: EVPN Instance." -- Ok, but EVPN is still not defined / >> referenced. >> >> 3.1 EVPN Layer 2 attributes extended community >> " A PE that receives an update with both B and P flags set MUST treat >> the >> route as a withdrawal. If the PE receives a route with both B and P >> clear, it MUST treat the route as a withdrawal from the sender PE." >> Do the above 2 sentences say the same thing? It sure sounds like >> repetition, if not, please explain the difference. If not, removing one >> would make this less confusing. >> >> Figure 3: EVPN-VPWS Deployment Model >> You use the terms / labels "PSN1", "PSN2" - what are these? "Provider >> <something> Network"? >> >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess >> > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
