Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-l2nm-18: (with COMMENT)

mohamed.boucadair@orange.com Thu, 02 June 2022 13:36 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 E9A02C15AAD2; Thu, 2 Jun 2022 06:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 SZR97V4B5NmB; Thu, 2 Jun 2022 06:36:17 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 9A027C15AAC1; Thu, 2 Jun 2022 06:36:17 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) (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 opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 4LDRqg3r6yzBsQC; Thu, 2 Jun 2022 15:36:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1654176975; bh=W3ZAsSBM1NERIwTiqmaZo2Otk7pRYHIbNVWz+2/+R7w=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UjffcxxYIAp5O7XjqcUeT+tGmfTAhyiTLIDoQ9buLdBH1Bk0nJ11T5Xl5dqVg9sDH 5efmpHCP7dsevWjXM7B7HLHPX6b2RBfqVW0bznNRlXmi2AXKNY5P4aYv/PAwAOtZZH 5Q2iBtKz70TpSJu3YHWL/1ycszlnVvIE5Wxwxqh2BEQR/gHdRoaW1HtVu7BmS74C+c J2v2OIXDPXLXPsOpIdc+ibcYkfRT5/gX9UIr2RhX8bh96KxjM1IWnW7laD1ucfAxRf m8xdoRTEfdP7i0EDTVtgxjQ3cHneYaYYeLPdwOl0hZ07QHg9G35pBUglSPkxL6UZos Uv8lWG1T7EjUg==
From: mohamed.boucadair@orange.com
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-opsawg-l2nm@ietf.org" <draft-ietf-opsawg-l2nm@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: Éric Vyncke's No Objection on draft-ietf-opsawg-l2nm-18: (with COMMENT)
Thread-Index: AQHYdmRBLs0aJn5GzEaJfN+JV4cQaK073D+QgABiXwD//99FQA==
Content-Class:
Date: Thu, 02 Jun 2022 13:36:14 +0000
Message-ID: <27776_1654176975_6298BCCF_27776_449_1_5a56e8c1a7314f66b905e89819e8dc3c@orange.com>
References: <165416259369.18596.3780660340649307689@ietfa.amsl.com> <4753_1654176047_6298B92E_4753_465_2_496e11fd47634db688f4e26ad268cd3f@orange.com> <D73D92E3-1867-4654-99AC-B8D70F0902F7@cisco.com>
In-Reply-To: <D73D92E3-1867-4654-99AC-B8D70F0902F7@cisco.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-06-02T13:33:34Z; 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=da7418d5-b8e0-4927-a269-1938623bd6f9; 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/opsawg/Nq8rDvjzbdApmNOWUeDv4YN9yYQ>
Subject: Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-l2nm-18: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 02 Jun 2022 13:36:22 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Eric Vyncke (evyncke) <evyncke@cisco.com>
> Envoyé : jeudi 2 juin 2022 15:31
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> The IESG <iesg@ietf.org>
> Cc : draft-ietf-opsawg-l2nm@ietf.org; opsawg-chairs@ietf.org;
> opsawg@ietf.org; adrian@olddog.co.uk
> Objet : Re: Éric Vyncke's No Objection on draft-ietf-opsawg-l2nm-
> 18: (with COMMENT)
> 
> Merci, Med, for your fast reply as usual.
> 
> Remaining comments are marked with EV> below but none were or are
> blocking the publication.
> 
> Regards
> 
> -éric
> 
> 
> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> on behalf of
> "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
> Date: Thursday, 2 June 2022 at 15:21
> To: Eric Vyncke <evyncke@cisco.com>, The IESG <iesg@ietf.org>
> Cc: "draft-ietf-opsawg-l2nm@ietf.org" <draft-ietf-opsawg-
> l2nm@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>,
> "opsawg@ietf.org" <opsawg@ietf.org>, "adrian@olddog.co.uk"
> <adrian@olddog.co.uk>
> Subject: RE: Éric Vyncke's No Objection on draft-ietf-opsawg-l2nm-
> 18: (with COMMENT)
> 
>     Hi Éric,
> 
>     Many thanks for the review.
> 
>     Please see inline.
> 
>     Cheers,
>     Med
> 
>     > -----Message d'origine-----
>     > De : Éric Vyncke via Datatracker <noreply@ietf.org>
>     > Envoyé : jeudi 2 juin 2022 11:37
>     > À : The IESG <iesg@ietf.org>
>     > Cc : draft-ietf-opsawg-l2nm@ietf.org; opsawg-
> chairs@ietf.org;
>     > opsawg@ietf.org; adrian@olddog.co.uk; adrian@olddog.co.uk
>     > Objet : Éric Vyncke's No Objection on draft-ietf-opsawg-
> l2nm-18:
>     > (with COMMENT)
>     >
>     > Éric Vyncke has entered the following ballot position for
>     > draft-ietf-opsawg-l2nm-18: No Objection
>     >
>     > When responding, please keep the subject line intact and
> reply to
>     > all email addresses included in the To and CC lines. (Feel
> free to
>     > cut this introductory paragraph, however.)
>     >
>     >
>     > Please refer to
>     > https://www.ietf.org/about/groups/iesg/statements/handling-
> ballot-
>     > positions/
>     > for more information about how to handle DISCUSS and COMMENT
>     > positions.
>     >
>     >
>     > The document, along with other ballot positions, can be
> found
>     > here:
>     > https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
>     >
>     >
>     >
>     > ------------------------------------------------------------
> ------
>     > ----
>     > COMMENT:
>     > ------------------------------------------------------------
> ------
>     > ----
>     >
>     > # Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD,
> review of
>     > draft-ietf-opsawg-l2nm-18 CC @evyncke
>     >
>     > Thank you for the work put into this document. It solves a
> common
>     > and important
>     > issue while keeping backward compatibility.
>     >
>     > Please find below some non-blocking COMMENT points (but
> replies
>     > would be
>     > appreciated even if only for my own education), and some
> nits.
>     >
>     > Special thanks to Adrian Farrel for the shepherd's write-up
>     > including the WG
>     > consensus and the intended status.
>     >
>     > The use of IANA-maintained YANG modules looks attractive to
> me.
>     >
> 
>     [Med] Thanks.
> 
>     > I hope that this helps to improve the document,
> 
>     [Med] Definitely.
> 
>     >
>     > Regards,
>     >
>     > -éric
>     >
>     > ## COMMENTS
>     >
>     > ### Set of L2VPN technologies
>     >
>     > Just wondering how extensible this model is ? I.e., the L2
> cross-
>     > connect of RFC
>     > 8986 is not included, any reason why ? How easy would it be
> to
>     > extend this
>     > model to also include RFC 8986 ?
> 
>     [Med] ... because that is local to the PE. See of example the
> discussion in RFC4667. Please note that this spec is about a
> network model, not a device model. Some device-specific features
> can be handled directly in the device models, not exposed network-
> wide to a controller. That's said, if such a feature is needed in
> the L2NM, augments can be considered at the "connection" level
> with a condition on the service type, for example.
> 
> EV> ack
>     >
>     > ### Section 2
>     > ```
>     >       The corresponding YANG module can be used by
>     >       a service orchestrator to request a VPN service to a
> network
>     >       controller or to expose the list of active L2VPN
> services.
>     > ```
>     > Does this mean that state information (e.g., counters) are
> not
>     > included ?
> 
>     [Med] This is covered as per the following:
> 
>        The L2NM ('ietf-l2vpn-ntw', Section 8.4) is used to manage
> L2VPNs
>        within a service provider network. In particular, the
> 'ietf-l2vpn-
>        ntw' module can be used to create, modify, delete and
> retrieve L2VPN
>        services in a network controller.
> 
> EV> still missing status/OAM though

[Med] I was assuming this is covered as part of "manage" (FCAPS if you will). Will add some text to make your point more explicit. 

> 
>     > Actually, sections 7.3 & 7.6.3 mention some status & OAM
> support
>     > so suggest
>     > adding status & OAM to the above text.
>     >
>     > ### Section 6
>     >
>     > While I understand that "ethernet" is used in a broad
> concept
>     > (i.e., also
>     > covering Wi-Fi), I find the use of 'ethernet' a little
> restrictive
>     > as layer-2
>     > VPN could exist in a near future with technologies that are
> not
>     > IEEE 802.3
>     > based (e.g., some IoT networks or the good old frame relay).
> Alas,
>     > probably too
>     > late to change anything.
>     >
> 
>     [Med] I prefer to not touch this at this stage.
> 
>     > ### Section 7.4
>     >
>     > ```
>     >   'svc-mtu':  Is the service MTU for an L2VPN service (i.e.,
> Layer
>     > 2
>     >       MTU including L2 frame header/tail).  It is also known
> as
>     > the
>     >       maximum transmission unit or maximum frame size.
>     > ```
>     > Does it include CRC and/or preamble ?
> 
>     [Med] The preamble is not included.
> 
> EV> worth mentioning ?

[Med] I think this is explicitly covered by "L2 frame hader/trailer". Will think about this.

> 
>      It would be nice also to
>     > mention the unit
>     > of this metric.
> 
>     [Med] Good catch. Fixed this and also for some other MTU-
> related data nodes. Thanks.
> 
>     >
>     > Same question in the 'mtu' in section 7.6.4.
> 
>     [Med] ACK.
> 
>     >
>     > ### Section 8.4
>     >
>     > Missing "units" in "svc-mtu'.
> 
>     [Med] Fixed.
> 
>     >
>     > Is 300 msec a valid default aging timer for a MAC address ?
> This
>     > seems really
>     > short.
> 
>     [Med] We do inherit this value from RFC8466, fwiw. This one is
> OK. The one I' unhappy with is the default of the "speed" (10
> mbps)!! but we preferred to maintain it as such to ease the
> mapping between the L2SM (RFC8466) and the L2NM.
> 
> EV> LoL for 10 Mbps ;-) and it is sad for the 300 msec
> 
>     >
>     > ### Sections A.2 & A.3
>     >
>     > Thanks for providing an IPv6 example ;-)
> 
>     [Med] :-)
> 
>     >
>     > ## NITS
>     >
>     > ### MAC is uppercase
>     >
>     > I noticed at least one occurence of 'mac' in lower case.
> 
>     [Med] Thanks. Fixed.
> 
> 


_________________________________________________________________________________________________________________________

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.