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

Andy Bierman <andy@yumaworks.com> Mon, 26 October 2015 20:18 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 179171A0181 for <i2rs-proto-dt@ietfa.amsl.com>; Mon, 26 Oct 2015 13:18:04 -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 vURhtP2FuS3k for <i2rs-proto-dt@ietfa.amsl.com>; Mon, 26 Oct 2015 13:18:02 -0700 (PDT)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (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 1F80E1A0180 for <i2rs-proto-dt@ietf.org>; Mon, 26 Oct 2015 13:18:02 -0700 (PDT)
Received: by lbbwb3 with SMTP id wb3so48952384lbb.1 for <i2rs-proto-dt@ietf.org>; Mon, 26 Oct 2015 13:18:00 -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=Mhy0km6TFpuwcg7BRNYbcg9QDOVzLLBowq1Af7xS9/A=; b=PQDYjSxQhyuPGxpIxSrNIRf/8ugoTvKAZnPFaIVmaRfc0ZrzvCERUNK6qw24jNqxI7 iX/ba/0ywIHCjmjCmtnyyFMdxxNlwz7mQiv771dkNLmqFktaVCANchFIjCrK57bdWF5X Hrc89JLcvQ5yJdCKUoEV5vGSIa20I1BZAq36wyVdLk7RseX6wRZeQQrloZSdXDeLfpWn LFsu5XMfWbxEnn7y5qMQaLsC54qT5ymBVL4w3vWv9by/OLTxPuoFZ7DT7pvh3QWS+a10 cY/dVMGyMVZOEpe4kospyL+QuAZAXp64k0qU2Gd+jc7SnC1p7ddqA0AQbPZKpcZLNiGR KNHA==
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=Mhy0km6TFpuwcg7BRNYbcg9QDOVzLLBowq1Af7xS9/A=; b=J2woZXadcA3DL2C/cj0Ekejj5VPviQ/502hMSq0XFJzBs5C0rmxmJAKxJt2zQNU/ez 7xQ3b3/wfeOSPkbe2xcvAI/lpAdCQvJmIrrwW2vu7yBkgkbfTfMYLpqxOSR79HXiltjZ reDzzy5PoBYaAISQwSBIfOtSOtZWzmm+zQnIfdA0FLvabMfZikKG75/ATBHdZCX1m0oq iNcONbS9jYeN4gGDRSrVrKXDFAwP4yRg4jjFUi7dqw98sPzMBXSA0rCu9hy0JaMM97Ox M+tfC5kyh9eDq2kLxddRJLVGyHgH/UJGlRKCGQDTBLWMQ1aX8t2SUvCfA3pIQ+qDMjdM FRXA==
X-Gm-Message-State: ALoCoQlxyUIH71/33u6oQmkJFlk/M4FhahSGiqWrm6L3CcvWuSUMJ3xUdG0+Aubc0qKUdh70pWkc
MIME-Version: 1.0
X-Received: by 10.112.170.165 with SMTP id an5mr18660764lbc.33.1445890680212; Mon, 26 Oct 2015 13:18:00 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Mon, 26 Oct 2015 13:18:00 -0700 (PDT)
In-Reply-To: <033a01d10dd4$0e25ef50$2a71cdf0$@ndzh.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>
Date: Mon, 26 Oct 2015 13:18:00 -0700
Message-ID: <CABCOCHQok6Kx_=Y5eQ4sjK5O912EibPLXM0n_c4zFSbMs_Z-Gg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a11c37a2460eb9a052307a822
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/vNYMJjmG6k97xAS7VUZwXaHZqBQ>
Cc: Jeffrey Haas <jhaas@pfrc.org>, i2rs-proto-dt@ietf.org
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:18:04 -0000

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