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

Andy Bierman <andy@yumaworks.com> Mon, 26 October 2015 20:45 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 2F0931A03D5 for <i2rs-proto-dt@ietfa.amsl.com>; Mon, 26 Oct 2015 13:45:09 -0700 (PDT)
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 4ad5wh6RGLlk for <i2rs-proto-dt@ietfa.amsl.com>; Mon, 26 Oct 2015 13:45:07 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 6B0DD1A0379 for <i2rs-proto-dt@ietf.org>; Mon, 26 Oct 2015 13:45:06 -0700 (PDT)
Received: by lffv3 with SMTP id v3so162943503lff.0 for <i2rs-proto-dt@ietf.org>; Mon, 26 Oct 2015 13:45:04 -0700 (PDT)
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=iMqaHmU7Bt1R4ACTgUuCxJTY8Kat408s3+0U/7RyuP4=; b=13fH7rzXsIxedc1eZtrjrlkNeGaRD59jW7C5/jJ+XzqHPcbc1GxmhstgI1EoaFGi3B yKora2prEvq+k3NAghuUauhNAWal1NdB9zKqtTMBYN32kHIQ5wwSKqHtZDEKHAR9v8qp 7JmaBQlfQlD7Dp+eRo8w2AL0MyOFQHbsUKD4Vu9VOPKordgO8z5pVnxxqCewfw9MuwkI wbhMNQRiqKIR3qMhkRiTGqwPVQ5VlEqpeSLhpKZu+qhHZw66wSP/n+ABo7cjakSTZx+B ECocc6OOWKORmMDw8xA4X8jBwQnqdasYNkgVim8lp7b4vp9/2DPXH8ddYQHDfEiojPmJ 7f+Q==
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=iMqaHmU7Bt1R4ACTgUuCxJTY8Kat408s3+0U/7RyuP4=; b=aNSYYH2oPbXmrNSude6/BsDFotmgeE+uuk5Ktxg5OtkZWhbhnIZ/OLgwFscwQdg0a+ BoRw3CeW5jObA85dLsgI08egOgd6Q7QLHATs1222aSerXtBZgHmKhEP0876miRTlG4jU GkHh3cdQ+QZXZqkTfuZyAvt+ibBveKiVfRFH1ZwIL3mELjzvqUTZgzaXJfJ30a0QqWiX KRZq7WL77XTHWhhfdylt2oACcTGoNxGnOKyQIyzxssEAmFrtpU0rn4LzgsfZV6DjQjnm N7hmu9gRgu0MQ7HAL4FgZrdQz8CMMIw467/BYMVbHE+/pbwbv7QZZg5cD6AUlBp5EMU6 l+7A==
X-Gm-Message-State: ALoCoQmpbWop0or7ZqeOQH8XRwHy/6CV2ZE/dcXhw8EJ+8rON8Bho9MHmgtvH8yhDs6I9SKaGdR4
MIME-Version: 1.0
X-Received: by 10.25.154.201 with SMTP id c192mr11720982lfe.119.1445892304532; Mon, 26 Oct 2015 13:45:04 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Mon, 26 Oct 2015 13:45:04 -0700 (PDT)
In-Reply-To: <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> <EA5EC853-2DA1-437C-8EC2-558F4C229680@gmail.com>
Date: Mon, 26 Oct 2015 13:45:04 -0700
Message-ID: <CABCOCHTVmJsRD5zN1fpmxFxb8Z0QPntvkXzLkutEkpf-+UQPqw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Dean Bogdanovic <ivandean@gmail.com>
Content-Type: multipart/alternative; boundary=001a114032d23216fa05230809cf
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/bEKgsnlqH03A7cGlVnwCteqPoSU>
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:45:09 -0000

On Mon, Oct 26, 2015 at 1:36 PM, Dean Bogdanovic <ivandean@gmail.com>; wrote:

> Ephemeral should obey the overall configuration.
>
>

What does this mean?
Does this mean all the YANG constraints MUST be valid in the ephemeral
datastore.  Your terminology is not precise enough to apply to RFC6020bis.

YANG tools need specific deterministic rules that are derived from YANG
statements
other than the description and reference statements.  The agent is not
going to read
description-stmts and decide if the resource represented by the YANG data
is real, virtual, or some combination of the two.


Andy




> 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>; 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] *On Behalf
>> Of *Andy Bierman
>> *Sent:* Friday, October 23, 2015 11:29 AM
>> *To:* Jeffrey Haas
>> *Cc:* 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>; 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
>
>
>