Re: [netmod] Differentiating the types of Mount
STUART VENTERS <stuart.venters@adtran.com> Wed, 16 March 2016 19:49 UTC
Return-Path: <stuart.venters@adtran.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D1E12D695 for <netmod@ietfa.amsl.com>; Wed, 16 Mar 2016 12:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aon8fhmqPtHI for <netmod@ietfa.amsl.com>; Wed, 16 Mar 2016 12:49:12 -0700 (PDT)
Received: from s12p02o149.mxlogic.net (s12p02o149.mxlogic.net [208.65.145.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C6A12D6A9 for <netmod@ietf.org>; Wed, 16 Mar 2016 12:48:56 -0700 (PDT)
Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by s12p02o149.mxlogic.net(mxl_mta-8.5.0-8) with ESMTP id 8a8b9e65.7fa1c35fe700.116435.00-522.347798.s12p02o149.mxlogic.net (envelope-from <stuart.venters@adtran.com>); Wed, 16 Mar 2016 13:48:56 -0600 (MDT)
X-MXL-Hash: 56e9b8a8455e5616-3340ea299574ae0dce68a884a8a26d1d3a74efdd
Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by s12p02o149.mxlogic.net(mxl_mta-8.5.0-8) over TLS secured channel with ESMTP id 5a8b9e65.0.116350.00-270.347515.s12p02o149.mxlogic.net (envelope-from <stuart.venters@adtran.com>); Wed, 16 Mar 2016 13:48:55 -0600 (MDT)
X-MXL-Hash: 56e9b8a70cda379f-436317e99d3105681c904a27bddd3bca7c938742
Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0266.001; Wed, 16 Mar 2016 14:48:50 -0500
From: STUART VENTERS <stuart.venters@adtran.com>
To: "'Eric Voit (evoit)'" <evoit@cisco.com>
Thread-Topic: [netmod] Differentiating the types of Mount
Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAZ+8KAAACU0PAAC9tEgAAH75xA
Date: Wed, 16 Mar 2016 19:48:50 +0000
Message-ID: <1220E2C537595D439C5D026E83751866E7B4C20C@ex-mb1.corp.adtran.com>
References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> <1220E2C537595D439C5D026E83751866E7B4C101@ex-mb1.corp.adtran.com> <020f5d85b38d46d5a09940e8e89cc37e@XCH-RTP-013.cisco.com>
In-Reply-To: <020f5d85b38d46d5a09940e8e89cc37e@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.22.118.25]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-AnalysisOut: [v=2.1 cv=YJeZvEyx c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==]
X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=0eaKXOXVzoQA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=7OsogOcEt9IA:10 a=OUixTkr]
X-AnalysisOut: [4AAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8]
X-AnalysisOut: [ a=ctln6_MMGif9rZKV0rYA:9 a=0VwNEXvxz8D-2UrO:21 a=VnkF6kAX]
X-AnalysisOut: [1a-BOEtW:21 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJ]
X-AnalysisOut: [tCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10]
X-Spam: [F=0.5100000000; CM=0.500; MH=0.510(2016031613); S=0.434(2015072901)]
X-MAIL-FROM: <stuart.venters@adtran.com>
X-SOURCE-IP: [76.164.174.81]
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/iJpmRF6eI6B-kIdUfC3B3ebxQs8>
Cc: "Martin Bjorklund (mbjorklu)" <mbjorklu@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Differentiating the types of Mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Mar 2016 19:49:15 -0000
Eric, I did the suggested OpenDaylight (ODL)search, and yes there is a lot of activity there. There are a lot of trees in that forest. The best overview I found seems to be here. https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architecture_Overview#Nested_Subsystems Mapping my words to ODL, My Sibling is the ODL Nested system. My Parent might be ODL Top-level Subsystem? Having had lunch to think about it, I don't think I should have picked NetConf as a place to choose what data to mount. I suspect it should be somewhere in the application, separate for both Yang and Netconf. ODL appears to use the Northbound Restconf interface to do this function <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config"> Stepping back, for this mounting stuff, there are at least 3 issues: 1) Specifying a where in the Parent schema to put the sibling schema. 2) Specifying the type of the sibling. 3) Specifying what sibling data instance to put at a specific parent node data instance. I think Yang would be a great place to do 1 and 2, but I think the application should handle 3. ODL appears to put 1) in Yang, I'm not sure about 2), and 3) in the application. Your proposed definition's mention of data-tree appears to put 3 into Yang with appears to conflict with ODL. Since you clearly don't want however Yang turns out to collide with ODL, but appear to be proposing something that collides, I must not understand? Another use case: ODL Yang device mounting is about grafting and removing whole, existing devices as branches in a single tree on a running system. For this, there may be some benefit in treating the grafted branch as a special sort of node in the tree. Having a special keyword like 'mount' might help this, or the application function that does 3) above could handle it. Another use case is simply making a big device model by grafting together smaller, whole, existing models. In this case, the benefit may be to make the grafted branch look like a non-special vanilla node in the tree. In this case, I don't see the benefit over a special keyword like 'mount' over an existing one like 'uses'. Regards, Stuart -----Original Message----- From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Wednesday, March 16, 2016 12:20 PM To: STUART VENTERS Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu); 'Juergen Schoenwaelder' Subject: RE: [netmod] Differentiating the types of Mount > From: STUART VENTERS, March 16, 2016 12:58 PM > > Defining a schema-tree seems Yang's strong suite. > I'm not sure if the suite extends to defining what goes into a > data-tree governed by the schema-tree. Hi Stuart, Open Daylight has found Mounting YANG data from one device to another has proven central to their effort. Doing a quick Google search for "mount site:opendaylight.org" gives 800+ results. Based on that, I was hoping that being defining the variants of Mount across different constituencies would help us not collide as the technologies evolve. This includes a shared definition of "YANG Mount" which shows what is common across all efforts. Thanks, Eric > Perhaps: > > YANG Mount > ---------------- > Definition: An abstracted term for a YANG mechanism that grafts a > sibling schema-tree as a subtree of a parent schema-tree. > Purpose: Provides flexibility by enabling the growth of YANG models > via an explicit reference to other YANG models defined elsewhere. > > Given the ability to specify a combined schema-tree, maybe something > at the protocol level could specify what data to use to populate the grafted tree. > This could provide a place to specify details like who has ownership > of the data, if it is RW, etc. > > NETCONF Mount > ------------------ > Definition: An abstracted term for a NETCONF mechanism to construct a > combined data-tree according to a schema defined with YANG mount. > Purpose: ... > > > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, March 16, 2016 6:23 AM > To: Eric Voit (evoit) > Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu) > Subject: Re: [netmod] Differentiating the types of Mount > > On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote: > > To help differentiate between concepts and drafts, below are > > strawman > definitions for the various types of Mount which we have been discussing over > the last year in Netmod. Thoughts/suggestions? > > > > YANG Mount > > ---------------- > > Definition: An abstracted term for a mechanism that a parent YANG > > model can > use to link in YANG information defined or located elsewhere. > > Purpose: Provides model flexibility by enabling the growth of YANG > > trees via > an explicit reference to other YANG information and structures. > > Trying to rewrite the definition to be more consistent with existing > terminology: > > The abstract concept of incorporating a YANG-defined data tree (the > mounted data tree) into a existing YANG-defined data tree (the > parent data tree). > > Well, this is not really correct, perhaps we have to just say 'tree' > instead of 'data tree' since a schema mount (as I understand it) seems > to incorporate a schema tree into another schema tree while the other > two mounts incorporate a data tree into a data tree. So perhaps the > general definition is something like this: > > The abstract concept of incorporating a YANG-defined data tree or > schema tree (the mounted data or schema tree) into a existing > YANG-defined data tree or schema tree (the parent data tree). > > The schema mount then essentially removes data tree and the other two > mounts remove the schema tree from this definition. > > Is your alias mount simply a special case of a peer mount where the > peer is local? Or is there more to it? In other words, would it be > reasonable to think of the terms in this way: > > +-> schema (tree) mount > | > mount -> | +-> local data tree (alias) mount > +-> data (tree) mount -> | > +-> remote data tree (peer) mount > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [netmod] Differentiating the types of Mount Eric Voit (evoit)
- Re: [netmod] Differentiating the types of Mount Juergen Schoenwaelder
- Re: [netmod] Differentiating the types of Mount Eric Voit (evoit)
- Re: [netmod] Differentiating the types of Mount Alexander Clemm (alex)
- Re: [netmod] Differentiating the types of Mount Kent Watsen
- Re: [netmod] Differentiating the types of Mount STUART VENTERS
- Re: [netmod] Differentiating the types of Mount Eric Voit (evoit)
- Re: [netmod] Differentiating the types of Mount STUART VENTERS
- Re: [netmod] Differentiating the types of Mount Eric Voit (evoit)
- Re: [netmod] Differentiating the types of Mount Eric Voit (evoit)