Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery
<stephane.litkowski@orange.com> Thu, 16 March 2017 10:31 UTC
Return-Path: <stephane.litkowski@orange.com>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9BC127698 for <l3sm@ietfa.amsl.com>; Thu, 16 Mar 2017 03:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_b2mUCKgW6E for <l3sm@ietfa.amsl.com>; Thu, 16 Mar 2017 03:31:24 -0700 (PDT)
Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6732412785F for <l3sm@ietf.org>; Thu, 16 Mar 2017 03:31:24 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 0EB6920478; Thu, 16 Mar 2017 11:31:23 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id BD2F11A0076; Thu, 16 Mar 2017 11:31:22 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0319.002; Thu, 16 Mar 2017 11:31:22 +0100
From: stephane.litkowski@orange.com
To: "Ogaki, Kenichi" <ke-oogaki@kddi.com>, 'Jan Lindblad' <janl@tail-f.com>, 'Benoit Claise' <bclaise@cisco.com>
CC: "l3sm@ietf.org" <l3sm@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery
Thread-Index: AdKNvXn61ktCgLtlTmqZK3F2acEsSwD6n5oAAcEiG4AAAVYhgAFfQv8AAARIADA=
Date: Thu, 16 Mar 2017 10:31:21 +0000
Message-ID: <3764_1489660282_58CA697A_3764_562_1_9E32478DFA9976438E7A22F69B08FF921DD40EF4@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <066b01d28dbd$d30e22a0$792a67e0$@olddog.co.uk> <D6747A53-4855-43CF-97DA-46B5C7F4A551@tail-f.com> <af3c4ff8-41e3-3077-e3af-636fc631738a@cisco.com> <860CA141-2DDB-4BDA-B256-B824B9D0C10B@tail-f.com> <00e601d29e37$474accc0$d5e06640$@kddi.com>
In-Reply-To: <00e601d29e37$474accc0$d5e06640$@kddi.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/yBVEuHN_0ni71y-invAk71_tMks>
Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 10:31:27 -0000
Hi, Pls find inline comments. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Ogaki, Kenichi Sent: Thursday, March 16, 2017 10:26 To: 'Jan Lindblad'; 'Benoit Claise' Cc: l3sm@ietf.org; adrian@olddog.co.uk Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery Hi Jan, All, See comments inline [KO], please. Stephane, Luis, could you correct me if I misunderstand? Thanks, Kenichi -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Jan Lindblad Sent: Thursday, March 09, 2017 6:48 PM To: Benoit Claise Cc: l3sm@ietf.org; adrian@olddog.co.uk Subject: Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery Benoît, all, > On 9 Mar 2017, at 20:09, Benoit Claise <bclaise@cisco.com> wrote: > > Dear all, > > It seems like Jan discovered a bug. > Can the authors confirm? Since the issue I found was in a quick scan, I decided to go through the entire document in a little more ordered fashion. My findings are below. Issue #1 is what I reported earlier. I am truly sorry I did not go through the YANG before the release, but there isn't much to do about that now. I was interested in the final result, so I took a quick look at the model. Within a couple of minutes I stumbled upon this, which is almost certainly not what the author had intended. #1) 1995: grouping site-devices /l3vpn-svc/sites/site container devices { must "/l3vpn-svc/sites/site/management/type = "+ "'provider-managed' or "+ "/l3vpn-svc/sites/site/management/type ="+ "'co-managed'" { To me, it appears that the author intended to say that the "container device" configuration is only applicable when the current site management type is 'provider-managed' or 'co-managed'. That would make sense. The use of "must" and the use of the absolute paths above changes the meaning in YANG to "as soon as any l3vpn is configured, there must be at least one l3vpn (not necessarily the current one) that is 'provider-managed' or 'co-managed'." One implication would be that it would not be legal to have a collection of only 'customer-managed' vpns. What would be legal, though, is to have one 'provider-managed' l3vpn with no device configuration and another 'customer-managed' with devices configured. I expect this was not the intention. I think an expression that reflects the intent would be container devices { when "../management/type = "+ "'provider-managed' or "+ "/l3vpn-svc/sites/site/management/type ="+ "'co-managed'" { This would make the container only exist when the management type of this site specifically is 'provider-managed' or 'co-managed'. [KO] Martin's following modification seems correct. [SLI] I also agree with Martin's proposal. > container devices { > when "../management/type = 'provider-managed' or " > + "../management/type = 'co-managed'" { Now I went through the YANG and discovered a couple more similar things, as well as a slew of optional leafs where the meaning of a non-existent leaf is undefined. #2) 2011: grouping site-devices /l3vpn-svc/sites/site/devices/device/ leaf location { type leafref { path "/l3vpn-svc/sites/site/locations/"+ "location/location-id"; The location and name of the grouping in which 'leaf location' is defined makes me believe the intent is to only allow pointers to locations within the current site. Currently this leafref allows pointing to any location in any site (as well as no reference at all). If my assumption about the modeler's intent is right, the path should be path "../../../locations/location/location-id"; [KO] Basically agree. However, a service provider may allow his/her customer to use two or more l3vpn-svc instances and refer their parameters from each other. [SLI] I would tend to limit to the objects created in the current site. #3) On line 2019 there is another must statement which wants to be a when, and the path is a little too liberal, I'd think. 2019: grouping site-devices /l3vpn-svc/sites/site/devices/device container management { must "/l3vpn-svc/sites/site/management/type"+ "= 'co-managed'" { I think the modeler's intent should be must "../../../management/type = 'co-managed'" { [KO] Agree. [SLI] Agree. #4) There's probably nothing wrong with this one, but since my confidence in guessing the modeler's intent is low here, and there are many previous leafref mistakes in this module, maybe someone should assert that this is what's intended 2139: grouping site-vpn-policy /l3vpn-svc/sites/site leaf vpn-id { type leafref { path "/l3vpn-svc/vpn-services/vpn-svc/vpn-id"; } [OK] The current path is correct. Not "vpn-svc", but "vpn-service". #5) Again, my guess is that the modeler would like to allow references to site-network-access objects from within the current site rather than in any site. 2395:/l3vpn-svc/sites/site/site-network-accesses/site-network-access grouping access-vpn-policy leaf vpn-policy-id { type leafref { path "/l3vpn-svc/sites/site/"+ "vpn-policy-list/vpn-policy/"+ "vpn-policy-id"; } If so, the leafref path should be path "../../../vpn-policy-list/vpn-policy/vpn-policy-id"; [KO] We need one more "../" and s/vpn-policy-list/vpn-policies/ . path "../../../../vpn-policies/vpn-policy/vpn-policy-id"; #6) Assuming I'm right in my suspicion that the current module has errors as described above, I'd say they are grave enough to require fixing. On a far lower severity, there are lot's of leafs and choices which are optional, but declare nothing about any meaning if absent. Probably many of them should be made mandatory or have a default. Most of the rest should probably have a sentence or two added to the description. Below I have collected the line numbers and optional element names where I honestly don't know what the system would do if left without a value. It may be that l3vpn experts would know in some cases, but it wouldn't hurt to spell out. Not fixing these undefined cases limits the interoperability, IMO. 629: leaf nat-enabled 653: choice group-format 757: leaf rp-address 966: choice target-flavor 1149:leaf svc-input-bandwidth 1156:leaf svc-output-bandwidth 1163:leaf svc-mtu 1177:leaf enabled 1194:leaf signalling-type 1237:choice match-type 1272:choice qos-profile 1362:leaf enabled 1367:leaf layer 1382:choice profile 1504:leaf area-address 1509:leaf metric 1526:leaf metric 1550:leaf autonomous-system 1555:leaf-list address-family 1639:leaf-list address-family 1662:leaf-list address-family 1742:leaf provider-address 1747:leaf customer-address 1752:leaf mask 1803:leaf-list server-ip-address 1821:leaf provider-address 1826:leaf customer-address 1831:leaf mask 1850:leaf bfd-enabled 1856:choice holdtime 1979:leaf type 2052:leaf site-vpn-flavor 2087:choice lan 2280:leaf site1 2285:leaf site2 2311:leaf src-site 2316:leaf dst-site 2349:leaf local-sites-role 2406:leaf vpn-id Best Rergards, /jan _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm _________________________________________________________________________________________________________________________ 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.
- [L3sm] RFC 8049 on YANG Data Model for L3VPN Serv… Adrian Farrel
- Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN … Qin Wu
- Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN … Jan Lindblad
- Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN … Benoit Claise
- Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN … Jan Lindblad
- Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN … Martin Bjorklund
- Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN … Ogaki, Kenichi
- Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN … stephane.litkowski