Re: [I2rs-proto-dt] couple YANG details

Dean Bogdanovic <ivandean@gmail.com> Mon, 26 October 2015 20:36 UTC

Return-Path: <ivandean@gmail.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 D4A061A0371 for <i2rs-proto-dt@ietfa.amsl.com>; Mon, 26 Oct 2015 13:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 UYuD8jpEjwou for <i2rs-proto-dt@ietfa.amsl.com>; Mon, 26 Oct 2015 13:36:55 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 50B171A036F for <i2rs-proto-dt@ietf.org>; Mon, 26 Oct 2015 13:36:55 -0700 (PDT)
Received: by qgad10 with SMTP id d10so130085160qga.3 for <i2rs-proto-dt@ietf.org>; Mon, 26 Oct 2015 13:36:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ah3lc18AqyTXq3jVqL9tQp1EFgvdcjb2i/us4KLEBT0=; b=zwTZMWV334DfmrlzR/Roh37WZLf03pz5XWAqIoQIEOxond7vLXASqObzZVa8pJJrdU f5N/XqkPZc90g9iHPgvPUFQYpLdSmSLyuNiFzgRUfVO+xYJvMJMMSyApMuxtgqfu/9vq R5LxPEoEchdpLobv3Xp8OcFyverYnWtWvxlI3uEcUUzy6AMluU8Hl2lndY4em77NCaeE My2lofk5Cz8+08lUD/9WuTvEeKc1Sluiv1pNZl3RoKNWw3QX5ME8VSFkDBncS3SnTxNg 4zAzOZeTapQ/l9S/fVDDNPIPK6PUrG4/gW8LzfZeOuIrfFdiSYLLB0ZNMfzcUfCay3+n CJpA==
X-Received: by 10.140.96.200 with SMTP id k66mr45172264qge.81.1445891814374; Mon, 26 Oct 2015 13:36:54 -0700 (PDT)
Received: from [192.168.128.73] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id j3sm13739543qgj.44.2015.10.26.13.36.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Oct 2015 13:36:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8EBCE0D5-9CC9-441A-BFDB-90CDBB5A4246"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Dean Bogdanovic <ivandean@gmail.com>
In-Reply-To: <CABCOCHQok6Kx_=Y5eQ4sjK5O912EibPLXM0n_c4zFSbMs_Z-Gg@mail.gmail.com>
Date: Mon, 26 Oct 2015 16:36:53 -0400
Message-Id: <EA5EC853-2DA1-437C-8EC2-558F4C229680@gmail.com>
References: <CABCOCHRRDZZZF1uj6UVDezmZzM3g8bEQiWTkyZKUPk6HL40fcg@mail.gmail.com> <CABCOCHSinfdgfxhg8Ly9ZDSDCvqi3xse+ZwAAQnYweEaMJ6j7w@mail.gmail.com> <20151023151945.GG26793@pfrc.org> <CABCOCHQb1MjX_8XpV1+2vOnEWO_VfNQoLi=jBizGov+Hz6saoA@mail.gmail.com> <033a01d10dd4$0e25ef50$2a71cdf0$@ndzh.com> <CABCOCHQok6Kx_=Y5eQ4sjK5O912EibPLXM0n_c4zFSbMs_Z-Gg@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/Gb-YIMWC_O3hY8E1nwx8aq2SGkA>
Cc: Jeffrey Haas <jhaas@pfrc.org>, i2rs-proto-dt@ietf.org, Susan Hares <shares@ndzh.com>
Subject: Re: [I2rs-proto-dt] couple YANG details
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: Mon, 26 Oct 2015 20:36:58 -0000

Ephemeral should obey the overall configuration.

To go forward with Andy’s example, ‘max-elements 5’, question is what is this limit: physical or logical?

If it is physical limitation, like number of queues, then there is really no sense to increase that value.

If it is logical, number of VRFs, then increasing this value might be possible. But how can this be known by the client? So IMO, ephemeral should obey overall configuration. Ephemeral can always overlay existing configuration with its values, if it has admin rights to it.

