Re: [Netconf] [netmod] development plan

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 06 August 2013 11:25 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 0BD8921F9BD8; Tue, 6 Aug 2013 04:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.242
X-Spam-Level:
X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 FqePkUGhU09K; Tue, 6 Aug 2013 04:25:51 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85321F9AA3; Tue, 6 Aug 2013 04:25:51 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66F2420BE0; Tue, 6 Aug 2013 13:25:50 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LucUJCObH2_J; Tue, 6 Aug 2013 13:25:50 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAC9820BDF; Tue, 6 Aug 2013 13:25:49 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5F30127BC3BA; Tue, 6 Aug 2013 13:25:43 +0200 (CEST)
Date: Tue, 06 Aug 2013 13:25:43 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>, netconf@ietf.org, netmod@ietf.org
Message-ID: <20130806112543.GA3573@elstar.local>
Mail-Followup-To: 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m2mwov3x7a.fsf@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Netconf] [netmod] development plan
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: <http://www.ietf.org/mail-archive/web/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: Tue, 06 Aug 2013 11:25:58 -0000

On Tue, Aug 06, 2013 at 12:55:37PM +0200, 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 reading of the I-D is that the want to read config, not write it.
Nothing seems to persists in I2RS.

   The I2RS Agent will not attempt to retain or reapply state across
   routing element reboot.

Anyway, we may have to check this document to make sure it really
clearly says this when it gets final using a terminology we do
understand.

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