Re: [L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery
"Ogaki, Kenichi" <ke-oogaki@kddi.com> Thu, 16 March 2017 09:35 UTC
Return-Path: <ke-oogaki@kddi.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 7BF58127241 for <l3sm@ietfa.amsl.com>; Thu, 16 Mar 2017 02:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.702
X-Spam-Level:
X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 uLDjMRdjazcB for <l3sm@ietfa.amsl.com>; Thu, 16 Mar 2017 02:35:44 -0700 (PDT)
Received: from post-send.kddi.com (athena3.kddi.com [27.90.165.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6F87612714F for <l3sm@ietf.org>; Thu, 16 Mar 2017 02:35:44 -0700 (PDT)
Received: from LTMC2123.kddi.com (LTMC2123.kddi.com [10.206.0.65]) by post-send.kddi.com (KDDI Mail) with ESMTP id 6B5EAE00B7; Thu, 16 Mar 2017 18:35:43 +0900 (JST)
Received: from LTMC2146.kddi.com ([10.206.0.236] [10.206.0.236]) by LTMC2123.kddi.com with ESMTP; Thu, 16 Mar 2017 18:35:43 +0900
Received: from LTMC2146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 450DF30005D; Thu, 16 Mar 2017 18:35:43 +0900 (JST)
Received: from LTMC2152.kddi.com (post-incheck [10.206.0.239]) by LTMC2146.kddi.com (Postfix) with ESMTP id 39E36300050; Thu, 16 Mar 2017 18:35:43 +0900 (JST)
Received: from LTMC2152.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v2G9Zgjv030659; Thu, 16 Mar 2017 18:35:43 +0900
Received: from LTMC2152.kddi.com.mid_16064013 (localhost.localdomain [127.0.0.1]) by LTMC2152.kddi.com with ESMTP id v2G9PfGL017726; Thu, 16 Mar 2017 18:25:41 +0900
X-SA-MID: 16064013
Received: from KDDI1508PC0003 ([10.200.122.178] [10.200.122.178]) by post-smtp2.kddi.com with ESMTPA; Thu, 16 Mar 2017 18:25:41 +0900
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: 'Jan Lindblad' <janl@tail-f.com>, 'Benoit Claise' <bclaise@cisco.com>
Cc: l3sm@ietf.org, adrian@olddog.co.uk
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>
In-Reply-To: <860CA141-2DDB-4BDA-B256-B824B9D0C10B@tail-f.com>
Date: Thu, 16 Mar 2017 18:25:40 +0900
Message-ID: <00e601d29e37$474accc0$d5e06640$@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGw39OCCWIIZre+1Z/L1DpRkz6jgAHWJocKAgLJ7BEC9thSn6Gj46iQ
Content-Language: ja
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/S_vvxIIwmuSDniahYt9pfcuDy4s>
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 09:35:47 -0000
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. > 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. #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. #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] 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