Re: [netmod] schema mount and YANG library

Ladislav Lhotka <lhotka@nic.cz> Wed, 17 January 2018 06:59 UTC

Return-Path: <lhotka@nic.cz>
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 930771314D1 for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 22:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level:
X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 270zXldKEN7X for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 22:59:37 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C456512F49B for <netmod@ietf.org>; Tue, 16 Jan 2018 22:59:35 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3095:1bff:fe2b:aa11]) by mail.nic.cz (Postfix) with ESMTPSA id 6B0DF646B7; Wed, 17 Jan 2018 07:59:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1516172373; bh=L6Acca97Cui60TGyoNw2eIHJ8VGqjIDYRDWUIdAvlCY=; h=From:To:Date; b=P8DWN9g23lsPNRRtoYbh/5UkLCqgOOiA8q2zBH/w33F34FxMYAJR7uVX4VK7PNnWc evYXEk7a2BYLRTDmQmwzg0PW8i6PoBOMkHaRkDDnALDmUgfYYRVXrhKnCAYJB3ztVv dAmVrJ/0nnsMEWp0Doa0REzenmWPYYy+9Giz0UHU=
Message-ID: <1516172373.21945.16.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Wilton <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, lberger@labn.net
Cc: netmod@ietf.org
Date: Wed, 17 Jan 2018 07:59:33 +0100
In-Reply-To: <e2065948-f455-dfc7-b1ae-079331b6e626@cisco.com>
References: <53c046c7-bd41-4a4b-ef61-0d3bf9414269@labn.net> <20180116.161347.1518992717170489943.mbj@tail-f.com> <0d9b55b4-1377-34b9-442a-a94713e6ead1@labn.net> <20180116.165014.297580929914718463.mbj@tail-f.com> <e2065948-f455-dfc7-b1ae-079331b6e626@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/O9XDBsJoUFqDlVJ_jCc--9Gcf7k>
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: Wed, 17 Jan 2018 06:59:39 -0000

