[RTG-DIR] rtgdir Last Call Review of draft-ietf-opsawg-l2nm-10

["Shah, Himanshu" <[e-mail]>]

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<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