Re: [netmod] Differentiating the types of Mount

Kent Watsen <kwatsen@juniper.net> Wed, 16 March 2016 15:36 UTC

Return-Path: <kwatsen@juniper.net>
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 3994712D52B for <netmod@ietfa.amsl.com>; Wed, 16 Mar 2016 08:36:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
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 kXCUOAUyjnM9 for <netmod@ietfa.amsl.com>; Wed, 16 Mar 2016 08:36:29 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A02D12D9D5 for <netmod@ietf.org>; Wed, 16 Mar 2016 08:35:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2hmHj7KMFtfg4ZaA98J4Z3eEfM+QemAa6Vt64hIedLg=; b=j1PLY78lHDwCQfd90VVn1FvEKoNB/II5APP3KINZevNHG17W474yGuKAapPZ4R/IsxbY9Vwfj0IEZmpgDfPphu9m8Bwf144omeHkh+PfBm0MNPwjksMSsYjekg+evlswfKQaKEyk4+rqyglG8/btRFhhmf9sPzD6jbWCDtM8v4E=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 15:35:25 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0434.019; Wed, 16 Mar 2016 15:35:25 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [netmod] Differentiating the types of Mount
Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAPgYyAAAf8JID//8NwAA==
Date: Wed, 16 Mar 2016 15:35:24 +0000
Message-ID: <24F4C6F2-3F59-4B71-A9D4-963371FE1EE6@juniper.net>
References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local> <21332d7a3dfd41009fb5023ca94baa94@XCH-RTP-013.cisco.com>
In-Reply-To: <21332d7a3dfd41009fb5023ca94baa94@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.160212
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: 9f859a14-424e-451f-da83-08d34db09811
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:PtXphvoFE+rSg0NI0KAbj6B4zmxw3q+J14KPGJsh7rWGVFPEPgAwSvi+RkBqhS+Cdx/0CNTUCx0FMpmwzg2+Mu8o/UB2LTAzdWPZ7E4yIhZob2j5dMWhPqAyjKuW4t2Nrvg9K35BdL3ie2SGuGce2g==; 24:yPpPIVzMwR+dui3n5VtV1q1FpIxNoDZn7nXCFc53Gsu6yeuc+ILjKpVdjcHkn7+URqegdaL08IwiUKsb3seAd0QTXL8+EdgbaNaXfU8b7HA=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442;
x-microsoft-antispam-prvs: <BN3PR0501MB144246EC6232152BCF67BE9BA58A0@BN3PR0501MB1442.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442;
x-forefront-prvs: 08831F51DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(3660700001)(5002640100001)(99286002)(11100500001)(81166005)(66066001)(83506001)(3280700002)(122556002)(4326007)(82746002)(5004730100002)(2906002)(83716003)(86362001)(36756003)(5008740100001)(87936001)(5001770100001)(33656002)(586003)(10400500002)(1220700001)(1096002)(2950100001)(4001350100001)(102836003)(2900100001)(3846002)(6116002)(76176999)(54356999)(50986999)(15975445007)(92566002)(189998001)(19580395003)(77096005)(19580405001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <0E6FDBB7CFAD044D8BDE11E40DED42A3@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 15:35:24.9167 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/dJWIuM-jilssSYk00GKjtgTd2uw>
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 15:36:32 -0000

Thank you Eric and Juergen, this is really helpful, especially the diagram.

Is there an implementation distinction between alias-mount and peer-mount?  I’m hoping that there is one solution for both.  Is there a difference with edits?  E.g., a remote data mount is read-only, whereas a local data mount is read-write?




Kent



On 3/16/16, 11:12 AM, "netmod on behalf of Eric Voit (evoit)" <netmod-bounces@ietf.org on behalf of evoit@cisco.com> wrote:

>> From: Juergen Schoenwaelder , March 16, 2016 7:23 AM
>> 
>> 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).
>
>This works for me.
>
>> 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? 
>
>>From a syntax standpoint, peer mount is more general.  But underneath, things get more complicated.
>
>For example, many of the initial concerns about peer mount were on the implications of synchronizing objects across distributed systems.  (I.e., Eventual consistency is not appropriate when attempting to manage some type of objects.)  Alias mount shouldn't have this issue.
>
>Eric
>
>> 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
>
>The formatting came through mixed up, and I didn't want to make any assumptions by doing my own reformatting.  If the answer above doesn't suffice, resend the example.
>
>Eric
>
>> /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