Re: [Last-Call] Rtgdir telechat review of draft-ietf-opsawg-l2nm-16
mohamed.boucadair@orange.com Tue, 24 May 2022 06:46 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF78BC14F72C; Mon, 23 May 2022 23:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 Ge4-jaP4YMIG; Mon, 23 May 2022 23:46:13 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 D3D0FC14F74F; Mon, 23 May 2022 23:46:12 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (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 opfedar25.francetelecom.fr (ESMTP service) with ESMTPS id 4L6l8f6C6Jz8ssT; Tue, 24 May 2022 08:46:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1653374770; bh=pTbSFMj1dbl9l/8akxC9gbnKZhGtT3E0BKnp3NRibUw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=VTVe2IgdWzgDc/FqmdfmEJweB0/oxdCAtriXDkE7NiLY68DEPfPID/z8jYbb/80Ho cuoVd/Is6MeIRW2uZMHl71ymJjA+ptU+AvnnBc/eN5Plw8mF2+Hya0BfOBxbl/EYzo 7fghhf4E9YphphnELd3/zCzvfA4+xqHMFiqg0jLqSW0zjpR2KnpwSw9jh6BROj0tcq 7EcQyNYdLAekNqnrNfxT79mFtEb0Tf3IMofmbcVi1FNoW+pSlBiXgZQ75Mmc8fTdP1 cWxqEPPuumcXTA0R9kdW3C7FNKExkV9I5ku1qVkbcOs+f9rWSUUkZiX1xKT6EbnRw9 r2k+f3fXfXlCw==
From: mohamed.boucadair@orange.com
To: Yingzhen Qu <yingzhen.ietf@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "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: AQHYbvzRoeDwMi5k2EC1RnuslXcMO60tjVWw
Content-Class:
Date: Tue, 24 May 2022 06:46:10 +0000
Message-ID: <23673_1653374770_628C7F32_23673_369_2_e6244d148c40426d923f2be276d4002d@orange.com>
References: <165334850837.36350.8527218349497939902@ietfa.amsl.com>
In-Reply-To: <165334850837.36350.8527218349497939902@ietfa.amsl.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-24T06:15:31Z; 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=1f9d996c-2e0a-4724-9589-025fac491e37; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.27.51]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/9NqUrdrSOnyoNatzXkaDmusBBn8>
Subject: Re: [Last-Call] Rtgdir telechat review of draft-ietf-opsawg-l2nm-16
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 06:46:16 -0000
Hi Yingzhen, Many thanks for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Yingzhen Qu via Datatracker <noreply@ietf.org> > Envoyé : mardi 24 mai 2022 01:28 > À : rtg-dir@ietf.org > Cc : draft-ietf-opsawg-l2nm.all@ietf.org; last-call@ietf.org; > 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. > > 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.
- [Last-Call] Rtgdir telechat review of draft-ietf-… Yingzhen Qu via Datatracker
- Re: [Last-Call] Rtgdir telechat review of draft-i… mohamed.boucadair
- Re: [Last-Call] Rtgdir telechat review of draft-i… Yingzhen Qu
- Re: [Last-Call] Rtgdir telechat review of draft-i… mohamed.boucadair