Re: [netmod] Yang mount / ysdl example use case

[Robert Wilton <[e-mail]>]

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.

Rob


On 04/02/2016 04:26, Lou Berger wrote:
> Alex,
>
>
> On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" 
> <[e-mail]> 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:[e-mail]]
>> Sent: Wednesday, February 03, 2016 11:27 AM
>> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
>> <[e-mail]>
>> Cc: Lou Berger <[e-mail]>; netmod WG <[e-mail]>; 
>> Alexander Clemm (alex) <[e-mail]>; Eric Voit (evoit) 
>> <[e-mail]>
>> 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" <[e-mail]> 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" 
>>>> <[e-mail] on behalf of [e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>
>
> .
>