On Tue, 2018-01-16 at 16:15 +0000, Robert Wilton wrote:
> 
> On 16/01/2018 15:50, Martin Bjorklund wrote:
> > Lou Berger <lberger@labn.net> wrote:
> > > 
> > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > ... (trimming to topic)
> > > > > > > > > > > rejectected by the WG multiple times.  FWIW there are
> > > > > > > > > > > drafts already
> > > > > > > > > > > with
> > > > > > > > > > 
> > > > > > > > > > No at all. The first and last time I proposed this was on 15
> > > > > > > > > > December
> > > > > > > > > > 2017:
> > > > > > > > > > 
> > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg1975
> > > > > > > > > > 3.html
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Oh, I certainly would call you proposing that the schema for
> > > > > > > > > inline be
> > > > > > > > > part of the rest of the schema Mount module well before that.
> > > > > > > > > I'm sure
> > > > > > > > > I can dig up mail / slides it really necessary...
> > > > > > > > 
> > > > > > > > I don't think this has been proposed before.  All previous
> > > > > > > > proposals
> > > > > > > > were basically variants on what is now "use-schema", which works
> > > > > > > > fine
> > > > > > > > when all instances have the same schema.  This new proposal
> > > > > > > > solves the
> > > > > > > > issue with different schemas in different instances.
> > > > > > > > 
> > > > > > > 
> > > > > > > I thought the previous proposals that as well, so don't see
> > > > > > > material
> > > > > > > difference - at least from the usage standpoint. I also don't see
> > > > > > > why
> > > > > > > the previous arguments that resulted in consensus for using Yang
> > > > > > > Library underneath the an in line Mount Point don't apply.
> > > > > > 
> > > > > > B/c it doesn't work well with the NMDA.  You can't mount yang
> > > > > > library
> > > > > > in the configuration datastores; it has to be mounted in
> > > > > > operational.
> > > > > > With meta-data, you can actually report the correct schema even in
> > > > > > running.  (This is actually true also for pre-NMDA systems).
> > > > > > 
> > > > > 
> > > > > Understood and agree there is nothing new here and the current version
> > > > > of SM (including inline) has the same limitation as rfc7895, and I'd
> > > > > expect it to behave the same once we have rfc7985bis -- in fact the
> > > > > inline case "just works" with YL-bis as defined today.
> > > 
> > > Martin,
> > > 
> > > you didn't respond to this point.
> > 
> > I agree, it works for non-NMDA servers. But see below.
> > 
> > > > > The argument I recall being the key point on inline was handling the
> > > > > large variety of possible different implementation approaches for
> > > > > modules using inline.
> > > > 
> > > > I think these still are covered.
> > > > 
> > > > > For example an LNE that is implemented using
> > > > > VMs which can be managed by the host at different times of the VMs
> > > > > operational life cycle based on customer/provider requirements.  I
> > > > > really don't see how YL-bis has any bearing on this point and
> > > > 
> > > > Using the new proposed meta data annotation together with the new YL
> > > > means that SM can support the use case above also in an NMDA server.
> > > > I think the new proposed solution covers more use cases than the
> > > > previous solution.
> > > 
> > > how so?  The inline mount point would contain YL-bis and have the same
> > > information there, just scoped for the mount point.  It's true a
> > > client would need to understand the mount point's schema only upon
> > > parsing the YL under the mount point and this schema could not be
> > > shared across inline mount points.  But this is as was discussed in
> > > the past and unchanged from YL.
> > > 
> > > > Do you think that there is any use case that the proposed solution
> > > > cannot handle, but the previous solution did?
> > > 
> > > yes.  with VM/container technologies the YL / schema can change under
> > > the mount point from time to time during normal operation (i.e.,
> > > during runtime, no reboot) and, in some implementations, may require
> > > some level of rpc operation to access even the schema.  The new (and
> > > previously proposed approach) of having inline schema available from
> > > the top level greatly complicates these cases.  Also keep in mind that
> > > there will be cases where the ability to access information under an
> > > inline mount point will dynamically change in operation (and top level
> > > YL would need to remove schema information for the inline mount
> > > point.)  As before, from the usage standpoint, these changes don't
> > > provide a whole lot of value and seem to optimizing for something not
> > > needed in the inline case.
> > 
> > I think this is an implementation issue, rather than a problem with
> > the proposed mechanism, and it is present in the current solution as
> > well.  An implementation that can handle dynamically changing mounted
> > YLs in the current solution can do that in the new solution as well.
> > 
> > > > > I think
> > > > > it is incumbent upon those revisiting past/closed WG decisions (in
> > > > > this case, inline schema being represented by YL) to argue why the
> > > > > decision needs to be revisited.
> > > > 
> > > > I'm repeating my self: b/c the current solution doesn't work well with
> > > > the NMDA.
> > > 
> > > I simply don't understand how YL-bis works at the root node but
> > > doesn't work equally at an inline mount point.  Can you elaborate?
> > 
> > With NMDA, a server may have one schema for the config datastore and
> > another one for operational (one is a superset of the other).  A
> > mounted YL can only be present in operational.  Thus, there's no way a
> > client can learn the schema for config.
> 
> If the LNE mounted the full YL-bis at the mount point then you would 
> have the list of datastores, and the schema associated with each 
> datastore.  Of course, this would only be available in operational, but 
> that is the same as a regular server support YL-bis.

YL-bis is different in that it is in fact metadata even though we call it state
data. In any case, no matter what datastores the server has, YL-bis is the
single well-known location from which the schema of all datastores can be
retrieved.

We could refer to <operational> as the place from which the mounted schemas of
NMDA-standard config datastores can be retrieved (except for special cases, one
is discussed below). But if there is another config datastore (e.g. dynamic)
with an inline mount point instance, it is unclear where to look for the mounted
schema. With my proposal, the mount point instance will be annotated with
@schema-ref that points to a schema in the top-level YL.

> 
> I thought that the problem with the current solution and NMDA, was that 
> there is no way to find out what the LNE schema is if the LNE isn't 
> booted, and hence isn't providing <operational>.  But I'm not sure what 
> issues that actually causes.  E.g. does it cause issues with 
> pre-configuration of the LNE?

The issue that this causes is that the schema for the pre-configured LNE isn't
known and validity of <intended> is unclear.

Lada

> 
> Thanks,
> Rob
> 
> 
> > 
> > With the proposed solution, there can be different schema-ref pointers
> > in config and operational (if needed).
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > 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