Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-l2nm-18: 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-opsawg-l2nm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of draft-ietf-opsawg-l2nm-18 CC @evyncke Thank you for the work put into this document. It solves a common and important issue while keeping backward compatibility. 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 Adrian Farrel for the shepherd's write-up including the WG consensus and the intended status. The use of IANA-maintained YANG modules looks attractive to me. I hope that this helps to improve the document, Regards, -éric ## COMMENTS ### Set of L2VPN technologies Just wondering how extensible this model is ? I.e., the L2 cross-connect of RFC 8986 is not included, any reason why ? How easy would it be to extend this model to also include RFC 8986 ? ### Section 2 ``` The corresponding YANG module can be used by a service orchestrator to request a VPN service to a network controller or to expose the list of active L2VPN services. ``` Does this mean that state information (e.g., counters) are not included ? Actually, sections 7.3 & 7.6.3 mention some status & OAM support so suggest adding status & OAM to the above text. ### Section 6 While I understand that "ethernet" is used in a broad concept (i.e., also covering Wi-Fi), I find the use of 'ethernet' a little restrictive as layer-2 VPN could exist in a near future with technologies that are not IEEE 802.3 based (e.g., some IoT networks or the good old frame relay). Alas, probably too late to change anything. ### Section 7.4 ``` 'svc-mtu': Is the service MTU for an L2VPN service (i.e., Layer 2 MTU including L2 frame header/tail). It is also known as the maximum transmission unit or maximum frame size. ``` Does it include CRC and/or preamble ? It would be nice also to mention the unit of this metric. Same question in the 'mtu' in section 7.6.4. ### Section 8.4 Missing "units" in "svc-mtu'. Is 300 msec a valid default aging timer for a MAC address ? This seems really short. ### Sections A.2 & A.3 Thanks for providing an IPv6 example ;-) ## NITS ### MAC is uppercase I noticed at least one occurence of 'mac' in lower case. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
