Last Call Review of draft-ietf-opsawg-l2nm-10
review-ietf-opsawg-l2nm-10-rtgdir-lc-shah-2021-11-14-00

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