IETF Logo Mail Archive

Re: [Netconf] Draft Charter Proposal for NETCONF WG

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 03 March 2017 18:41 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09374129974 for <netconf@ietfa.amsl.com>; Fri, 3 Mar 2017 10:41:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 qxy7HLGIa38V for <netconf@ietfa.amsl.com>; Fri, 3 Mar 2017 10:41:08 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB5312996F for <netconf@ietf.org>; Fri, 3 Mar 2017 10:41:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2108; q=dns/txt; s=iport; t=1488566468; x=1489776068; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iT64tWa9GhGC4COmKuGKclh/RNwRHW461r6X1gft93E=; b=aJWjSmDBfYxfLNEAJFqbD/k/Tp8X15f/6LvkoVI8hc7ppgOY9bbUwHkM tHFlQQWzn16OQKs5DRglihHALsE9vqfF9YFBk6Ojdn+Tz5PrghgI6ON8n kQU/Dqvc1GuNhbbnwnDWp5TSiuzMgFd/4JCstPgJ5iIVZE107khDuDxBO Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ASAQCct7lY/4QNJK1bAxkBAQEBAQEBAQEBAQcBAQEBAYNRYYERjWGRRpMogg+CDSaFfAKCYz8YAQIBAQEBAQEBYiiEcAEBAQMBOj8FCQICAQgOAgUDHhAbFyUCBA4NiWsItWKLAwEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FhkmEb4R1JoUeBY9WjFYBkimCBIh2hi6TOgEfOIEDVhWHE4l3gQ0BAQE
X-IronPort-AV: E=Sophos;i="5.35,238,1484006400"; d="scan'208";a="392424220"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2017 18:41:07 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v23If63q025301 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2017 18:41:07 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 13:41:06 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 13:41:06 -0500
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [Netconf] Draft Charter Proposal for NETCONF WG
Thread-Index: AQHSkqTwCc7ORdXbRmOFzdaoTO5UHKGA3a1wgAEFUwD//+LA8IAAYTsAgAB61wCAAIyFAP//x28wgABh9gCAABWI8A==
Date: Fri, 03 Mar 2017 18:41:06 +0000
Message-ID: <95291a9dd1494cc4be5035cd837a6ef7@XCH-RTP-013.cisco.com>
References: <026f01d29273$5d57dfa0$4001a8c0@gateway.2wire.net> <F1EB9C98-BB1C-410D-9D6D-1777A96148C6@nic.cz> <CABCOCHTVZxPyT_LSX2GjnNKFCz3857HAOA_GS5iTaxLejno8RQ@mail.gmail.com> <bc6813b038094a1eac1fc9df68f3205c@XCH-RTP-013.cisco.com> <m2pohzpznf.fsf@birdie.labs.nic.cz> <e2cd792fb1734d04b5d0340617ff39e9@XCH-RTP-013.cisco.com> <CABCOCHQ7zymX=0qtT9_ihamxDHiokkP9bE2bac-8Y=eU+bcXoQ@mail.gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF83D7A@SJCEML703-CHM.china.huawei.com> <20170303092406.GA2790@elstar.local> <0ba776220d76471abcfb1b3b9a956421@XCH-RTP-013.cisco.com> <20170303115216.GA2992@elstar.local>
In-Reply-To: <20170303115216.GA2992@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.61.143]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ZagheuVGpQG6sXYAJBSo8Esd_CA>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 18:41:10 -0000

> From: Juergen Schoenwaelder, March 3, 2017 6:52 AM
> 
> On Fri, Mar 03, 2017 at 11:05:53AM +0000, Eric Voit (evoit) wrote:
> >
> >
> > > From: Juergen Schoenwaelder, March 3, 2017 4:24 AM
> > >
> > > On Fri, Mar 03, 2017 at 01:01:10AM +0000, Alexander Clemm wrote:
> > > >
> > > > An operator doesn't want external systems to individually address
> > > > every
> > > control plane VM.  Rather they want a YANG model for this
> > > logical+physical combination.  In this case each VM might use Peer
> > > (data) Mount to build a multi-device abstraction.  BTW: doing it
> > > this way also allows the same mounted YANG object data to be
> > > addressably exposed for each VM without requiring another YANG model to
> be made.
> > > >
> > >
> > > My question since the very beginning is: Is the idea to run
> > > configuration editing transactions across mount points?
> >
> > My position is that there is huge value in read only access.  I have no desire to
> champion edit operations.
> >
> 
> Reading data of course has value but then NETCONF has this little 'CONF' in its
> name...
> 
> Anyway, if the peer mount is designed as a read-only access mechanism, how
> are the VMs then configured? I suppose there then needs to be a different
> addressing mechanism to access the VM's configuration data, e.g., something
> Andy was hinting at. Or how does this work?

There are lots of ways to approach this problem, but for this particular use case often it is unnecessary.   Configuration attempts from outside the box are often supposed to be global or VM agnostic across the box.  So each of the VMs then simply Peer Mount the global configuration data.  This eliminates lots of error-cases as it becomes very hard to push configuration data out of synch as you aren't exposing ways to do this.

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

v2.23.0 | Report a Bug | By Email