Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsawg-l2nm-10.txt Reviewer: Himanshu Shah Review Date: 11/11/2021 IETF LC End Date: not known Intended Status: Standards Track Summary: Firstly, the review request was made for revision -06- of this document, but the latest revision is -10-. So I took the liberty to review the latest version. The document is quite comprehensive with lots of details. I was able to consult with some of the colleagues within my company to get network management perspective. The review comments reflect the experiences of participants in this field. I believe this would be more helpful to the authors. The document is good candidate for publication, but the comments provided should be considered and addressed before the publication. Comments: Note that I am not following the provided guidelines on the issue categories (Like major/minor). I leave that upto AD and/or authors on what level of attention they would like to provide. Overall: - Resiliency/Protection aspects of the requirements/modelling need more elaboration from the access/core/service perspective. o For example – PW protection - Topology types may need more clarity on what is the desired end result. o For example – Custom or Tree topologies – what are the forwarding rules at the VPN access points. o Is hierarchical VPLS (H-VPLS) a consideration and how is it expressed in the model? - PW characteristics should be more abstract – seems more detailed in the document while still not covering o Protected? o MS-PW? - Service Status need more elaboration. Our experience has been challenging in this area and desire more details on its usage/semantics (e2e service, vpn-node, vpn-access, etc). Specifics (using -10- draft) (Do note this is best effort comments – document is too long and not entire document is scanned with fine toothcomb) – (page 14 – last but one paragraph) 'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) profile refers to a set of BFD [RFC5880] policies that can be invoked when building a VPN service. Himanshu> Should this be a OAM-profile to accommodate OAM other than BFD? For instance, 802.1ag, Y.1731, etc. (page 17 – last para) 'vpn-service-topology': Indicates the network topology for the service: hub-spoke, any-to-any, or custom. Himanshu> What about H-VPLS? Does that type of construct fall in to "custom" Himanshu> In Custom topology, how are forwarding rules specified?? Himanshu> What about resiliency, for example, primary/backup PW (page 18) l2tp-signaling': The L2NM uses L2TP-signaled Pseudowires as described in [RFC6074]. Himanshu> What about static PWs? Multi-segment PWs? (page 18) 'underlay-transport': Describes the preference for the transport technology to carry the traffic of the VPN service. This preference is especially useful in networks with multiple domains and Network-to-Network Interface (NNI) types. The underlay transport can be expressed as an abstract transport instance (e.g., an identifier of a VPN+ instance, a virtual network identifier, or a network slice name) or as an ordered list of the actual protocols to be enabled in the network. A rich set of protocol identifiers that can be used to refer to an underlay transport (or how such an underlay is set up) are defined in [I-D.ietf-opsawg-vpn-common]. Himanshu> Not clear how ordered list of transport work for VPN Spanning multiple domain and how it is pinned for each domain.. (page 23) 'protection-type': It defines the protection type Himanshu> Not sure what protection-type means for MAC-loop-prevention (page 33) The VPN network access is comprised of: 'id': Includes an identifier of the VPN network access. Himanshu> Should there be a "name" field as well - keeping with same pattern of identification (id, name, description) (page 33) 'port-id': Indicates the port on which the VPN network access is bound. Himanshu> Text above says - interface-id and not port-id. Irrespective, does interface-id refer to or include "attachment-circuit" (page 34) 'status': Indicates the administrative and operational status of the service. Himanshu> Perhaps refers to status of the access-point and not global VPN service, right? Thanks, Himanshu