Re: [netmod] [Netconf] development plan

Andy Bierman <andy@yumaworks.com> Tue, 06 August 2013 11:15 UTC

Return-Path: <andy@yumaworks.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 E5E4321F9CBF for <netmod@ietfa.amsl.com>; Tue, 6 Aug 2013 04:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.474
X-Spam-Level:
X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 mpE-oPdeJY1P for <netmod@ietfa.amsl.com>; Tue, 6 Aug 2013 04:15:37 -0700 (PDT)
Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id CEEBD21F9B5C for <netmod@ietf.org>; Tue, 6 Aug 2013 04:15:37 -0700 (PDT)
Received: by mail-pb0-f41.google.com with SMTP id rp2so278511pbb.14 for <netmod@ietf.org>; Tue, 06 Aug 2013 04:15:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=DMlRI5aZma9X7II5JKDQFH26sKNR6j+1HhJnRusW+kc=; b=dFshK6ftNwQ4ZsdLzou9lKw7A/gXAUMdbShXBCq7fm5R1Cr1a2mH6XY1bfmEG4p4AQ lABhbw0Rc50WrFd9vE9oXc6K4Uuo+crERQBam6dXnWVWa4Jj3piiTwwQNPpjDKvblwS8 ZWI4EhVRTyeY0Hp6EZ3oEhHrSl3hdRl8hU5MFWilLWhymQFeHUG63n2Y2gdM/K3DbU9d lwZFuS4wz405IVHilVoB3UPFrX+K9ty/oww0f4QCpWiX7USU9vsELHk1r7Y2FXQZNEMk TL6czNmK//eiUiWz9Mf7kVpV0FajGPwSEKJujL3EsFnc7o4/HiaRQu5s5alywudVz09l NTwA==
X-Gm-Message-State: ALoCoQkoux0HZrd/J/Mpu93wyhFWXDk1w8M+x5VckqlVxbUjQgWcJwXV9jdhSyy+N38DB6NnYNpg
MIME-Version: 1.0
X-Received: by 10.68.135.162 with SMTP id pt2mr969240pbb.42.1375787737451; Tue, 06 Aug 2013 04:15:37 -0700 (PDT)
Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 04:15:37 -0700 (PDT)
In-Reply-To: <m2mwov3x7a.fsf@nic.cz>
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>
Date: Tue, 06 Aug 2013 04:15:37 -0700
Message-ID: <CABCOCHS43-pC2AzWM9XgXHu-GEG5wzGE9+z9S6b6DPsaRt5u3Q@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, netconf@ietf.org, netmod@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 11:15:43 -0000

On Tue, Aug 6, 2013 at 3:55 AM, Ladislav Lhotka <lhotka@nic.cz> 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.
>

I have not finished the code yet, so I will not comment on details,
but it should be quite possible to allow writable operational state
to be supported so it is compatible with NETCONF.

This meeting it was decided the injected state will not
be tied to local config (i.e., made to persist).  It only
lasts until explicitly removed or the next server reboot.

If you remember from the BoF, they want a fast path.
So implementing I2RS with RESTCONF or NETCONF is just
a matter of eliminating the slow parts ;-)

> Maybe I2RS folks reading this thread can shed more light on this issue.
>
> Lada
>
>>
>> /js
>>


Andy