Skip to main content

Telechat Review of draft-ietf-opsawg-l2nm-16
review-ietf-opsawg-l2nm-16-rtgdir-telechat-qu-2022-05-23-00

Request Review of draft-ietf-opsawg-l2nm
Requested revision No specific revision (document currently at 19)
Type Telechat Review
Team Routing Area Directorate (rtgdir)
Deadline 2022-05-23
Requested 2022-05-09
Requested by Alvaro Retana
Authors Mohamed Boucadair , Oscar Gonzalez de Dios , Samier Barguil , Luis Angel Munoz
I-D last updated 2022-05-23
Completed reviews Rtgdir Early review of -01 by Yingzhen Qu (diff)
Secdir Last Call review of -07 by Chris M. Lonvick (diff)
Rtgdir Last Call review of -10 by Himanshu C. Shah (diff)
Yangdoctors Last Call review of -07 by Ladislav Lhotka (diff)
Genart Last Call review of -15 by Dale R. Worley (diff)
Secdir Last Call review of -15 by Chris M. Lonvick (diff)
Rtgdir Telechat review of -16 by Yingzhen Qu (diff)
Assignment Reviewer Yingzhen Qu
State Completed
Request Telechat review on draft-ietf-opsawg-l2nm by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/ekcwKSlBpWJ4NaCaiNVwbqKyQFo
Reviewed revision 16 (document currently at 19)
Result Has nits
Completed 2022-05-23
review-ietf-opsawg-l2nm-16-rtgdir-telechat-qu-2022-05-23-00

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-16
Reviewer: Yingzhen Qu
Review Date: 05/23/2022
IETF LC End Date: unknown
Intended Status: Standards Track

Summary:
Thanks to the authors for working on this document. I think it's almost ready
for publication. There is one error in the appendix A.2 example that should be
fixed before publication, and there are a few minor issues/nits that may be
considered before publication.

Major Issues:

Appendix A.2:
libyang[0]: Node "ldp-pw-type" not found as a child of "ldp-or-l2tp" node.
(path: Schema location
/ietf-l2vpn-ntw:l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/signaling-option/signaling-option/ldp-or-l2tp/ldp-or-l2tp,
data location /ietf-l2vpn-ntw:ldp-or-l2tp, line number 61.) This should
"t-ldp-pw-type".

General Comment:
A lot of descriptions about nodes exported from RFC9181 in section 7 are
redundant from RFC9181.

Minor Issues and Nits (line numbers are from idnits):

397        Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps"
398        (Section 8.1) and "iana-pseudowire-types" (Section 8.2) to identify a
399        Layer 2 encapsulation type.

[nits]: encapsulation type and pseudowire type.

409        view of the L2VPN service.  Such a view is only visible within the
410        service provider and is not exposed outside (to customers, for
411        example).

[nits]: Visible within/visible to

500        'name':  Sets a name to uniquely identify an ES within a service
501           provider network.  This name is referenced in the VPN network
502           access level of the L2NM (Section 7.6).

[major]: I don't see where the "name" is referenced.

577        The 'vpn-profiles' container is used by the provider to maintain a
578        set of common VPN profiles that apply to VPN services (Section 7.2).

[nits]: to be consistent with section 7.2: to maintain/to define and maintain

629        This document does not make any assumption about the exact definition
630        of these profiles.  The exact definition of the profiles is local to
631        each VPN service provider.

[nits]: These two sentences should be rewritten to be concise.

2785             leaf name {
2786               type string;
2787               description
2788                 "Includes the name of the Ethernet Segment (ES).";
2789             }

[nits]: please update the description

3824                   container active-global-parameters-profiles {
3825                     description
3826                       "Container for a list of global parameters
3827                        profiles.";
3828                     list global-parameters-profile {
3829                       key "profile-id";
3830                       description
3831                         "List of active global parameters profiles.";
3832                       leaf profile-id {
3833                         type leafref {
3834                           path "../../../../../global-parameters-profiles"
3835                              + "/global-parameters-profile/profile-id";
3836                         }
3837                         description
3838                           "Points to a global profile defined at the
3839                            service level.";
3840                       }
3841                       uses parameters-profile;
3842                     }
3843                   }

[question]: profile-id is a leafref to the "global-parameters-profile", where
grouping "parameters-profile" is already included/used, why is it used here
again? is it for configuration overwritten?