Rob,
On February 4, 2016 4:57:24 AM Robert Wilton <rwil...@cisco.com> wrote:
Hi,
I wasn't actually suggesting that Alex's YANG mount draft be considered
as a solution here. I think that this draft is probably sufficiently
complex that it would require a lot WG discussion and hence take too
long to standardize to meet the RTG DT requirements.
Hence, I envisage that we'll end up with two drafts:
1) A basic mount draft - based on either Martin's Structural Mount or
Lada's Ysdl drafts.
2) A revision of Alex's YANG mount draft that extends from the base
mount draft (1) above to cover alias and peer mount.
The meeting should focus on (1).
But what I am suggesting is for either Alex or Eric to evaluate both
Martin's Structural Mount and Lada's Ysdl to determine whether either of
the drafts are particularly better/easier/cleaner to extend to cover the
Alias and Peer mount use cases covered in Alex's YANG mount draft, since
that might be useful to help identify which of (Martin's Structural
Mount of Lada's Ysdl) should be chosen as a starting point as a WG solution.
I hope this clarifies my previous request.
Yes. Although to me a merging may be more appropriate/likely then picking one.
Lou
Rob
On 04/02/2016 04:26, Lou Berger wrote:
Alex,
On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)"
<a...@cisco.com> 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:kwat...@juniper.net]
Sent: Wednesday, February 03, 2016 11:27 AM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
<rwil...@cisco.com>
Cc: Lou Berger <lber...@labn.net>; netmod WG <netmod@ietf.org>;
Alexander Clemm (alex) <a...@cisco.com>; Eric Voit (evoit)
<ev...@cisco.com>
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" <rwil...@cisco.com> 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"
<netmod-boun...@ietf.org on behalf of lber...@labn.net> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
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
