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

[Ladislav Lhotka <[e-mail]>]

> On 04 Feb 2016, at 13:07, Lou Berger <[e-mail]> wrote:
> 
> Rob,
> 
> 
> On February 4, 2016 4:57:24 AM Robert Wilton <[e-mail]> 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.

I agree.

Lada

> 
> Lou
> 
>> 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
>>>>> 
>>> 
>>> 
>>> .
>>> 
>> 
>> 
> 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C