Re: [netmod] schema mount and YANG library

Martin Bjorklund <mbj@tail-f.com> Wed, 17 January 2018 08:20 UTC

Return-Path: <mbj@tail-f.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 8B7CE12F4D0 for <netmod@ietfa.amsl.com>; Wed, 17 Jan 2018 00:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 121Ufpnwp2hW for <netmod@ietfa.amsl.com>; Wed, 17 Jan 2018 00:20:05 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EBB0912F4D8 for <netmod@ietf.org>; Wed, 17 Jan 2018 00:20:04 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id D2F601AE0385; Wed, 17 Jan 2018 09:20:02 +0100 (CET)
Date: Wed, 17 Jan 2018 09:20:02 +0100
Message-Id: <20180117.092002.464472752076487902.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net>
References: <20180116.165014.297580929914718463.mbj@tail-f.com> <e2065948-f455-dfc7-b1ae-079331b6e626@cisco.com> <754a4ce8-a3de-ad0b-03a4-0edc500f9cf3@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/yeR07_Uc5QPdJiQ5U6HA6-xYB74>
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 08:20:08 -0000

Lou Berger <lberger@labn.net> wrote:
> 
> 
> On 1/16/2018 11:15 AM, 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/msg19753.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.
> exactly my point.

Yes, you're right.  But it requires the usage of YL-bis.

> > 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>.
> I've never heard anyone mention this issue/limitation.

This has been dicussed, but this does not change with the introduction
of the meta annotation; if the server has off-line knowledge of the
instance's schema then it can populate an inline YL as well as the
meta annotation and corresponding SM data.

> My
> understanding of the previously raised objections were (a) that the
> full schema can't be obtained by just reading the top level YL and (b)
> that when multiple inline mount points have the same schema the
> information can't be combined using a shared schema approach as is
> taken in base SM.

Right.  Both these issues are addressed by using a meta annotation.


/martin


> Yes both increase client operations/work, but
> without incurring the server side implementation overhead that is
> implied in this approach.  -- Again, I don't see how YL-bis or NMDA
> changes any of this.
> 
> >   But I'm not sure what
> > issues that actually causes.  E.g. does it cause issues with
> > pre-configuration of the LNE?
> Assignment of host resources takes place at the root level, not the
> within the context of the inline mount point, other preprovisiong can
> be handled via the inline/managed mechanisms defined in the LNE
> module.  We looked at this in detail for multiple server/vendor
> implementations and agreed the current mechanisms work even if not
> optimal in all cases.
> 
> Lou
> 
> > 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
> >> .
> >>
> >
>