Re: [pim] [yang-doctors] Optional key support?
Andy Bierman <andy@yumaworks.com> Wed, 24 October 2018 17:31 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984A5130E77 for <pim@ietfa.amsl.com>; Wed, 24 Oct 2018 10:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 CSb8JS-GJltf for <pim@ietfa.amsl.com>; Wed, 24 Oct 2018 10:30:53 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803BB130E1E for <pim@ietf.org>; Wed, 24 Oct 2018 10:30:51 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id k11-v6so5545750lja.5 for <pim@ietf.org>; Wed, 24 Oct 2018 10:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9AD7OTsjD88rVE2ZlDVgTSSyskMsjFaYkmcU6Fz5VzE=; b=UHzUwjq/KMY4eT6R0EWydbCX7eCjGxXOTPhA/VS1aa0QOkoV/g3XDw/PLMccEsr65i kwNhtIUOvc9PmgibaObTTTezFgLV0Ix6kU4Y9kgdPCRFYTWK4UFGfSs72rd1JElGA9Hf i8n4RCv2xsvU+dMKZ9bSV2wKtfQ/kfT1VizqW4xGdYuH/JwVl3vlaO7b6HAht8EorJyU l3BV+GSAvPPhgYMSTCau5/y+5gnMYXxPh/ZdBktjlsP1OG/FKS4hVrAG7HMZ8XcUkfGy D7qZHN3vnoVmSkPJLqP0xDoxSWwwhyTAkB+pdFVEqlf3KCjTsIsyKmCLlxShLaPMVjP5 +moA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9AD7OTsjD88rVE2ZlDVgTSSyskMsjFaYkmcU6Fz5VzE=; b=K7euLN2BJoUZ7aYw2DKwMmx/Huz7T7MhAfaBacILi/Sxd1tSoG20+/Tj6JcfWa8y9W Spk9/+TQ5grzYdGLkKHfW8guh5XDXiiaSpWrEl7nV6DiiUdizYnmPENSpr3Tm+k2z8up K+qAig/vHTUTTOOs9ZkbC34yBAFMCODwcMwe1N4JQgYg7OgYx5byYm6PUxqbTZtybhfM Lzoonqq03Cma9jwZZKcQodWWk7EU/aWY08dGnfoHDPXs8Da2xuYUlxq9PrWqdeIQGTSx BzAjDzVdqEMQzumzJJLZTWcl2un4ASwuOvduAXsJN1I2oKd2s4DOIzDjRgXP1BQv3beX zLtQ==
X-Gm-Message-State: AGRZ1gLXpRNDElhkahgAxEfz7DsDJnz7m9RSHQnrozFhDitNs6bd8UXC YAe75/PsTnXjNHNfeBabEZY/ZctYDAuTmLTvDdAiRA==
X-Google-Smtp-Source: AJdET5c67Nz1LWWnAOlCwqmkJj//m/l3ohOi2b3QNtfSTlbb1XGo+VLQ6AKHrnKw2aBi7aaa7A2ky1IgVdKeQ+noMFY=
X-Received: by 2002:a2e:810e:: with SMTP id d14-v6mr2444018ljg.170.1540402249254; Wed, 24 Oct 2018 10:30:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Wed, 24 Oct 2018 10:30:47 -0700 (PDT)
In-Reply-To: <991ade50-85d3-c907-0fb2-3d777ae49e09@cisco.com>
References: <8AC97776-E280-45D0-86AC-08BF3F13A60B@cisco.com> <CABCOCHTSiW8y46SMvXcyW0rTZmNDfHPUka_Y35gW8v5M8yC--Q@mail.gmail.com> <20181024.074744.771331979340686070.mbj@tail-f.com> <870A0CEB-1E21-4451-80FD-2D1DE605A8C7@cisco.com> <991ade50-85d3-c907-0fb2-3d777ae49e09@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 24 Oct 2018 10:30:47 -0700
Message-ID: <CABCOCHSc0NM=suTkVd5DBt_cst9GWAEx=Rh6Z+Jkpc+PdVHXnA@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "xufeng.liu.ietf@gmail.com" <xufeng.liu.ietf@gmail.com>, "sivakumar.mahesh@gmail.com" <sivakumar.mahesh@gmail.com>, "stig@venaas.com" <stig@venaas.com>, "guofeng@huawei.com" <guofeng@huawei.com>, "anish.ietf@gmail.com" <anish.ietf@gmail.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "liuyisong@huawei.com" <liuyisong@huawei.com>, "pete.mcallister@metaswitch.com" <pete.mcallister@metaswitch.com>, "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e0e43f0578fcd84a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/mQDQEVIdw9PHLyhIus-0sd-Rfjo>
X-Mailman-Approved-At: Thu, 25 Oct 2018 16:20:26 -0700
Subject: Re: [pim] [yang-doctors] Optional key support?
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 17:31:09 -0000
On Wed, Oct 24, 2018 at 8:56 AM, Robert Wilton <rwilton@cisco.com> wrote: > It looks like the final reason that it was not accepted was because the > change was regarded as being too big for YANG 1.1. As such, it seems > reasonable for this issue to be on Yang.next and considered again. > > My objection to it was that it had a huge impact on the protocols and the implementations. The added complexity is not worth it. It is not that hard to define a value that indicates "not really used". That is not the same as "use the default". Doing this in an elegant way instead of ad-hoc requires coordinated solutions in YANG, protocols, and servers. There are probably lots of complex YANG text changes because the concept of an instance (and an instance-identifier) is so different. Also augment, leafref, and other cross-model dependencies are impacted. Thanks, > Rob > Andy > > On 24/10/2018 15:53, Acee Lindem (acee) wrote: > >> Read through the discussion and it is a shame we can't converge on a >> solution. Is YANG 1.0 compatibility the major issue? >> Thanks, >> Acee >> >> On 10/24/18, 1:48 AM, "yang-doctors on behalf of Martin Bjorklund" < >> yang-doctors-bounces@ietf.org on behalf of mbj@tail-f.com> wrote: >> >> Andy Bierman <andy@yumaworks.com> wrote: >> > Hi, >> > >> > It has been discussed before. >> > It is already allowed for config=false nodes so the change would >> be to >> > allow config=true nodes >> > to have no keys. >> > >> > Each time it comes up, somebody mentions that >> > (a) NETCONF/RESTCONF has no mechanism to delete all list entries >> > (b) The client cannot create more than 1 entry. How does the >> server know >> > the next entry is a different instance or replacing the first >> instance? >> I don't think these were the reasons. See the proposal that >> was on >> the table for 1.1: >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html >> #sec-10 >> and the discussion: >> https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1&index >> =bwacmVipuJMakMFjDXXCZMXCTAA >> /martin >> > What is the use-case for a config list without keys? >> > >> > >> > Andy >> > >> > >> > On Tue, Oct 23, 2018 at 2:16 PM, Reshad Rahman (rrahman) < >> rrahman@cisco.com> >> > wrote: >> > >> > > <Changed subject> >> > > >> > > >> > > >> > > Hi Xufeng, >> > > >> > > >> > > >> > > I don’t know if this has been discussed for yang-next but it >> doesn’t seem >> > > to be in the yang-next list. I believe optional keys were >> discussed for >> > > YANG1.1, maybe others on the YD list remember… >> > > >> > > https://github.com/netmod-wg/yang-next/issues >> > > >> > > >> > > >> > > In this case, I believe it would have been useful to have that >> > > functionality. >> > > >> > > >> > > >> > > Regards, >> > > >> > > Reshad. >> > > >> > > >> > > >> > > *From: *Xufeng Liu <xufeng.liu.ietf@gmail.com> >> > > *Date: *Tuesday, October 23, 2018 at 4:39 PM >> > > *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com> >> > > *Cc: *"janl@tail-f.com" <janl@tail-f.com>, Mahesh Sivakumar < >> > > sivakumar.mahesh@gmail.com>, Stig Venaas <stig@venaas.com>, >> Guofeng < >> > > guofeng@huawei.com>, Anish Peter <anish.ietf@gmail.com>, " >> > > yang-doctors@ietf.org" <yang-doctors@ietf.org>, Liuyisong < >> > > liuyisong@huawei.com>, Pete McAllister < >> pete.mcallister@metaswitch.com>, " >> > > pim@ietf.org" <pim@ietf.org> >> > > *Subject: *Re: [yang-doctors] [pim] Yangdoctors last call review >> of >> > > draft-ietf-pim-igmp-mld-yang-07 >> > > >> > > >> > > >> > > Hi Reshad and All, >> > > >> > > >> > > >> > > Do you think that it would be useful to eventually extend YANG >> spec to >> > > allow an optional key with a default value? That would allow the >> user not >> > > to enter the extra empty string, and make the model more user >> friendly. >> > > >> > > >> > > >> > > Thanks, >> > > >> > > - Xufeng >> > > >> > > >> > > >> > > On Fri, Oct 19, 2018 at 11:02 AM Reshad Rahman (rrahman) < >> > > rrahman@cisco.com> wrote: >> > > >> > > Hi Xufeng, >> > > >> > > >> > > >> > > I think we should go with the solution proposed by Chris >> (attached) when >> > > we last discussed this. I realize it’s not ideal but IMO it’s >> better than >> > > other proposals. >> > > >> > > >> > > >> > > Regards, >> > > >> > > Reshad. >> > > >> > > >> > > >> > > *From: *yang-doctors <yang-doctors-bounces@ietf.org> on behalf >> of Xufeng >> > > Liu <xufeng.liu.ietf@gmail.com> >> > > *Date: *Friday, October 19, 2018 at 9:21 AM >> > > *To: *"janl@tail-f.com" <janl@tail-f.com> >> > > *Cc: *Mahesh Sivakumar <sivakumar.mahesh@gmail.com>, Stig >> Venaas < >> > > stig@venaas.com>, Guofeng <guofeng@huawei.com>, Anish Peter < >> > > anish.ietf@gmail.com>, "yang-doctors@ietf.org" < >> yang-doctors@ietf.org>, >> > > Liuyisong <liuyisong@huawei.com>, Pete McAllister < >> > > pete.mcallister@metaswitch.com>, "pim@ietf.org" <pim@ietf.org> >> > > *Subject: *Re: [yang-doctors] [pim] Yangdoctors last call review >> of >> > > draft-ietf-pim-igmp-mld-yang-07 >> > > >> > > >> > > >> > > Hi Jan, >> > > >> > > >> > > >> > > Thanks for reviewing. >> > > >> > > For #1, as discussed, there is no other better solution at the >> moment. >> > > What would you suggest? >> > > >> > > Thanks. >> > > >> > > - Xufeng >> > > >> > > >> > > >> > > On Fri, Oct 19, 2018 at 4:25 AM Jan Lindblad <janl@tail-f.com> >> wrote: >> > > >> > > Feng, >> > > >> > > >> > > >> > > Hi Jan, >> > > >> > > >> > > >> > > We updated draft-ietf-pim-igmp-mld-yang according to the >> comments #2 ~ >> > > #7, while Xufeng and you had discussed about comment #1. >> > > >> > > Please review the draft, thanks a lot. >> > > >> > > https://www.ietf.org/id/draft-ietf-pim-igmp-mld-yang-08.txt >> > > >> > > >> > > >> > > Good. I looked through the points #2-#7 and find that the work >> group have >> > > understood and fixed those issues. #1 still remains to be >> resolved. I can >> > > do a full re-review of the module once that one has been >> resolved as well.. >> > > Are there any outstanding questions on how to fix #1? >> > > >> > > >> > > >> > > Best Regards, >> > > >> > > /jan >> > > >> > > -- >> > > >> > > *Jan Lindblad*, janl@tail-f.com, +46 702855728 >> > > >> > > Solutions Architect, Business Development, Tail-f >> > > >> > > Tail-f is now a part of Cisco >> > > >> > > >> > > >> > > >> > > >> > > Feng >> > > >> > > >> > > >> > > -----Original Message----- >> > > >> > > From: Jan Lindblad [mailto:janl@tail-f.com <janl@tail-f.com>] >> > > >> > > Sent: Monday, August 13, 2018 10:35 PM >> > > >> > > To: yang-doctors@ietf.org >> > > >> > > Cc: ietf@ietf.org; pim@ietf.org; draft-ietf-pim-igmp-mld-yang.a >> ll@ietf.org >> > > >> > > Subject: Yangdoctors last call review of >> draft-ietf-pim-igmp-mld-yang-07 >> > > >> > > >> > > >> > > Reviewer: Jan Lindblad >> > > >> > > Review result: On the Right Track >> > > >> > > >> > > >> > > This is my YANG-doctor review of draft-ietf-pim-igmp-mld-yang-07. >> In the >> > > spring, I did an early review of the -02 version. >> > > >> > > >> > > >> > > Most of the comments from the earlier review are still valid. In >> some ways >> > > the document has progressed since -02, in many it has not, and >> in a few it >> > > has deteriorated. In my judgement, the document is not ready for >> last call. >> > > Many fundamentally important questions are still unresolved. >> Here are my >> > > review comments in rough falling order of importance. >> > > >> > > >> > > >> > > #1 Improper augment of /rt:routing/rt:control-plane-protocols >> > > >> > > >> > > >> > > Quoted from section 3.1: >> > > >> > > This model augments the core routing data model "ietf-routing" >> > > >> > > specified in [RFC8349]. The IGMP model augments "/rt:routing/ >> > > >> > > rt:control-plane-protocols" as opposed to augmenting >> "/rt:routing/ >> > > >> > > rt:control-plane-protocols/rt:control-plane-protocol", as >> the latter >> > > >> > > would allow multiple protocol instances, while the IGMP >> protocol is >> > > >> > > designed to be enabled or disabled as a single protocol >> instance on >> > > >> > > a network instance or a logical network element. >> > > >> > > >> > > >> > > The description above, and the actual augment statements in the >> YANG >> > > module violate the principles described in RFC 8349, the >> ietf-routing.yang >> > > module it augments. In RFC 8349, section 5.3. Control-Plane >> Protocol, the >> > > proper way of augmenting the routing module is described. The >> fact that >> > > this is a singleton protocol instance doesn't change this. >> Section 5.3 >> > > describes singleton cases as well. >> > > >> > > >> > > >> > > Guofeng: Xufeng has discussed with Jan about the comment, and it >> is closed. >> > > >> > > >> > > >> > > #2 Incorrect vendor refinement model >> > > >> > > >> > > >> > > Quoted from section 2.2: >> > > >> > > For the same reason, wide constant ranges (for example, timer >> > > >> > > maximum and minimum) will be used in the model. It is >> expected that >> > > >> > > vendors will augment the model with any specific restrictions >> that >> > > >> > > might be required. Vendors may also extend the features list >> with >> > > >> > > proprietary extensions. >> > > >> > > >> > > >> > > This is not acceptable. The principle suggested does not foster >> > > interoperability and useful standards. It is also not possible >> to do what >> > > the paragraph suggests in YANG. This was pointed out in the -02 >> review, and >> > > a suggestion was given there on how to address the problem. >> > > >> > > >> > > >> > > Guofeng: We removed the paragraph above, and put the values >> discussed by >> > > Mcast Design Team. >> > > >> > > >> > > >> > > >> > > >> > > #3 Top level structures not optional >> > > >> > > >> > > >> > > Quoted from section 2.3: >> > > >> > > The current document contains IGMP and MLD as separate schema >> > > >> > > branches in the structure. The reason for this is to make it >> easier >> > > >> > > for implementations which may optionally choose to support >> specific >> > > >> > > address families. And the names of objects may be different >> between >> > > >> > > the IPv4 (IGMP) and IPv6 (MLD) address families. >> > > >> > > >> > > >> > > This problem was also pointed out in the -02 review. The author >> suggests >> > > that implementing igmp and/or mld is optional. This is not >> reflected in the >> > > YANG module, however. As currently modeled, both are currently >> mandatory to >> > > implement. If-feature is used liberally in the module, and could >> be used >> > > here as well. >> > > >> > > >> > > >> > > #4 Unclear meaning of optional leaves >> > > >> > > >> > > >> > > Quoted from section 3.1: >> > > >> > > Where fields are not genuinely essential to protocol >> operation, they >> > > >> > > are marked as optional. Some fields will be essential but >> have a >> > > >> > > default specified, so that they need not be configured >> explicitly. >> > > >> > > >> > > >> > > In fact, in the current version of the module, every leaf is >> optional >> > > (except keys, which cannot be optional). It is good to see the >> addition of >> > > defaults in many cases, but many unclear cases remain. E.g. leaf >> > > /igmp/global/enable is of type boolean. I understand what true >> and false >> > > implies for this leaf. But what does it mean if it is not set at >> all? >> > > Either add a default or describe the meaning in the description. >> Similarly, >> > > if the leaf version is not set on an igmp or mld interface, or >> on the >> > > interface-global level, what does that mean? >> > > >> > > Add default. require-router-alert? explicit-tracking? >> exclude-lite? Many >> > > of these are used in NP-containers inheriting all the from the >> root, which >> > > makes the use of mandatory highly discouraged in the current >> form. If the >> > > RFC 8349 augmentation principles are followed, the concern >> around mandatory >> > > falls, and some leafs with no sensible default could be marked >> mandatory >> > > instead. >> > > >> > > >> > > >> > > #5 All optional state >> > > >> > > >> > > >> > > All state data is optional, which means a conforming server >> could very >> > > well decide not to implement it. E.g. discontinuity-time is >> optional. >> > > Should a manager count on this being available? A situation >> where every >> > > leaf is optional is as nice and flexible for server implementors >> as it is >> > > frustrating and complicated for manager implementors to consume. >> A YANG >> > > model is an API contract and should consider the needs of both >> sides. The >> > > way this has been designed reveals that no representation for >> the consumer >> > > side of this model has been involved in the design. I would >> suggest >> > > thinking through what is the most essential state data for a >> manager, and >> > > make some leafs mandatory. >> > > >> > > >> > > >> > > #6 Abundant copy-paste >> > > >> > > >> > > >> > > There is abundant repetition in the YANG module. leaf version is >> defined 2 >> > > times for igmp with identical definitions, and two more for mld >> with >> > > identical definitions. leaf enable is defined once for the >> interface >> > > global-level, and with identical definition on the interface >> local level. >> > > leaf last-member-query-interval, query-interval and half a dozen >> other >> > > leaves are defined twice with identical definitions. >> > > >> > > >> > > >> > > #7 Leaf interface in the rpc clear*groups on line 1124, 1094 has >> type >> > > string. >> > > >> > > Should be a leafref? Describe what values are valid. #8 Leaf >> group-policy, >> > > source-policy on line 486, 527, 624, 689: type string. Should be >> leafref? >> > > >> > > Describe what values are valid. #9 Leaf group on line 705, 1101, >> 1131: Is >> > > any >> > > >> > > ipv4/6 address ok, or only a multicast address? Model >> accordingly. >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > *From:* pim [mailto:pim-bounces@ietf.org <pim-bounces@ietf.org>] >> *On >> > > Behalf Of *Jan Lindblad >> > > *Sent:* Tuesday, September 11, 2018 9:52 PM >> > > *To:* Xufeng Liu <xufeng.liu.ietf@gmail.com> >> > > *Cc:* yang-doctors@ietf.org; ietf <ietf@ietf.org>; pim@ietf.org; >> > > draft-ietf-pim-igmp-mld-yang.all@ietf.org >> > > *Subject:* Re: [pim] Yangdoctors last call review of >> > > draft-ietf-pim-igmp-mld-yang-07 >> > > >> > > >> > > >> > > Xufeng, >> > > >> > > >> > > >> > > Thanks for the review and valuable comments. >> > > >> > > >> > > >> > > In regard to item #1, there was a discussion thread among the >> Yang >> > > Doctors, authors of RFC 8349, and Routing Area Yang Architecture >> Design >> > > Team, as attached below. The discussion occurred during the >> review of a >> > > draft with the same issue as this one. >> > > >> > > >> > > >> > > I see, didn't know. Good. If this has been discussed to >> conclusion, then >> > > you should of course go with that decision. >> > > >> > > >> > > >> > > As mentioned earlier, there are a few other singleton protocols >> mapped >> > > into this structure, e.g. static. I think it would make sense to >> treat this >> > > the same. Principle of least astonishment. >> > > >> > > >> > > >> > > Best Regards, >> > > >> > > /jan >> > > >> > > >> > > >> > > >> > > >> > > ================================ >> > > >> > > 原始邮件 >> > > 发件人:XufengLiu <Xufeng_Liu@jabil.com> >> > > 收件人:Acee Lindem (acee) <acee@cisco.com>Christian Hopps < >> chopps@chopps.org>Martin >> > > Bjorklund <mbj@tail-f.com> >> > > 抄送人:张征00007940;yang-doctors@ietf.org <yang-doctors@ietf.org> >> > > 日 期 :2018年02月20日 22:30 >> > > 主 题 :RE: [yang-doctors] How to restrict to have >> > > singlecontrol-plane-protocol instance >> > > Using "" as the name is better, but I am not sure that it is >> good enough. >> > > When we use ConfD to translate the model to a command line, if >> the option >> > > "tailf:cli-expose-key-name" is not used, we will have: >> > > >> > > edit routing control-plane-protocols control-plane-protocol type >> msdp name >> > > ''" >> > > >> > > If the option "tailf:cli-expose-key-name" is used, we will have: >> > > >> > > edit routing control-plane-protocols control-plane-protocol msdp >> ''" >> > > >> > > I am pretty sure that we would get a bug report on this, asking >> what is >> > > the purpose to have: name ''", and requesting a suppression on >> the term, >> > > but we do not have a good way to achieve. >> > > >> > > As a comparison, the option #3 will give: >> > > >> > > edit routing control-plane-protocols msdp >> > > >> > > This is the only acceptable solution so far. When a model is not >> usable by >> > > the end-user, other considerations (such as augmentation >> convenience) will >> > > not matter. >> > > >> > > Thanks, >> > > - Xufeng >> > > >> > > > -----Original Message----- >> > > > From: Acee Lindem (acee) [mailto:acee@cisco.com] >> > > > Sent: Monday, February 19, 2018 1:35 PM >> > > > To: Christian Hopps <chopps@chopps.org>; Martin Bjorklund < >> > > mbj@tail-f.com> >> > > > Cc: Xufeng Liu <Xufeng_Liu@jabil.com>; zhang.zheng@zte.com.cn; >> yang- >> > > > doctors@ietf.org >> > > > Subject: Re: [yang-doctors] How to restrict to have single >> control-plane- >> > > > protocol instance >> > > > >> > > > >> > > > >> > > > On 2/19/18, 5:02 AM, "Christian Hopps" <chopps@chopps.org> >> wrote: >> > > > >> > > > >> > > > Martin Bjorklund <mbj@tail-f.com> writes: >> > > > >> > > > > Hi, >> > > > > >> > > > > "Acee Lindem (acee)" <acee@cisco.com> wrote: >> > > > >> All, >> > > > >> >> > > > >> As seems to be the modus operandi for YANG issues, we >> have 3 >> > > separate >> > > > opinions as to how a protocol only supporting a single >> instance should be >> > > > realized. >> > > > >> >> > > > >> 1. Augment the existing control plane protocols list >> (RFC >> > > 8022BIS) >> > > > >> and specify in the description text that only a >> single instance >> > > is >> > > > >> supported. >> > > > >> 2. Augment the existing control plane protocols list >> (RFC >> > > 8022BIS) >> > > > >> and use a YANG 1.1 must() restriction as discussed by >> Martin and >> > > > >> Lada. >> > > > >> 3. Augment the container one level up from the list >> for >> > > singleton >> > > > >> protocols (suggested by Xufeng). >> > > > >> > > > > But I think there was also a proposal to require the >> single >> > > instance >> > > > > to have a well-known name - but maybe this proposal is >> no longer on >> > > > > the table. >> > > > >> > > > I actually liked this solution; however, instead of >> picking an >> > > arbitrary "well- >> > > > known" value for name, I would specify the 0 length string >> instead. I >> > > think that >> > > > reinforces the idea that this isn't actually a named instance. >> :) >> > > > >> > > > augment "/rt:routing/rt:control-plane-protocols/" >> > > > + "rt:control-plane-protocol" { >> > > > when "derived-from-or-self(rt:type, 'msdp:msdp') and >> rt:name = >> > > ''" { >> > > > container msdp { >> > > > >> > > > One benefit of this solution is that it solves Xufeng's issue >> of what >> > > the client uses >> > > > as the instance name. >> > > > >> > > > >> > > > Thanks, >> > > > Chris. >> > > > >> > > > > >> > > > > >> > > > > /martin >> > > > > >> > > > > >> > > > >> and #3. For #3, one determent would be that the control >> plane >> > > protocols >> > > > are in a location other than where they were originally >> envisioned and I >> > > don't >> > > > relish pulling RFC8022BIS off the RFC queue to document. >> > > > >> >> > > > >> Thanks, >> > > > >> Acee >> > > > >> >> > > > >> On 2/15/18, 8:39 AM, "Reshad Rahman (rrahman)" < >> rrahman@cisco.com >> > > > >> > > > wrote: >> > > > >> >> > > > >> Hi Xufeng, >> > > > >> >> > > > >> I think the intent of 8022bis was to have all >> protocols under >> > > > /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol. >> I >> > > agree that >> > > > forcing a name for a single-instance is cumbersome, but I >> think it is >> > > too late to >> > > > change tree hierachy organization at this point. >> > > > >> >> > > > >> I will defer to other YDs and 8022bis authors on >> this. >> > > > >> >> > > > >> Regards, >> > > > >> Reshad. >> > > > >> >> > > > >> On 2018-02-08, 9:48 AM, "Xufeng Liu" < >> Xufeng_Liu@jabil.com> >> > > wrote: >> > > > >> >> > > > >> Hi All, >> > > > >> >> > > > >> I feel that such a solution is still not clean >> enough to >> > > outweigh the >> > > > simple augmentation to "/rt:routing/rt:control-plane- >> protocols/". >> > > > >> >> > > > >> Some considerations are: >> > > > >> >> > > > >> - Name management: Neither the operator nor the >> > > implementation >> > > > wants to deal with the artificial name, whether it is >> hardcoded, >> > > user-configured, >> > > > or system-generated. When we implement such singleton >> protocol, we don't >> > > > save a name anywhere. >> > > > >> - The complexity of validation: The "when" >> statement is an >> > > > unnecessary expense to the user and to the implementation, >> especially if >> > > we >> > > > need to check all instances. >> > > > >> - Data tree query: If the singleton "MSDP" is >> mixed with >> > > other protocol >> > > > instances, it is less obvious or harder to search for. >> Depending on the >> > > > implementation, it would be worse if the entire list needs to >> be >> > > iterated. >> > > > >> - Tree hierarchy organization: I don't see too >> big a >> > > problem with "all >> > > > single-instance protocols under /rt:routing/rt:control-plane-p >> rotocols >> > > and all >> > > > the multi-instance ones under /rt:routing/rt:control-plane- >> > > protocols/rt:control- >> > > > plane-protocol". If necessary, some of the names can be >> adjusted. >> > > > >> >> > > > >> Thanks, >> > > > >> - Xufeng >> > > > >> >> > > > >> >> > > > >> > -----Original Message----- >> > > > >> > From: Reshad Rahman (rrahman) [mailto: >> rrahman@cisco.com >> > > ] >> > > > >> > Sent: Thursday, February 8, 2018 9:41 AM >> > > > >> > To: Ladislav Lhotka <lhotka@nic.cz>; Martin >> Bjorklund >> > > <mbj@tail- >> > > > f.com>; >> > > > >> > Acee Lindem (acee) <acee@cisco.com> >> > > > >> > Cc: yang-doctors@ietf.org; >> zhang.zheng@zte.com.cn; >> > > Xufeng Liu >> > > > >> > <Xufeng_Liu@jabil.com> >> > > > >> > Subject: Re: [yang-doctors] How to restrict >> to have >> > > single control- >> > > > plane- >> > > > >> > protocol instance >> > > > >> > >> > > > >> > Thanks for the suggestions. I agree that >> hard-coding >> > > the name is a >> > > > bad idea, >> > > > >> > glad that a cleaner way of doing this is >> possible. >> > > > >> > - We can move the must statement up to >> restrict max of >> > > 1 control- >> > > > plane- >> > > > >> > protocol instance of type msdp? >> > > > >> > - Acee/Lada, should a note be added to >> section 5.3 of >> > > 8022bis >> > > > regarding how >> > > > >> > to enforce single instance? How much of a >> concern is the >> > > > performance >> > > > >> > impact in this specific case? >> > > > >> > >> > > > >> > Regards, >> > > > >> > Reshad. >> > > > >> > >> > > > >> > On 2018-02-08, 7:02 AM, "Ladislav Lhotka" < >> > > lhotka@nic.cz> wrote: >> > > > >> > >> > > > >> > On Thu, 2018-02-08 at 12:39 +0100, Martin >> Bjorklund >> > > wrote: >> > > > >> > > "Acee Lindem (acee)" <acee@cisco.com> >> wrote: >> > > > >> > > > Hi Lada, >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > On 2/8/18, 4:42 AM, "yang-doctors on >> behalf of >> > > Ladislav >> > > > Lhotka" >> > > > >> > <yang-docto >> > > > >> > > rs-bounces@ietf.org on behalf of >> lhotka@nic.cz> >> > > wrote: >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > On Thu, 2018-02-08 at 09:20 >> +0100, Martin >> > > Bjorklund wrote: >> > > > >> > > >> > > > >> > > > > Hi, >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > "Reshad Rahman (rrahman)" < >> > > rrahman@cisco.com> wrote: >> > > > >> > > >> > > > >> > > > > > Hi YDs, >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > MSDP YANG authors want to >> enforce >> > > single-instance of >> > > > MSDP >> > > > >> > > >> > > > >> > > > > > control-plane protocol. The >> when >> > > “rt:type = >> > > > ‘msdp’“ allows >> > > > >> > multiple >> > > > >> > > >> > > > >> > > > > > control-pane-protocol >> instances as long >> > > as they have >> > > > different >> > > > >> > > >> > > > >> > > > > > rt:name. The only workaround >> I thought >> > > of is to have a >> > > > when >> > > > >> > > statement >> > > > >> > > >> > > > >> > > > > > on the name in the top level >> container.. >> > > This would still >> > > > multiple >> > > > >> > > >> > > > >> > > > > > control-plane-protocol >> instance of type >> > > msdp but >> > > > restricts the >> > > > >> > name >> > > > >> > > to >> > > > >> > > >> > > > >> > > > > > a fixed name (msdp-protocol >> in this >> > > case) for the top level >> > > > msdp >> > > > >> > > >> > > > >> > > > > > container to exist. Any >> suggestions on >> > > how to do this >> > > > better? >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > Hard-coding a name like this is >> IMO a bad >> > > idea. >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > Better would be to simply state >> in text >> > > that there MUST >> > > > only be one >> > > > >> > > >> > > > >> > > > > instance of this type. >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > But you can also add a must >> statement >> > > that enforces this: >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > augment >> "/rt:routing/rt:control-plane- >> > > protocols/" >> > > > >> > > >> > > > >> > > > > + >> "rt:control-plane-protocol" { >> > > > >> > > >> > > > >> > > > > when >> 'derived-from-or-self(rt:type, >> > > "msdp:msdp"' { >> > > > >> > > >> > > > >> > > > > container msdp { >> > > > >> > > >> > > > >> > > > > must >> 'count(/rt:routing/rt:control- >> > > plane-protocols/' >> > > > >> > > >> > > > >> > > > > + ' >> > > rt:control-plane-protocol[' >> > > > >> > > >> > > > >> > > > > + ' >> > > derived-from-or-sel(../rt:type, "msdp:msdp")]) >> > > > <= >> > > > >> > > 1'"; >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > In general, you should be >> careful with >> > > the usage of "count", >> > > > since it >> > > > >> > > >> > > > >> > > > > will loop through *all* >> instances in the >> > > list every time. If >> > > > the list >> > > > >> > > >> > > > >> > > > > is big, this can have a >> performance >> > > impact. >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > Instead of count(), it is >> possible to use >> > > the so-called >> > > > Muenchian >> > > > >> > > method: >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > container msdp { >> > > > >> > > >> > > > >> > > > must >> "not(../preceding-sibling::rt: >> > > control-plane- >> > > > protocol[" >> > > > >> > > >> > > > >> > > > + >> "derived-from-or-self(rt:type, >> > > 'msdp:msdp')])"; >> > > > >> > > >> > > > >> > > > .. >> > > > >> > > >> > > > >> > > > } >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > It basically states that the >> > > control-plane-protocol containing >> > > > the >> > > > >> > > "msdp" >> > > > >> > > >> > > > >> > > > container must not be preceded >> with a >> > > control-plane- >> > > > protocol entry >> > > > >> > of >> > > > >> > > the >> > > > >> > > >> > > > >> > > > msdp:msdp type (or derived). >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > This looks like an elegant solution. >> > > > >> > > >> > > > >> > > >> > > > >> > > "elegant" as in "less obvious" ;) It >> has the >> > > same time complexity >> > > > as >> > > > >> > > the count() solution. >> > > > >> > >> > > > >> > It should be faster on the average - it >> has to scan >> > > only preceding >> > > > siblings of >> > > > >> > the MSDP protocol instance whereas >> count() always >> > > has to check >> > > > *all* >> > > > >> > protocol >> > > > >> > instances. >> > > > >> > >> > > > >> > It is true though that in XSLT this >> technique can >> > > be made >> > > > considerably >> > > > >> > more >> > > > >> > efficient by using indexed keys. >> > > > >> > >> > > > >> > Lada >> > > > >> > >> > > > >> > > >> > > > >> > > >> > > > >> > > However, since the key for the >> > > control-plane-protocol list is >> > > > "type >> > > > >> > > name", won't it only work if the >> previous sibling >> > > has a "name" >> > > > that >> > > > >> > > is precedes the one being added? >> > > > >> > > >> > > > >> > > For each list entry that has this >> container, the >> > > expression is >> > > > >> > > evaluated. It will scan all preceding >> entries >> > > and ensure that there >> > > > >> > > are none with this type. So the order >> of the >> > > entries doesn't >> > > > matter; >> > > > >> > > if there are two with the same type, >> one of them >> > > has to be >> > > > before the >> > > > >> > > other. >> > > > >> > > >> > > > >> > > >> > > > >> > > /martin >> > > > >> > > >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > Thanks, >> > > > >> > > >> > > > >> > > > Acee >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > Lada >> > > > >> > > >> > > > >> > > > >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > Also note that I use >> derived-from-or-self >> > > instead of equality >> > > > for the >> > > > >> > > >> > > > >> > > > > identity. >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > /martin >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > Regards, >> > > > >> > > >> > > > >> > > > > > Reshad. >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > augment >> "/rt:routing/rt:control-plane- >> > > protocols/" >> > > > >> > > >> > > > >> > > > > > + >> "rt:control-plane-protocol" { >> > > > >> > > >> > > > >> > > > > > when "rt:type = ‘msdp’" >> { >> > > > >> > > >> > > > >> > > > > > description >> > > > >> > > >> > > > >> > > > > > "….”; >> > > > >> > > >> > > > >> > > > > > } >> > > > >> > > >> > > > >> > > > > > description "…."; >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > container msdp { >> > > > >> > > >> > > > >> > > > > > when "../rt:name = >> > > ‘msdp-protocol’" { >> > > > >> > > >> > > > >> > > > > > description >> > > > >> > > >> > > > >> > > > > > "…."; >> > > > >> > > >> > > > >> > > > > > } >> > > > >> > > >> > > > >> > > > > > description "MSDP top >> level >> > > container."; >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > From: "Reshad Rahman >> (rrahman)" < >> > > rrahman@cisco.com> >> > > > >> > > >> > > > >> > > > > > Date: Monday, February 5, >> 2018 at 6:25 >> > > PM >> > > > >> > > >> > > > >> > > > > > To: Xufeng Liu < >> Xufeng_Liu@jabil.com>, >> > > > >> > "zhang.zheng@zte.com.cn" >> > > > >> > > >> > > > >> > > > > > <zhang.zheng@zte.com.cn> >> > > > >> > > >> > > > >> > > > > > Cc: "anish.ietf@gmail.com" < >> > > anish.ietf@gmail.com>, >> > > > "Mahesh >> > > > >> > Sivakumar >> > > > >> > > >> > > > >> > > > > > (masivaku)" < >> masivaku@cisco.com>, >> > > > "guofeng@huawei.com" >> > > > >> > > >> > > > >> > > > > > <guofeng@huawei.com>, >> > > > "pete.mcallister@metaswitch.com" >> > > > >> > > >> > > > >> > > > > > < >> pete.mcallister@metaswitch.com>, >> > > > "liuyisong@huawei.com" >> > > > >> > > >> > > > >> > > > > > <liuyisong@huawei.com>, " >> > > xu.benchong@zte.com.cn" >> > > > >> > > >> > > > >> > > > > > <xu.benchong@zte.com.cn>, >> > > "tanmoy.kundu@alcatel- >> > > > >> > lucent.com" >> > > > >> > > >> > > > >> > > > > > < >> tanmoy.kundu@alcatel-lucent.com>, >> > > > >> > "zzhang_ietf@hotmail.com" >> > > > >> > > >> > > > >> > > > > > <zzhang_ietf@hotmail.com>, >> "Acee >> > > Lindem (acee)" >> > > > >> > <acee@cisco.com> >> > > > >> > > >> > > > >> > > > > > Subject: Re: Hi all, about the >> > > modification of MSDP YANG >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > Hi Sandy and Xufeng, >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > I understand that you want >> only 1 MSDP >> > > instance but I >> > > > don’t think >> > > > >> > > that >> > > > >> > > >> > > > >> > > > > > justifies >> /rt:routing/rt:control-plane-protocols. >> > > If we do >> > > > that we >> > > > >> > > >> > > > >> > > > > > will end up with all >> single-instance >> > > protocols under >> > > > >> > > >> > > > >> > > > > > /rt:routing/rt:control-plane-p >> rotocols >> > > and all the multi- >> > > > instance >> > > > >> > > ones >> > > > >> > > >> > > > >> > > > > > under >> > > > >> > > >> > > > >> > > > > > /rt:routing/rt:control-plane- >> > > protocols/rt:control-plane- >> > > > protocol. >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > I am not sure what’s the best >> way to >> > > enforce single- >> > > > instance, I can >> > > > >> > > >> > > > >> > > > > > check with the other YDs on >> this topic.. >> > > One way it can be >> > > > done is >> > > > >> > as >> > > > >> > > >> > > > >> > > > > > follows (I’ve added the when >> statement >> > > in bold to >> > > > existing BFD >> > > > >> > > model), >> > > > >> > > >> > > > >> > > > > > it enforces that the protocol >> name is >> > > ‘bfdv1’. So multiple >> > > > >> > instances >> > > > >> > > >> > > > >> > > > > > with rt:type=bfd-types:bfdv1 >> could be >> > > created, but only >> > > > one of >> > > > >> > these >> > > > >> > > >> > > > >> > > > > > instances can have the bfd >> container. >> > > This is probably not >> > > > the >> > > > >> > best >> > > > >> > > >> > > > >> > > > > > way but the point is that IMO >> protocols >> > > have to go under >> > > > >> > > >> > > > >> > > > > > /rt:routing/rt:control-plane- >> > > protocols/rt:control-plane- >> > > > protocol. >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > Regards, >> > > > >> > > >> > > > >> > > > > > Reshad. >> > > > >> > > >> > > > >> > > > > > >> > > > >> > > >> > > > >> > > > > > augment >> "/rt:routing/rt:control-plane- >> > > protocols/" >> > > > >> > > >> > > > >> > > > > > + >> "rt:control-plane-protocol" { >> > > > >> > > >> > > > >> > > > > > when "rt:type = > >
- Re: [pim] [yang-doctors] Optional key support? Andy Bierman
- Re: [pim] [yang-doctors] Optional key support? Andy Bierman
- Re: [pim] [yang-doctors] Optional key support? Andy Bierman
- Re: [pim] [yang-doctors] Optional key support? Andy Bierman
- Re: [pim] [yang-doctors] Optional key support? Ladislav Lhotka
- Re: [pim] [yang-doctors] Optional key support? Martin Bjorklund