Re: [netmod] schema mount and YANG library

Robert Wilton <rwilton@cisco.com> Tue, 16 January 2018 12:41 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DED12DB6D for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 04:41:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 XpiHo2n90933 for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 04:41:23 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9B912711B for <netmod@ietf.org>; Tue, 16 Jan 2018 04:41:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14431; q=dns/txt; s=iport; t=1516106482; x=1517316082; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KCbVMsgnQTPnkRQGbs7lGXDmF9L5DLbW2rw6p7Duz2M=; b=DV5Pf2QTwNLC8l2C5680E08kLJv497BA72zfjx0HX2OLc/o9j5TjnA0w Px2SVqwnEJrdHncvDUTDEDXthIs44uwt+IztbHQ8niH3Pph3hEDiBhU8/ WVUYNxD3ZQ/JczgyAE/GaN+Wh0r9AHoLLClRyE2Weyx0Fug0RYe9BhN5l 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B0AQBs8l1a/xbLJq1cGQEBAQEBAQEBAQEBAQcBAQEBAYQndCeEE4sYj26ZQgoYC4RJTwKFHhQBAQEBAQEBAQFrKIUjAQEBAQIBAQEhDwEFNgsQCxIGAgImAgInIg4GAQwGAgEBF4oQCBClb4IniUkBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhxmBaSmDBYMvAQECgU8BAQhCgmuCZQWSJ5E9iziKE4IZhh2DbyaHRY8ciAmBPDYigVAyGggbFT2CKoRXQTeLA4I8AQEB
X-IronPort-AV: E=Sophos;i="5.46,368,1511827200"; d="scan'208";a="1478661"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 12:41:18 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0GCfHPr029061; Tue, 16 Jan 2018 12:41:18 GMT
To: Ladislav Lhotka <lhotka@nic.cz>, Lou Berger <lberger@labn.net>, Martin Bjorklund <mbj@tail-f.com>
Cc: NETMOD WG <netmod@ietf.org>
References: <1512747137.3467.71.camel@nic.cz> <87zi6kay8b.fsf@nic.cz> <30ba994a-96b5-880c-ea43-b67469933a94@labn.net> <1513663919.478.7.camel@nic.cz> <1606e810770.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1513682591.2479.20.camel@nic.cz> <e8830510-e9ef-2179-8c83-763ce379777d@labn.net> <1513686995.2479.41.camel@nic.cz> <1cd9a729-d3ea-92e4-8954-bfb2c5a12424@labn.net> <1513690008.2479.70.camel@nic.cz> <3d436446-20d0-812e-134d-d148c8fcf2c0@labn.net> <1516086847.3188.24.camel@nic.cz>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <a8777c7c-a5bb-a0ea-ff6a-e57acd5fdc8e@cisco.com>
Date: Tue, 16 Jan 2018 12:41:17 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <1516086847.3188.24.camel@nic.cz>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kxjTGTDVeWJNAC5raUUvzqSYomU>
Subject: Re: [netmod] schema mount and YANG library
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 12:41:26 -0000


On 16/01/2018 07:14, Ladislav Lhotka wrote:
> Hi Lou,
>
> in my view, we should do the following two (significant) changes:
>
> 1. Instead of borrowing a grouping from ietf-yang-library and having a parallel
> list of mounted schemas, we should keep *all* mounted schemas directly in the
> YANG library and refer to them from schema-mounts structures. Juergen suggested
> this change and it is IMO the right thing to do.
I also support this approach.  I think that it easier for everyone if 
schema are defined in one place.

This was also the suggested approach that I presented at IETF 100 for 
the YANG library bis draft, which seemed to have reasonable support in 
the room, and I don't recall anyone objecting to this approach.

I also provided the same comment in November during the WG LC on schema 
mount ...

Thanks,
Rob


