Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Christian Hopps <[e-mail]>]

Martin Bjorklund <[e-mail]> writes:

> Hi,
>
> Christian Hopps <[e-mail]> wrote:
>>
>> Hi Rob,
>>
>> You do realize that no-one trying to actually deploy and run networks
>> cares about live-discovery of different schema per datastore for the
>> same mount point right? Like 99.999% of the clients know where things
>> are supposed to reside and expect them to be there.
>
> But then why advertise anything at all?   We can do a *much* simpler
> solution by just having the mountpoint extension, and nothing else.
> Clients will know what to find anyway.

That was the idea Lou and I brought up over 2 *years* ago, yes. :)

But good points were made for something more general and powerful, and we all agreed with those, so..

> My experience, which may differ from yours, is that correct knowledge
> about the devices' datamodels and revisions is crucial for correct
> implementation of automation of network services.  The application
> programmer can program the intent for some set of data models, and
> then the orchestrator can automatically decide what to do for a given
> device depending on which data models it advertises.

and that's why we have a module list present in the work now ready to publish. It's enough for now. Perfect is killing good enough here.

Thanks,
Chris.

>
>
>
> /martin
>
>
>
>
> At most (although
>> still not common) they may want to know what modules are supported
>> under a mount point. What your talking about is a severe edge case
>> that apparently has achieved extreme importance in a very small group
>> of people's views.
>>
>> Thanks,
>> Chris.
>>
>> Robert Wilton <[e-mail]> writes:
>>
>> > Hi Chris,
>> >
>> > I've got no desire or intent to try and slow down the NI and LNE
>> > drafts, or any
>> > that depend on them. I actually agree that this is critically
>> > important that
>> > IETF gets modules standardized/finished so that everyone can use them.
>> >
>> > However, ...
>> >
>> > YLbis has quite a different structure to YL. The main part of this
>> > change was
>> > to support NMDA, the other part of this change was to better support
>> > things like
>> > SM, or YANG packages.
>> >
>> > I don't think that there is a clean, backwards compatible, way to go
>> > from the
>> > YANG module in SM -08 to one that is going to work well with YLbis and
>> > other
>> > YLbis extensions/augmentations that seem to be coming down the
>> > line. Given what
>> > we know now, I believe that the correct medium/long term structure for
>> > the SM
>> > YANG module, taking YLbis into account, is the one proposed in pre09,
>> > because it
>> > directly augments the YLbis structure, and hence any future
>> > augmentations to
>> > YLbis should automatically extend to SM mounted schema as well.
>> >
>> > I think that the likely future technical issues with the -08 module
>> > will be:
>> > - supporting NMDA in a clean consistent way
>> > - adding in support for SemVer
>> > - additional capability reporting as an augmentation to YANG library
>> >
>> > So, if -08 proceeds as is, then it seems to me like one of three
>> > things will
>> > need to happen:
>> > 1) Their will need to be a non backwards compatible update to the SM
>> > model that
>> > is the same/similar to pre09.
>> > 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
>> > explicitly
>> > mounted schema.
>> > 3) We accrue technical debt, implementations need to support two YL
>> > module
>> > structures, the one in SM and the one in YLbis, and future extensions
>> > need to
>> > augment both the SM structure and YLbis structure.
>> >
>> > I don't like the idea of (2) or (3), but I don't know if others will
>> > find (1)
>> > acceptable.
>> >
>> > But I do agree that we are just going round in circles on this:
>> > - Using the pre09 structure is not acceptable to some folks
>> > - Publishing a draft with both -08 and pre09 structure is liked by even
>> > - less
>> > folks.
>> >
>> > Perhaps publishing -08 is the only option. My hope is that the WG will
>> > support
>> > somebody subsequently doing solution (1), otherwise it seems like a
>> > missed
>> > opportunity to get this right.
>> >
>> > Thanks,
>> > Rob
>> >
>> >
>> > On 24/02/2018 13:54, Christian Hopps wrote:
>> >> My position,
>> >>
>> >> It may be the case that there's even a better cleaner solution;
>> >> however, it's
>> >> simply too late for major modifications to this work that don't
>> >> actually
>> >> address functional failures. The draft as proposed works for the
>> >> people who
>> >> need to get work done.
>> >>
>> >> We have multiple pending RFCs - MISREF on this document. These RFCs
>> >> would have
>> >> to be pulled from the RFC EDITOR queue, and reworked to be compliant
>> >> again,
>> >> and this very well could lead to discovering issues with your new
>> >> proposal.
>> >> Any new issues discovered in either the pending RFCs *or* in the new
>> >> solution
>> >> would then need to be worked out and fixed. Please recall that this
>> >> actually
>> >> occurred on the first round (i.e., doing the examples led to
>> >> discovering
>> >> problems with the drafts), so it's not unreasonable at all to assume
>> >> this
>> >> would happen again.
>> >>
>> >> Look this just isn't a simple change your proposing. It involves a
>> >> large
>> >> upheaval, killing the pending RFC status on multiple documents that
>> >> the
>> >> industry is waiting on. Please see this.
>> >>
>> >> Thanks,
>> >> Chris.
>> >>
>> >>
>> >> Martin Bjorklund <[e-mail]> writes:
>> >>
>> >>> Hi,
>> >>>
>> >>> Robert Wilton <[e-mail]> wrote:
>> >>>> Hi Lou,
>> >>>>
>> >>>> I think that this solution is inferior to the model presented in
>> >>>> pre-09.
>> >>>
>> >>> I agree. Servers that are NMDA-compliant, or implements YANG Library
>> >>> bis will have to present schemas in two different structures,
>> >>> depending on where the schema is used, and clients will have to code
>> >>> for both. With the solution in pre-09, there is just one structure.
>> >>> A single structure also has other benefits (apart from being simpler),
>> >>> e.g., if we augment it with the meta data that has been discussed
>> >>> recently, we can augment a single structure.
>> >>
>> >>> /martin
>> >>>
>> >>>
>> >>>
>> >>>> I would prefer that we publish pre09 instead, potentially including
>> >>>> the -08 model in the appendix if that helps progress the document in a
>> >>>> more expedient fashion.
>> >>>>
>> >>>> Thanks,
>> >>>> Rob
>> >>>>
>> >>>>
>> >>>> On 22/02/2018 16:18, Lou Berger wrote:
>> >>>> > Hi,
>> >>>> >
>> >>>> > (I have a bunch of different roles WRT this work. This mail is being
>> >>>> > sent as an individual - as chair, I fully support the previous chair
>> >>>> > statements on this draft.)
>> >>>> >
>> >>>> > Chris and I have come up with a proposal on how to provide full NMDA
>> >>>> > as part the existing schema-mount module. Our motivation was to
>> >>>> > enable full NMDA support with *minimal* change to the model and
>> >>>> > disruption to the LC'ed work. The key NMDA limitation, with -08, that
>> >>>> > we are aiming to address is the ability to support different mounted
>> >>>> > schema in different datastores for non-inline mount points. (See more
>> >>>> > detailed description below if interested full nuances of limitations
>> >>>> > of -08)
>> >>>> >
>> >>>> > What we came up with was to simply add a (leaf)list to identify in
>> >>>> > which datastores a
>> >>>> > schema-mount schema is valid/present. This is somewhat similar to
>> >>>> > YL-bis schema/module-set. Specifically we're proposing (see below for
>> >>>> > full tree below):
>> >>>> >
>> >>>> > +--ro schema* [name]
>> >>>> > +--ro name string
>> >>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>> >>>> >
>> >>>> > This approach has the advantages of supporting different mounted
>> >>>> > schema in different DSes, working with both NMDA and non-NMDA
>> >>>> > implementations, supporting all of the extensively discussed features
>> >>>> > of schema mount (including recursive mounts), and having minor/scoped
>> >>>> > impact on all dependent work. The main downside is that it isn't the
>> >>>> > most optimal/compact solution possible if we were to base this work on
>> >>>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
>> >>>> > perspectives, but it is what was agreed to as sufficient by those who
>> >>>> > contribute to the WG discussion.
>> >>>> >
>> >>>> > In short, we see this as a solution to addresses the raised last call
>> >>>> > issue with the minimal impact on -08 and dependent work -- which is
>> >>>> > what is appropriate given where we are in the process.
>> >>>> >
>> >>>> > So our/my question really is:
>> >>>> >
>> >>>> > Is this a solution that you/all can live with?
>> >>>> >
>> >>>> > Note: optimization, design preference and perfect alignment with use
>> >>>> > or YL-bis are not part of our question as we both don't think that is
>> >>>> > the right question given where we are in the WG process.
>> >>>> >
>> >>>> > Lou (with ideas developed with Chris, and chair hat off)
>> >>>> >
>> >>>> > ======
>> >>>> > Details -- for those who want
>> >>>> > ======
>> >>>> > As background, my understanding/view is that the -08 version of the
>> >>>> > both NMDA and non-NMDA supporting implementations, but there are
>> >>>> > limitations in its NMDA applicability. Used with Yang Library,
>> >>>> > [rfc7895], only non-NMDA implementations can be supported. When used
>> >>>> > with the revised Yang Library defined in
>> >>>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>> >>>> > supported with certain limitations. Specifically, this document
>> >>>> > requires use of the now deprecated module-list grouping, and the same
>> >>>> > schema represented in schema list of the Schema Mount module MUST be
>> >>>> > used in all datastores. Inline type mount points, which don't use the
>> >>>> > schema list, can support different schema in different data stores
>> >>>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>> >>>> > YANG library under the inline mount point.
>> >>>> >
>> >>>> > module: ietf-yang-schema-mount
>> >>>> > +--ro schema-mounts
>> >>>> > +--ro namespace* [prefix]
>> >>>> > | +--ro prefix yang:yang-identifier
>> >>>> > | +--ro uri? inet:uri
>> >>>> > +--ro mount-point* [module name]
>> >>>> > | +--ro module yang:yang-identifier
>> >>>> > | +--ro name yang:yang-identifier
>> >>>> > | +--ro config? boolean
>> >>>> > | +--ro (schema-ref)?
>> >>>> > | +--:(inline)
>> >>>> > | | +--ro inline? empty
>> >>>> > | +--:(use-schema)
>> >>>> > | +--ro use-schema* [name]
>> >>>> > | +--ro name
>> >>>> > | | -> /schema-mounts/schema/name
>> >>>> > | +--ro parent-reference* yang:xpath1.0
>> >>>> > +--ro schema* [name]
>> >>>> > +--ro name string
>> >>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>> >>>> > +--ro module* [name revision]
>> >>>> > | +--ro name yang:yang-identifier
>> >>>> > | +--ro revision union
>> >>>> > | +--ro schema? inet:uri
>> >>>> > | +--ro namespace inet:uri
>> >>>> > | +--ro feature* yang:yang-identifier
>> >>>> > | +--ro deviation* [name revision]
>> >>>> > | | +--ro name yang:yang-identifier
>> >>>> > | | +--ro revision union
>> >>>> > | +--ro conformance-type enumeration
>> >>>> > | +--ro submodule* [name revision]
>> >>>> > | +--ro name yang:yang-identifier
>> >>>> > | +--ro revision union
>> >>>> > | +--ro schema? inet:uri
>> >>>> > +--ro mount-point* [module name]
>> >>>> > +--ro module yang:yang-identifier
>> >>>> > +--ro name yang:yang-identifier
>> >>>> > +--ro config? boolean
>> >>>> > +--ro (schema-ref)?
>> >>>> > +--:(inline)
>> >>>> > | +--ro inline? empty
>> >>>> > +--:(use-schema)
>> >>>> > +--ro use-schema* [name]
>> >>>> > +--ro name
>> >>>> > | -> /schema-mounts/schema/name
>> >>>> > +--ro parent-reference* yang:xpath1.0
>> >>>> >
>> >>>> > We would expect that the revised-datastores feature would be used
>> >>>> > (perhaps required) for any implementation that supports
>> >>>> > ietf-datastores
>> >>>> > and yl-bis.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > netmod mailing list
>> >>>> > [e-mail]
>> >>>> > https://www.ietf.org/mailman/listinfo/netmod
>> >>>>
>> >>>> _______________________________________________
>> >>>> netmod mailing list
>> >>>> [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/netmod
>> >>>
>> >>> _______________________________________________
>> >>> netmod mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/netmod
>> >>
>> >> .
>> >>
>>