Re: [OPSAWG] Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard l2vpn-ntw

mohamed.boucadair@orange.com Wed, 18 May 2022 13:40 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 42A1BC14F735; Wed, 18 May 2022 06:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 psSrhGdUyDLO; Wed, 18 May 2022 06:40:04 -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 5244FC14F727; Wed, 18 May 2022 06:40:04 -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 opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 4L3Dcy3Wz2zFpv6; Wed, 18 May 2022 15:40:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1652881202; bh=kcFrWP3R8bS814GHXn2u6GclFeeYphMabf5U3WhBuhY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=YP2detOAYve6O0yLBvHB1odJkA76tBG7Y4IHk9CvljFJnr+mw4/699lN3Iemkk0ik 2s9XvHrl61IPbX3F8/9FE+kN6q+xA8WwEI+tGCEl/4W/xiAMrO5HMwF6YZK96T7aUs JlB2irMrppQbN6JOszeoL6Sk0edUljmfif9j5AvHZwMHGBvFL6TKwGBq3/qxaSLhqh FOc8xx4I+cWC7kKJMpdHKnrK50l1eHK0OqqaI5HuzBv4Wt4k1Eq7RWjmsClUcJhUAI 83oVNcB+4lu1TolKLJ9o4tyS4HKjqx9BED9/z/BXKKhoJGGx9+ki7cT/YpE7zaclSS +tGFCIy7a2oMw==
From: mohamed.boucadair@orange.com
To: tom petch <daedulus@btconnect.com>, "last-call@ietf.org" <last-call@ietf.org>
CC: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "opsawg@ietf.org" <opsawg@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "draft-ietf-opsawg-l2nm@ietf.org" <draft-ietf-opsawg-l2nm@ietf.org>
Thread-Topic: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard l2vpn-ntw
Thread-Index: AQHYaqnUAXQ9hRd5S0en4iYKwUCSM60koG1Q
Content-Class:
Date: Wed, 18 May 2022 13:40:01 +0000
Message-ID: <31078_1652881202_6284F732_31078_257_4_321c65d7d59f4b80a7b7612d177760ff@orange.com>
References: <165124323213.7379.13149514636739448316@ietfa.amsl.com> <627E3AF3.8020303@btconnect.com> <25254_1652445383_627E50C7_25254_360_1_343b10ba958d4c7bbd9f31ef9f9c7aa4@orange.com> <6284D763.8080205@btconnect.com>
In-Reply-To: <6284D763.8080205@btconnect.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-18T13:26:43Z; 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=0e65b290-e31a-4189-94ec-d744263d7c6f; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.26.50]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/C_6CidOC86zg0xIcQeg1u2ah0O8>
Subject: Re: [OPSAWG] Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard l2vpn-ntw
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, 18 May 2022 13:40:09 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tom petch <daedulus@btconnect.com>
> Envoyé : mercredi 18 mai 2022 13:24
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> last-call@ietf.org
> Cc : adrian@olddog.co.uk; opsawg@ietf.org; opsawg-chairs@ietf.org;
> draft-ietf-opsawg-l2nm@ietf.org
> Objet : Re: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG
> Network Data Model for Layer 2 VPNs) to Proposed Standard l2vpn-
> ntw
> 
> On 13/05/2022 13:36, mohamed.boucadair@orange.com wrote:
> > Tom,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : tom petch <daedulus@btconnect.com> Envoyé : vendredi 13
> mai 2022
> >> 13:03
> >>
> >> Some stray thoughts on YANG module 'ietf-l2vpn-ntw'
> >>
> >> - In a number of places, the module says 'The default value is
> ...
> >> when used at the service level'.  I have two problems with
> this.
> >> I see no 'default' specified in YANG - there could be but there
> is
> >> not; this would appear to be a recommendation not a default.
> >> Other YANG modules have the concept of e.g. global, link, node
> >> parameters with the same grouping appearing in several places
> with a
> >> suitable but different default specified in each place, but not
> here.
> >
> > [Med] We used to have default statements, but we removed them as
> per a fair comment from during the AD review. Please refer to that
> thread with Rob.
> >
> 
> Yes, but you should also have removed the mention of default in
> the description because there is no default (and most readers of a
> YANG module will think they know what a default is!).

[Med] This was also discussed in that thread with Rob. We included the default mention in the description on purpose as we can't do it using the default statement. This intent is convey to the implementers which defaults to use as a function of data node hierarchy.

> 
> >> Second, the statement is in a grouping, such as parameters-
> profile.
> >> This grouing appears in two 'uses', one under 'global-
> parameters-
> >> profiles' and the other under 'active-global-parameters-
> profiles'.
> >>
> >> How do I marry the reference to 'service level' and whatever is
> the
> >> alternative to 'service level' to a choice of 'active' or
> whatever
> >> the alternative to 'active' is?
> 
> Again, I think that there is a lack of big picture.  I cannot see,
> in the introductory text, something about values specified at
> global v line v node level, or the equivalent thereof for service
> level and whatever the alternative(s) are. Something for s.7
> perhaps.

[Med] That's already provided in Section 7.4:

"The 'global-parameters-profile' defines reusable parameters for the same L2VPN service instance ('vpn-service'). Global parameters profiles are defined at the VPN service level, activated at the VPN node level, and then an activated VPN profile may be used at the VPN network access level. Each VPN instance profile is identified by 'profile-id'. Some of the data nodes can be adjusted at the VPN node or VPN network access levels. These adjusted values take precedence over the global values. The subtree of 'global-parameters-profile' is depicted in Figure 7."

[snip]
> >>
> >
> > [Med] This was designed to mimic RFC8519. The match will be
> based on the parameters that will be provided. This is similar to
> this part from 8519:
> 
> Worth spelling out IMHO, not replicating RFC8519 but referencing
> it
> 

[Med] We do already have the following: 

    "Similar to [RFC8519], an ACL match can be based upon source MAC address, source MAC address mask, destination MAC address, destination MAC address mask, or a combination thereof"



_________________________________________________________________________________________________________________________

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.