>
> 2. Define a metadata annotation (e.g. @schema-ref) that would be required for
> inline mount point instances and specify the inline-mounted schema also by
> referring to a schema specified in YANG library.
>
> The advantage of #2 is that an annotation can be attached equally well to both
> state an configuration data. So, instead of papering over the issue that YANG
> library (state data) cannot appear in configuration datastores, we can use this
> general and straightforward approach. This also allows for defining different
> mounted schemas for instances of the same mount point in different datastores.
>
> I strongly believe that these changes (along with the new YANG library schema
> and NMDA) make for a simple and elegant datastore architecture in which schema
> mount would be an optional feature.
>
> Lada
>
>   
>
> On Mon, 2018-01-15 at 16:20 -0500, Lou Berger wrote:
>> Lada/Martin,
>>
>> I don't believe we reached closure on this discussion.  The open issues
>> relate to proposed new text (slightly modified):
>>
>> at the end of the section [3.2] adding a new paragraph along the
>> lines of:
>>
>>     The use of mount points does not impact the nature of the
>>     mounted data or in which data store information is made
>>     available. For example, mounted YANG Library modules define
>>     only operational state data and, as such, the information in
>>     these modules is available from operational data stores using
>>     the appropriate protocol operations.  It is also worth
>>     noting that the Schema Mount module itself parallels the
>>     YANG Library module and only defines operational state data.
>>
>> Is this change acceptable?
>>
>> What other issues related to SM are outstanding?
>>
>> Thank you,
>>
>> Lou
>>
>> On 12/19/2017 8:26 AM, Ladislav Lhotka wrote:
>>> On Tue, 2017-12-19 at 07:49 -0500, Lou Berger wrote:
>>>> On 12/19/2017 7:36 AM, Ladislav Lhotka wrote:
>>>>> On Tue, 2017-12-19 at 06:43 -0500, Lou Berger wrote:
>>>>>> Hi Lada,
>>>>>>
>>>>>> On 12/19/2017 6:23 AM, Ladislav Lhotka wrote:
>>>>>>> On Tue, 2017-12-19 at 06:20 -0500, Lou Berger wrote:
>>>>>>>> Lada,
>>>>>>>>
>>>>>>>>
>>>>>>>> On December 19, 2017 1:12:35 AM Ladislav Lhotka <lhotka@nic.cz>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
>>>>>>>>>> lada,
>>>>>>>>>>
>>>>>>>>>>       See below.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> unfortunately, using an action for querying embedded YANG
>>>>>>>>>>> library
>>>>>>>>>>> data
>>>>>>>>>>> (needed for the "inline" case of schema mount) doesn't work
>>>>>>>>>>> either
>>>>>>>>>>> because now under NMDA actions can be used only on instances
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> <operational> datastore.
>>>>>>>>>> but the inline/embedded library would (only) be present in the
>>>>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>> operational datastore, so what's the issue?
>>>>>>>>> Well, the issue is described in my initial mail of this thread:
>>>>>>>>> the
>>>>>>>>> current
>>>>>>>>> text
>>>>>>>>> requires that every instance of an inline mount point contains
>>>>>>>>> the
>>>>>>>>> embedded
>>>>>>>>> YANG library. Tha latter is state data, so the above requirement
>>>>>>>>> cannot
>>>>>>>>> be
>>>>>>>>> satisfied if the mount point instance is in a configuration
>>>>>>>>> datastore.
>>>>>>>>>
>>>>>>>> That's not how I read the intent of the current text.  I don't see
>>>>>>>> SM
>>>>>>>> impacting which data stores information is presented.  Just like
>>>>>>>> use
>>>>>>>> of
>>>>>>>> scheme mount doesn't transform RO configuration information into
>>>>>>>> operational information.  I sent you a couple of sentences
>>>>>>>> clarifying
>>>>>>>> this
>>>>>>>> at one point, I'll dig up the proposed text and resend.
>>>>>>> Please do, this has to be discussed in the WG mailing list.
>>>>>> Agreed - that's why I asked to start this thread!
>>>>>>
>>>>>> Here's the original proposal:
>>>>>>
>>>>>>     How about at the end of the section [3.2] adding a new
>>>>>>     paragraph along the lines of:
>>>>>>
>>>>>>     It is important to note that both YANG Library and Schema
>>>>>>     Mount Modules contain only operational state data. As such,
>>>>> s/contain/define/
>>>>>
>>>>>>     the information in these modules should be retrieved by
>>>>>>     clients from operational data stores using the appropriate
>>>>> This is based on two assumptions:
>>>>>
>>>>> 1. For every configuration datastore there is a corresponding
>>>>> operational
>>>>> datastore.
>>>> well the text is revised below.  In any case, "these modules" refers to
>>>> yang library, and yes, I'm assuming YL is always and only in
>>>> operational.  If the revised text below isn't clear s/these/YANG Library/
>>>> -
>>> The thing is that we have the top-level YANG library in <operational>, and
>>> then
>>> embedded YANG libraries scattered inside inline mount point instances.
>>>
>>>>> 2. For every mount point instance in any configuration datastore there
>>>>> is a
>>>>> corresponding mount point instance (with the same path) in an
>>>>> operational
>>>>> datastore.
>>>>>
>>>>> I think that neither of these has to be true in general.
>>>> agreed in general, but for inline, where YL is required, it must be true.
>>> How do you know? I provided an example in Singapore where a mount point
>>> instance
>>> in <intended> is a part of pre-provisioned data (for non-existent hardware).
>>> Then, according to the NMDA rules there is no corresponding instance in
>>> <operational>, hence no place where the embedded YANG library can be placed.
>>> (I can easily provide a concrete example if needed).
>>>
>>>
>>> Dean replied that this cannot happen, so it seems there are some assumptions
>>> how
>>> the inline method of schema mount may be applied. If so, these assumptions
>>> have
>>> to be explicitly stated.
>>>
>>>>>>     protocol operations.
>>>>> In contrast, the substance of my proposal with metadata annotations is
>>>>> to be
>>>>> able to retrieve all schemas from a well-known location in *the*
>>>>> <operational>
>>>>> datastore, namely from the top-level YANG library.
>>>> What about a schema that is based on dll that contains modules that
>>>> isn't loaded until a mount point is instantiated -- this is certainly a
>>>> valid approach for supporting LNEs, but would be precluded in this
>>>> approach.  I really don't think a top level approach works for all
>>>> inline (managed) types of mounts.
>>> It isn't precluded: when the mount point is instantiated (no matter which
>>> datastore it is in), the server adds the schema as a new entry to the
>>> "schema"
>>> list in the top level YANG library (with a unique key), and annotates the
>>> mount
>>> point instance with a leafref pointing to that key. So different instances
>>> of
>>> the same mount point can have different schemas.
>>>
>>>>>> Given this discussion, we can generalize it further to:
>>>>>>
>>>>>>     The use of mount points does not impact the nature of the
>>>>>>     mounted data or in which data store information is made
>>>>>>     available. For example, mounted YANG Library modules contain
>>>>>>     only operational state data and, as such, the information in
>>>>>>     these modules is available from operational data stores using
>>>>>>     the appropriate protocol operations.
>>>>> The whole question here is whether and how we can locate the schema for
>>>>> an
>>>>> inline mount point in any configuration datastore.
>>>> Why is a mounted YL different than a top level YL?  What works for and
>>> It is not different, but it can be only in an operational datastores, and so
>>> for
>>> mount point instances inside configuration datastores we need a way how to
>>> locate the schema for that mount point, because it cannot be found directly
>>> under the mount point instance (as the current text assumes).
>>>
>>>> is sufficient for the normal case of YL shouldn't be impacted or
>>>> modified by SM -- at least that's how I thought we've been talking about
>>>> since SM was started.  Again, we never made any special provisions for
>>>> any other rw/ro/state data, assuming top level YL is not handled as
>>>> metadata, why start now?
>>>>
>>>> I'm getting the impression that your argument may be more about if YL
>>>> should be treated as something other than operational data, is this wrong?
>>> This is wrong. My argument is that there should be only one top-level YANG
>>> library (state data) and each inline mount point instance just points to a
>>> schema inside it by means of a metadata annotation attached to the mount
>>> point
>>> (in any datastore).
>>>
>>> Lada
>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>>> Lada
>>>>>
>>>>>> Lou
>>>>>>
>>>>>>> Lada
>>>>>>>
>>>>>>>> Lou
>>>>>>>>>>> However, a good alternative seems to be a metadata
>>>>>>>>>>> annotation
>>>>>>>>>>> along
>>>>>>>>>>> the
>>>>>>>>>>> lines of RFC 7952, for example with the alternative B of the
>>>>>>>>>>> newly
>>>>>>>>>>> proposed YANG library schema:
>>>>>>>>>>>
>>>>>>>>>>>        md:annotation schema-ref {
>>>>>>>>>>>          type leafref {
>>>>>>>>>>>            path "/yanglib:yang-
>>>>>>>>>>> library/yanglib:schema/yanglib:name";
>>>>>>>>>>>          }
>>>>>>>>>>>        }
>>>>>>>>>>>
>>>>>>>>>>> In other words, all inline mounted schemas would be included
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> top-level YANG library, and mount point instances in all
>>>>>>>>>>> datastores
>>>>>>>>>>> would be annotated with leafref pointing to the actual
>>>>>>>>>>> schema.
>>>>>>>>>>>
>>>>>>>>>>> Unlike regular state data, it is IMO no problem to permit
>>>>>>>>>>> such
>>>>>>>>>>> annotations in configuration datastores.
>>>>>>>>>>>
>>>>>>>>>>> Opinions?
>>>>>>>>>> I'm not sure this will work for all architectures of LNEs as
>>>>>>>>>> well
>>>>>>>>>> as
>>>>>>>>>> other possible future use cases.  In short, this seems *very*
>>>>>>>>>> restrictive.
>>>>>>>>> I don't understand, IMO it is not restrictive at all. What kind
>>>>>>>>> of
>>>>>>>>> restrictions
>>>>>>>>> do you see?
>>>>>>>>>
>>>>>>>>> Lada
>>>>>>>>>
>>>>>>>>>> Lou
>>>>>>>>>>
>>>>>>>>>>> Thanks, Lada
>>>>>>>>>>>
>>>>>>>>>>> Ladislav Lhotka <lhotka@nic.cz> writes:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> the following text in sec. 3.2 of schema-mount-08 is wrong
>>>>>>>>>>>> for
>>>>>>>>>>>> traditional
>>>>>>>>>>>> datastores, and even more so for NDMA:
>>>>>>>>>>>>
>>>>>>>>>>>>      In case 1 ["inline"], the mounted schema is determined
>>>>>>>>>>>> at
>>>>>>>>>>>> run
>>>>>>>>>>>> time:
>>>>>>>>>>>> every
>>>>>>>>>>>>      instance of the mount point that exists in the parent
>>>>>>>>>>>> tree
>>>>>>>>>>>> MUST
>>>>>>>>>>>>      contain a copy of YANG library data [RFC7895] that
>>>>>>>>>>>> defines
>>>>>>>>>>>> the
>>>>>>>>>>>>      mounted schema exactly as for a top-level data
>>>>>>>>>>>> model.  A
>>>>>>>>>>>> client
>>>>>>>>>>>> is
>>>>>>>>>>>>      expected to retrieve this data from the instance tree,
>>>>>>>>>>>> possibly
>>>>>>>>>>>> after
>>>>>>>>>>>>      creating the mount point.  Instances of the same mount
>>>>>>>>>>>> point
>>>>>>>>>>>> MAY
>>>>>>>>>>>> use
>>>>>>>>>>>>      different mounted schemas.
>>>>>>>>>>>>
>>>>>>>>>>>> An instance of the mount point in any *configuration*
>>>>>>>>>>>> datastores
>>>>>>>>>>>> cannot
>>>>>>>>>>>> contain
>>>>>>>>>>>> YANG library (being state data), and so the MUST cannot
>>>>>>>>>>>> hold.
>>>>>>>>>>>>
>>>>>>>>>>>> It is not clear to me how to repair this without
>>>>>>>>>>>> considerable
>>>>>>>>>>>> complications
>>>>>>>>>>>> and/or a lot of handwaving. There is actually one good
>>>>>>>>>>>> solution
>>>>>>>>>>>> but it
>>>>>>>>>>>> has
>>>>>>>>>>>> impact on YANG library: the server could provide it in a
>>>>>>>>>>>> reply
>>>>>>>>>>>> to
>>>>>>>>>>>> an
>>>>>>>>>>>> operation,
>>>>>>>>>>>> say "get-yang-library" rather than as state data. Then
>>>>>>>>>>>> everything
>>>>>>>>>>>> would be
>>>>>>>>>>>> fine
>>>>>>>>>>>> - this operation would turn into an action for the mount
>>>>>>>>>>>> point,
>>>>>>>>>>>> and it
>>>>>>>>>>>> can
>>>>>>>>>>>> be
>>>>>>>>>>>> used equally well for config true and false mount points.
>>>>>>>>>>>>
>>>>>>>>>>>> So my proposal is to move from YANG library as state data
>>>>>>>>>>>> to
>>>>>>>>>>>> an
>>>>>>>>>>>> operation.
>>>>>>>>>>>> It
>>>>>>>>>>>> could be done along with changing the YANG library
>>>>>>>>>>>> structure,
>>>>>>>>>>>> so
>>>>>>>>>>>> there
>>>>>>>>>>>> will be
>>>>>>>>>>>> little extra impact on implementations.
>>>>>>>>>>>>
>>>>>>>>>>>> Lada
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ladislav Lhotka
>>>>>>>>>>>> Head, CZ.NIC Labs
>>>>>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> netmod mailing list
>>>>>>>>>>>> netmod@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netmod mailing list
>>>>>>>>>> netmod@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>> --
>>>>>>>>> Ladislav Lhotka
>>>>>>>>> Head, CZ.NIC Labs
>>>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>>>>
>>