Re: [I2rs-proto-dt] I2RS meeting

Andy Bierman <andy@yumaworks.com> Fri, 13 November 2015 03:30 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: i2rs-proto-dt@ietfa.amsl.com
Delivered-To: i2rs-proto-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FB21B3F63 for <i2rs-proto-dt@ietfa.amsl.com>; Thu, 12 Nov 2015 19:30:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 o4SPwYYK7tdg for <i2rs-proto-dt@ietfa.amsl.com>; Thu, 12 Nov 2015 19:30:18 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043321B3F64 for <i2rs-proto-dt@ietf.org>; Thu, 12 Nov 2015 19:30:17 -0800 (PST)
Received: by lfdo63 with SMTP id o63so45456597lfd.2 for <i2rs-proto-dt@ietf.org>; Thu, 12 Nov 2015 19:30:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VubdJajCFAF3RzPNA6NbteaHjoqMfh9sKs0D3xx+dw8=; b=LtMtDyorege1YS8iVBDxnZ48snUX3+IraYlY79kkhQIarswO5fh7qo4YYB4Giu8wT3 Qx4PEBtwXLtmRglzuntVvuNsAtuCUF66HIz33xL8vb2ffVsabkRSLruDw+DeOEVvJ2M2 7UsqklCJqpKDeWSTAA7SoG1T3s2bjXdbvq0YLpawfThURTZli/guIjlrXzrhg5Zs6Vek qqLqkrHzcdL3zf4TB1TX6x/jp5O49mRFFy/n4P42ycHXdGztF2ex3HPQl8ngtG5stCyN G/xyAwL7C6oQnpIDnVAAfSULWWKSydUX7VFxhQe78g67uKkH+e1vAclUhd/ouwdlEC0Q AoqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VubdJajCFAF3RzPNA6NbteaHjoqMfh9sKs0D3xx+dw8=; b=h/YWNKgFY4ghUu+L3PQkj5j6IWFbyMddBWZhcC7OGv6jsVkz6uLLeWRyVyLk2fG+gp E6sc4nJoVZq+ReqndF66sPEBDjFthBpYGR+FUmpvUeClLPAq0FK4wuBUXyTHO+K/GgOE V3QIUwjKbCyaF+3AT4jfZjMRY0DaLTi2BghiFa87oe1EAwCPWptdLlwrN66gI/D7WWKx il8iPAteWy63b2Vj6ncwrsYvejAufM5tnvkaeqW2gppX3hoBqc8JHZ79oQsIJetQpe9W M+AVV9/JGNuy0OmgYi3Q6P90c/3ojnaQxpniNnBkw5HuL9Af1L1esKcBrR9KDujYjAWn GgZA==
X-Gm-Message-State: ALoCoQmlnBEpoMfDLHTky0nZIopgMcl1269TBl/ymxD2lvsfYUsFaWt2T4togU9Q0OkmyaK2M8pO
MIME-Version: 1.0
X-Received: by 10.25.17.232 with SMTP id 101mr8883916lfr.38.1447385416054; Thu, 12 Nov 2015 19:30:16 -0800 (PST)
Received: by 10.112.144.106 with HTTP; Thu, 12 Nov 2015 19:30:15 -0800 (PST)
In-Reply-To: <616EAB9D-3E23-40A1-822F-D49D9E8BC37C@gmail.com>
References: <CABCOCHQmW34gjQ3zrhLvk3a1zYk5LFftLfTgy+rPq1skCbqhXA@mail.gmail.com> <007101d114e8$e56e3bf0$b04ab3d0$@ndzh.com> <616EAB9D-3E23-40A1-822F-D49D9E8BC37C@gmail.com>
Date: Thu, 12 Nov 2015 19:30:15 -0800
Message-ID: <CABCOCHTK=ATSpzj5rW+DkN-D27wpYpZABzi-J-R9+nTBi=8-MQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Dean Bogdanovic <ivandean@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f993a93d1fe052463ad2c
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/B1uH2idqsbjz8sU4H1gyFUJE7Y4>
Cc: i2rs-proto-dt@ietf.org, Susan Hares <shares@ndzh.com>
Subject: Re: [I2rs-proto-dt] I2RS meeting
X-BeenThere: i2rs-proto-dt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: I2RS protocol design team <i2rs-proto-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs-proto-dt/>
List-Post: <mailto:i2rs-proto-dt@ietf.org>
List-Help: <mailto:i2rs-proto-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 03:30:20 -0000

Hi,

I have some new questions about I2RS.

1) save client-id or client-id and priority?
Jan was concerned about saving state for every node.
If there is only 1 client and 1 priority then there is nothing to save.
For multi-head agents they will need to save the client-id.
The priority is configured for the client. It if changes the
priority of all the client's data automatically changes.
If this is not acceptable, then the priority and the client have to
be saved per node.

2) edit boundaries are not remembered
Each edit by each client will just go into the ephemeral datastore.
Identification of individual edits is not remembered.
Therefore the data that gets bumped by a high-priority overlap
is deleted based only on the overlap, not the original edit.

3) because of (2) there might be client interactions that break things.
e.g...
   client-worst sets entire /foo/bar subtree and it is accepted and
activated
   client-best later sets some subtree inside /foo/bar and the old subtree
is deleted
   and replaced with the data from client-best.  At this point the overall
   config may be invalid. The agent needs to do lots of expensive validation
   and may need to remove even more data from client-worst.
   Whether arbitrary pruning is done or not, the config may be operationally
   invalid at this point. Maybe this is no different than clashing clients
in persistent config,
  and can be considered out of scope.



Andy



On Sun, Nov 1, 2015 at 1:32 PM, Dean Bogdanovic <ivandean@gmail.com>; wrote:

> I support Andy's comments
>
> On Nov 2, 2015, at 06:04, Susan Hares <shares@ndzh.com>; wrote:
>
> Andy:
>
>
>
> I really appreciate this email.   Please comment remotely or skype me
> (Susan.Hares) or send a note to the jabber scribe.
>
>
>
> How is your dog?
>
>
>
> Sue
>
>
>
> *From:* I2rs-proto-dt [mailto:i2rs-proto-dt-bounces@ietf.org
> <i2rs-proto-dt-bounces@ietf.org>] *On Behalf Of *Andy Bierman
> *Sent:* Sunday, November 01, 2015 3:36 PM
> *To:* Susan Hares; i2rs-proto-dt@ietf.org
> *Subject:* [I2rs-proto-dt] I2RS meeting
>
>
>
> Hi,
>
>
>
> I plan to listen in to the I2RS meeting.
>
> It's probably too late for a conf-call before the meeting,
>
> but I am available.
>
>
>
> I think it is OK to say the YANG constraints apply to
>
> the derived "intended config" and also apply
>
> to the running datastore as defined in YANG.
>
>
>
> That means if the max-entries is 5, then 5 can exist in
>
> the running config, and new entries added to ephemeral
>
> must override entries in running.  Retrieving the intended config
>
> actually used (e.g., which config entry is disabled) is
>
> a different issue.  The intended config can only have 5 entries
>
> in it.  It falls out that the ephemeral datastore can only
>
> have 5 entries in it as well.
>
>
>
> Not all YANG constraints are as easy as min-elements,
>
> and max-elements.
>
>
>
> mandatory, must, when, and unique need more careful thought
>
>
>
>
>
> Andy
>
>
>
> _______________________________________________
> I2rs-proto-dt mailing list
> I2rs-proto-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt
>
>