Re: [OPSAWG] Rtgdir telechat review of draft-ietf-opsawg-l2nm-16

mohamed.boucadair@orange.com Wed, 25 May 2022 08:20 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC26DC14F612; Wed, 25 May 2022 01:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi7cCBSfV1EG; Wed, 25 May 2022 01:20:24 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895EFC14F613; Wed, 25 May 2022 01:20:23 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr27.francetelecom.fr (ESMTP service) with ESMTPS id 4L7PBs5pXTz4w8W; Wed, 25 May 2022 10:20:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1653466821; bh=FkzuCfVC3QGk+zWmfbbkJzvWGGeqrw8ZxWRz+Q1QtvI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Ed5eOO6CMp4NhRufrXq1Gd2M33TzrJFqkOqFLUXxxXvnCRC7WbJeAR5/2cbhhB2Ip VQfeHhuQFCujsgSnitnAiquuVA/dc1ZtiBOaazNEW1+9MGyZfvt351u3qvxBzulHP/ ymQifedXw8Ht+njtWQ4EssOBNU0EBH24i/YXHVpUjeWc4WDumuQL7LEKawXdVDrLZy +h/jkPD1wCa/JJYg0qlypNaFgNl7UPm/XQteIMHDHPPgSmjtkW8QaTCzhRANo3T7/P YBea1mmuIF5L/qKauKIOj6ycBCSTgIXH0H+pFplw7d5p/DFz0gXWv62Dk3ooutrp5P 1pb6gd0a9WIOQ==
From: mohamed.boucadair@orange.com
To: Yingzhen Qu <yingzhen.ietf@gmail.com>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-opsawg-l2nm.all@ietf.org" <draft-ietf-opsawg-l2nm.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Rtgdir telechat review of draft-ietf-opsawg-l2nm-16
Thread-Index: AQHYb6LovK7oc68lFkeoEU5GZ2khFq0vP0fA
Content-Class:
Date: Wed, 25 May 2022 08:20:21 +0000
Message-ID: <10370_1653466821_628DE6C5_10370_315_3_ab4dfcff3b2143bb811d7d8ecadbfe3d@orange.com>
References: <165334850837.36350.8527218349497939902@ietfa.amsl.com> <23673_1653374770_628C7F32_23673_369_2_e6244d148c40426d923f2be276d4002d@orange.com> <6CFCF2DE-6600-4C0E-BF39-21A77D49D680@gmail.com>
In-Reply-To: <6CFCF2DE-6600-4C0E-BF39-21A77D49D680@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-05-25T08:13:25Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=63ec7abb-3912-4c25-b3f6-aa8d6e6e5b65; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.26.52]
Content-Type: multipart/alternative; boundary="_000_ab4dfcff3b2143bb811d7d8ecadbfe3dorangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ZZZJ0c-jK4lEX8syAMbg0aVClg4>
Subject: Re: [OPSAWG] Rtgdir telechat review of draft-ietf-opsawg-l2nm-16
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2022 08:20:27 -0000

Hi Yingzhen,

Thank you for the follow-up.

[Yingzhen]: “ethernet-segment-identifier” is defined as string here in stead of a leafref, why?

We used to have that in previous versions, e.g., draft-ietf-opsawg-l2nm-06 had the following:

                       +--rw group* [group-id]
                       |  +--rw group-id                       string
                       |  +--rw precedence?
                       |  |       identityref
                       |  +--rw ethernet-segment-identifier?   leafref

We removed that leafref when we moved ES to a separate module.


As you can see in the new version (https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l2nm-17), we went with the following to have a clean reference to the ES:


  *   define a new typedef in the ES (of type leafref)
  *   use that type in the L2NM

The revised tree looks now as follows:

                       +--rw group* [group-id]
                       |  +--rw group-id                       string
                       |  +--rw precedence?               identityref
                       |  +--rw ethernet-segment-identifier?
                       |                              l2vpn-es:es-ref

Thank you for spotting this.

Cheers,
Med

De : Yingzhen Qu <yingzhen.ietf@gmail.com>
Envoyé : mardi 24 mai 2022 21:17
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Cc : rtg-dir@ietf.org; draft-ietf-opsawg-l2nm.all@ietf.org; last-call@ietf.org; opsawg@ietf.org
Objet : Re: Rtgdir telechat review of draft-ietf-opsawg-l2nm-16

Hi Med,

Thanks for working on my comments. Just one question inline below.

Thanks,
Yingzhen


On May 23, 2022, at 11:46 PM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:

Hi Yingzhen,

Many thanks for the review.

Please see inline.

Cheers,
Med


-----Message d'origine-----
De : Yingzhen Qu via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>>
Envoyé : mardi 24 mai 2022 01:28
À : rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>
Cc : draft-ietf-opsawg-l2nm.all@ietf.org<mailto:draft-ietf-opsawg-l2nm.all@ietf.org>; last-call@ietf.org<mailto:last-call@ietf.org>;
opsawg@ietf.org<mailto:opsawg@ietf.org>
Objet : Rtgdir telechat review of draft-ietf-opsawg-l2nm-16

Reviewer: Yingzhen Qu
Review result: Has Nits

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

[Med] Good catch. Fixed. Thanks.


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

[Med] We tried to find a balance between pointing to RFC9181 and ease the readability of the document.



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.

[Med] ACK. Changed to "encapsulation and pseudowire types"


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

[Med] Fixed, thanks.



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.

[Med] This is called here:

                      +--rw group* [group-id]
                      |  +--rw group-id                       string
                      |  +--rw precedence?
                      |  |       identityref
               =====> |  +--rw ethernet-segment-identifier?   string


A.4 provides an example how the segment is created and then how the name is called in the L2NM.

Updated the text with a pointer to that appendix.

[Yingzhen]: “ethernet-segment-identifier” is defined as string here in stead of a leafref, why?




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

[Med] OK.


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.

[Med] OK, shortened to:

"The exact definition of these profiles is local to each VPN service provider."



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

[nits]: please update the description

[Med] Updated to:

         "Includes the name of the Ethernet Segment (ES) that
          is used to unambiguously identify an ES.";



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?

[Med] We need to call out a specific profile (and use the same id) to be activated at the node level. Some of the parameters will be overridden.



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.