Dean


> On Oct 26, 2015, at 4:18 PM, Andy Bierman <andy@yumaworks.com>; wrote:
> 
> 
> 
> On Fri, Oct 23, 2015 at 1:47 PM, Susan Hares <shares@ndzh.com <mailto:shares@ndzh.com>> wrote:
> Andy:
> 
>  
> 
> Two options:
> 
> 1)      Ephemeral obeys the overall configuration,
> 
> 2)      Ephemeral sets its own ephemeral limit.
> 
> 
> 
> 
> It is not that clear what it means for both (1) and (2) to be true.
> 
> I am ready to give up on panes of glass.
> Nobody is clear on the details of client-facing integration of running
> and ephemeral datastores.
> 
> Instead, I think the ephemeral datastore should be completely separate
> from the running datastore.  At boot-time, it is completely empty.
> 
> To override "next-hop",  the I2RS client has to provide all the ancestors,
> and (at least) ancestor key leafs.  These data nodes will not be created automatically
> or mirror running config automatically, or do anything at all automatically,
> wrt/ the running datastore.
> 
> The router is responsible for reconciling the running and ephemeral datastores
> to produce the current intended config.
> 
> A collision can only occur in the ephemeral datastore between the proposed edit
> and the existing ephemeral datastore contents.
> 
> Running datastore validation and operation is completely untouched
> and unaffected by the ephemeral datastore.   
> 
> Ephemeral datastore validation and operation is completely untouched
> and unaffected by the running datastore.   
> 
> The client will not be able to derive the intended configuration by retrieving
> both datastores and combining them. A special operation is probably
> needed for that.
> 
> Validation on the ephemeral datastore is not really required, although
> any deviation from the running datastore (especially pick and choose statements)
> is likely to cause user astonishment.
> 
> IMO it is least astonishing to say the ephemeral datastore is not validated
> at all, but the intended configuration in use by the agent SHOULD be valid
> at all times.
> 
> 
> Andy
> 
> 
> 
>  
> 
> If you do #2, then are you suggesting we put a limit in the original data model.
> 
>  
> 
> Sue
> 
>  
> 
> From: I2rs-proto-dt [mailto:i2rs-proto-dt-bounces@ietf.org <mailto:i2rs-proto-dt-bounces@ietf.org>] On Behalf Of Andy Bierman
> Sent: Friday, October 23, 2015 11:29 AM
> To: Jeffrey Haas
> Cc: i2rs-proto-dt@ietf.org <mailto:i2rs-proto-dt@ietf.org>; Susan Hares
> Subject: Re: [I2rs-proto-dt] couple YANG details
> 
>  
> 
>  
> 
>  
> 
> On Fri, Oct 23, 2015 at 8:19 AM, Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> wrote:
> 
> Andy,
> 
> On Wed, Oct 21, 2015 at 02:49:12PM -0700, Andy Bierman wrote:
> > We need to figure out for each YANG constraint:
> >  1) does it apply at all?
> >  2) is it MUST, SHOULD, or MAY enforce?
> >  3) Does the constraint apply the same in running vs. ephemeral?
> >  4) Does the constraint apply to the combined panes of glass or
> >      each pane independently?
> 
> I'm going to avoid answering your question to let you decide what this
> functional requirement means:
> Ephemeral nodes SHOULD NOT introduce their own constraints.
> The presence of ephemeral nodes does not trump validation or constraints for
> persistent state.
> 
>  
> 
> So if the YANG list has "max-elements 5",
> 
> and the config has 5 entries.  What happens when
> 
> 5 or 10 entries are added in the ephemeral datastore?
> 
>  
> 
>  
> 
> -- Jeff
> 
>  
> 
> Andy
> 
>  
> 
>  
> 
> 
> _______________________________________________
> I2rs-proto-dt mailing list
> I2rs-proto-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs-proto-dt