Re: [netmod] [Netconf] development plan

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 06 August 2013 15:42 UTC

Return-Path: <jmh@joelhalpern.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 1E03521E8088; Tue, 6 Aug 2013 08:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.724
X-Spam-Level:
X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwG3R1NuYeZh; Tue, 6 Aug 2013 08:42:45 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0542421E804D; Tue, 6 Aug 2013 08:42:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E6D27102318; Tue, 6 Aug 2013 08:42:44 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-134-254.clppva.east.verizon.net [70.106.134.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id ED6041021D7; Tue, 6 Aug 2013 08:42:43 -0700 (PDT)
Message-ID: <52011972.5050406@joelhalpern.com>
Date: Tue, 06 Aug 2013 11:42:42 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, netconf@ietf.org, netmod@ietf.org
References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@elstar.local> <m2mwov3x7a.fsf@nic.cz>
In-Reply-To: <m2mwov3x7a.fsf@nic.cz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] [Netconf] development plan
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 06 Aug 2013 15:42:50 -0000

If there is an arrow in figure 1 of the I2RS architecture implying that 
an I2RS agent manipulates the config data, then we need to fix that. 
The intention of the authors (and the intention agreed in earlier 
documents) is that I2RS does not mes with config data.
The amplification in the architecture document is that I2RS simply does 
not mess with any persistent data storage at all.  I2RS state is lost at 
reboot.  The working group sounded happy with this proposal in Berlin. 
We will see what happens on the list.

Yours,
Joel M. Halpern,
I2RS Architecture coauthor and netconf/netmod spectator.

On 8/6/13 6:55 AM, Ladislav Lhotka wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
>
>> On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote:
>>>
>>> FWIW, this is not how I understand I2RS - I think they explicitly
>>> mention the configuration data as being one thing, and that they want
>>> another "direct" method to modify the operational state.
>>>
>>
>> Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt,
>> which is likely going to become the I2RS architecture document soon.
>
> That document clearly states (Sec. 5.3): "... local device configuration is considered to be separate from the I2RS data store." So if Fig. 1 indicates that I2RS agents interact with Local Config, I assume it has to do so as a compliant NETCONF client. So "config true" data stay fully in the NETCONF realm.
>
> My conclusion from the discussion with the authors of draft-nitinb-i2rs-rib-info-model-01 is that I2RS data store is a subset of "config false" data from the NETCONF viewpoint, except that they are all read-only for NETCONF whereas the I2RS agent can write some of them.
>
> Maybe I2RS folks reading this thread can shed more light on this issue.
>
> Lada
>
>>
>> /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/>
>