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

[Lou Berger <[e-mail]>]

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.

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
>>>>
>>
>>
>> .
>>
>
>