On 1/16/2018 11:15 AM, Robert Wilton wrote:
On 16/01/2018 15:50, Martin Bjorklund wrote:
Lou Berger <lber...@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.
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. 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. 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
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
