Alex,
On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" <[email protected]> wrote:
Hi Kent,
I do think that we should have a slot for that draft as well. The
structural mount case is a variation of the alias mount case;
Insofar as much that Structural mount and YSDL both have a model that is
used to control their mount functions there is similarity, but there is a
fundamental difference that the other documents cover a schema being
mounted not a datastore. Scheme mount is really a better term than
structural mount...
Also for our use case we don't want to use a different/ additional model.
That said covering alias and remote mount if there is time in the interim
would be fine with me, but not at the expense of identifying a preferred
approach of enabling the same amount that we are making use of in our draft.
Lou
it is certainly possible to have a continuum of solutions that allows to
incorporate structural mount as well as alias mount and peer mount (the
latter possibly at a later point).
At the core in each case is the “mountpoint” construct / YANG extension,
which was first introduced in the peer-mount draft and which also appears
in the structured-mount draft. In peer-mount, we also introduced two
additional arguments/ extension in addition: the subtree (used for alias
mount), and the target (for peer mount – building on top, for when it is
required). In the discussions since, it became clear that there is also a
use case where you don’t need an alias, where it is sufficient to just
mount a module and instantiate it right under the mount point. This is the
case that Martin put in his draft. So, there is really a continuum: a case
of a mountpoint with no argument (structural mount - the new draft), with
one argument (alias), and with two (peer) (the earlier draft).
--- Alex
-----Original Message-----
From: Kent Watsen [mailto:[email protected]]
Sent: Wednesday, February 03, 2016 11:27 AM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email protected]>
Cc: Lou Berger <[email protected]>; netmod WG <[email protected]>; Alexander
Clemm (alex) <[email protected]>; Eric Voit (evoit) <[email protected]>
Subject: Re: [netmod] Yang mount / ysdl example use case
I was led to believe that the current set of drafts subsume
draft-clemm-netmod-mount. If that’s not true, then absolutely there should
be a slot for that draft to be discussed as well. Please advise.
Kent
On 2/3/16, 9:07 AM, "Robert Wilton" <[email protected]> wrote:
Hi Kent,
There is also another Yang Mount related draft:
draft-clemm-netmod-mount-03
Now, this draft doesn't directly address the RTG DT Arch team use-case,
and seems to cover two more complex problem scenarios (remote mount and
alias mount), but these do appear to be a valid mount use cases (e.g. I
think that it is used by OpenDaylight SDN controller), and I know that
there is at least one implementation of this draft.
So, I want to echo Eric Voit's comments that it would be good if
whatever basic YANG mount draft we converge on is able to be cleanly
extended to cover the more complex mount scenarios.
As such, if Alex Clemm or Eric Voit are willing, I think that it would
be useful if one of them could comment on how feasible it is to extend
either netmod-structual-mount or netmod-ysdl to cover the remote mount
and alias mount scenarios described in draft-clemm-netmod-mount-03.
Hence, if they agree, do you think that you would be able to add a 15
min slot to the agenda to cover this please?
Thanks,
Rob
On 03/02/2016 02:24, Kent Watsen wrote:
[Chair hat on]
Given the number of competing/complementing drafts involved, and the
general lack of discussion on any of them, a virtual interim meeting might
be an expedient way to proceed. In fairness, we know that there has been
some discussion, but it hasn’t been picked up yet in a big way, and now Lou
has an updated draft.
The chairs discussed maybe scheduling one for a couple weeks from now,
perhaps Thursday Feb 18 starting at 10am EST? I'm thinking about this
slot only since it worked for us for previously. Is this a good time slot?
I assume to schedule for 2 hours, with a plan to end early if needed -
makes sense? We also need to put together a proper agenda, perhaps the
following?
10 min: RTG DT YANG Arch team use-case summary
20 min: draft-rtgyangdt-rtgwg-device-model
20 min: draft-lhotka-netmod-ysdl
20 min: draft-bjorklund-netmod-structural-mount
50 min: general discussion or end early
We hope to schedule the meeting itself tomorrow or the next day, so please
respond quickly to this email if possible.
Thanks,
Kent and Tom
On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
<[email protected] on behalf of [email protected]> wrote:
I thought it would be worth summarizing what we're looking for in
our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version
in case you missed it) with respect to the draft-lhotka-netmod-ysdl
and draft-bjorklund-netmod-structural-mount drafts. This is just my
view, so my co-authors may wish to chime in and correct me.
I'd be interested in hearing from the authors of YSDL and
structural-mount, or anyone else for that matter, on how they see to
best meet these needs.
Here's what I think our draft needs:
1. that there be a mechanism that allows the incorporation (or
'mounting') of the data model defined by one top-level module
within another module.
The implication here is that when information is instantiated
for the parent model it is also instantiated for the
incorporated/mounted model. In our case we expect to do this on
list element creation. Both solutions drafts cover the path
implications, so these are not repeated here.
2. that this mechanism allow identification of specific modules to
be incorporated/mounted at time of module definition, i.e. that
no additional module is needed to support 1. This doesn't
preclude definition of such a module.
3. that this mechanism allow for a server to control (and
identify) which modules are incorporated/mounted. (see Section
3 LNE in our draft for an envisioned usage.)
4. that all capabilities that exist with the mounted module are
available e.g. RPC operations and notifications.
5. while our primary requirement is for 'mounting' of top level
modules, mounting of submodules may also be useful. (DT not draft
driven.)
We make use of the above in sections 3 and 4 of rtgwg-device-model.
We see having a solution as critical for the
simplifications/flexibility represented in the -02 version of our
draft vs the -03 rev. We don't see wither solution draft as
significantly different and just hope for a standard solution as
soon as possible. (a draft-ietf-netmod solutions draft on the topic
by BA would be fantastic given the impact on routing area -- even if
it had to document two variations / alternative solutions.)
Again, this is just my opinion and my coauthors or others on the rtg
area yang DT may choose to chime in.
Lou
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
