Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-vpws-fxc-09: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle 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-fxc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-vpws-fxc-09 Thank you for the work put into this document. I found the document very difficult to read and understand, notably with long sentences and absence of graphics in the first sections. This may also be caused by my lack of BESS expertise of course, therefore I was unable to do a deep review of this I-D. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Stéphane Litkowski for the shepherd's write-up (including the justification for 6 authors and of the intended status). I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract Should "EVPN VPWS" be expanded ? Even if https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list lists them, it will make the reader task easier. Suggest to split the abstract in 3 paragraphs. ## Section 1 s/These service provider want the above functionality without scarifying any of the capabilities/These service provider*s* want the above functionality without *sacrificing* any of the capabilities/ ? s/This document presents a solution/This document specifies a solution/ ## Section 1.1 Why is there a difference between "Single-Active Redundancy Mode" and "All-Active Redundancy Mode" as the former allows for `When a device *or a network* is multi‑homed` ## Section 3 Generic comment on this section and its sub-section, the text is descriptive only and not really a complete specification, e.g., nothing is specified about things going wrong (section 5 is about failures though). Be more assertive in a PS, e.g., s/This section outlines a solution for providing/This section specifies how to provide/ Rather than leaving up to the reader to guess what is a "normalized VID", let's define it in the previous paragraph. Should there be a reference for `Ethernet tag` (e.g., IEEE 802.1Q or another RFC) ? A small graphic would also make the text easier to read. Any suggestion on how this can be achieved ? `Operators should be informed of potential trade-offs ` While the text specifies what is to be done at the ingress, it is silent about control plane (add a reference ?) and what the egress should do. ## Section 3.1 Should "ASBR" be expanded ? Or simply use the expansion as it is used only here. ## Section 3.2 Please expand "XConnect" somewhere. ## Section 3.3 `Provider Edge (PE)` the PE acronym has been used before and should not be expanded here. ## Section 4 It may be worth repeating the text of RFC 8214 about the 'reserved' field. ## Section 7 Is it worth adding the registry URI ? I.E., https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn-layer-2-attributes-control-flags # NITS (non-blocking / cosmetic) The use of the aasvg tool would make the HTML rendering of the figures much easier to read. _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
