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

Andy Bierman <andy@yumaworks.com> Wed, 28 October 2015 16:21 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 8F9411B586E for <i2rs-proto-dt@ietfa.amsl.com>; Wed, 28 Oct 2015 09:21:14 -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 2KSPjszctOWn for <i2rs-proto-dt@ietfa.amsl.com>; Wed, 28 Oct 2015 09:21:12 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 CEB1B1B5844 for <i2rs-proto-dt@ietf.org>; Wed, 28 Oct 2015 09:21:11 -0700 (PDT)
Received: by lbbwb3 with SMTP id wb3so9633602lbb.1 for <i2rs-proto-dt@ietf.org>; Wed, 28 Oct 2015 09:21:10 -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=tpjikscvXVacKO4JQJG92UhSL/rjT2+GnkxJD+3w1pc=; b=AmwLT1h0JqYm3WLlXoEldiU96FNweGt+sJH2vPxKaSsVoE2bC7DOpr375G4ioi/8wN QTAQN8dISNTOMOwst5CaBJ0lVQUpyCHlzzI2Ai8CK0LVHsJZLqdUGaoeRotYPrhRxHnN xCjE6G9j4M035XVI4azQlQcBMxVdyAUsMIiomsh200UrwuJcyERa4GNekcwDG9Pmc+6r /403s6cFKYnB7GBk+L43l+3miHa2S5WUHyO9MkdT7ZNURUyhzfdhrcwcRcDy+LRIBRhn 00QiiSiUc7z6PGUpeImM+gRT8fVDK7zplGMsQv4247h1yuQeqgi6lymynjNvsRTSohtB KJQA==
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=tpjikscvXVacKO4JQJG92UhSL/rjT2+GnkxJD+3w1pc=; b=d8aRkmPesHsphjOE+13i/alI4kTOtsFPC9gRgpbWsgx2/Y/hhtnVv7HLirFf0pQ/IK P/QrM1/E5rQy0P1DRGLZvkjnflXb/R5XC5/ZspsDsdQV0JBaeVdY539RXSTU/7aDvGSP 8yxOyLQwaft0Olo4ERVuWRuKTxqzAvb/sb3Kx8y0U3z0z9UCRYnLN6Bmwv391yPnkrWk V6ylFOGJIIQau7sjaWhiqPMdOPrYOWqYLaIqv0WXpIrBpugc29FskdyRzrMCEeYCrL8z 0QF/QbzgYkhw8HYSnEodIkrYIRuZdCZSZAziaHaIzfWdV/5gymsloeJyO64t2reM5MkH yKHg==
X-Gm-Message-State: ALoCoQnS5beriN3KM3az8NYlinlbcJbn7FfthcbqhZskZcBJ4pP6a/vs2oLYKxX9MwRFRf8mUfDe
MIME-Version: 1.0
X-Received: by 10.112.160.138 with SMTP id xk10mr23417598lbb.119.1446049269937; Wed, 28 Oct 2015 09:21:09 -0700 (PDT)
Received: by 10.112.138.72 with HTTP; Wed, 28 Oct 2015 09:21:09 -0700 (PDT)
In-Reply-To: <01f601d11180$eb2372b0$c16a5810$@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> <CABCOCHQok6Kx_=Y5eQ4sjK5O912EibPLXM0n_c4zFSbMs_Z-Gg@mail.gmail.com> <01f601d11180$eb2372b0$c16a5810$@ndzh.com>
Date: Wed, 28 Oct 2015 09:21:09 -0700
Message-ID: <CABCOCHSdHrKg2sUJTq=SOBk3OSP_8WmuHaJFK=iuvhrBMAtEcg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="001a11c38b901018ef05232c954d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/sCVD1VGyTpD0zfcTzuvFFmJG28A>
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: Wed, 28 Oct 2015 16:21:14 -0000

Hi,

I will be there Sat. night, so anytime from Sunday to Friday is OK
(except WG meetings I have to attend).

The YANG validation should fall out for free if the architecture
is good enough.  Something as simple as YANG "max-entries"
should be obvious, but that does not seem to be the case.

There was a slide from Jeff way back that had "running" and
"ephemeral" as "sibling datastores".  The intended config
was derived by the I2RS agent somehow.   This is how Phil described
the Junos implementation to me.  The router picks data from the
dynamic datastore to activate.  It is not a direct API to operational state.

Understanding the differences between panes of glass and sibling datastores
might be useful. Something to talk about next week.


Andy



On Wed, Oct 28, 2015 at 6:02 AM, Susan Hares <shares@ndzh.com> wrote:

> Andy:
>
>
>
> The two options were a choice – not both.  I’m not sure how to take the
> document toward this major change. I think I need in person time at IETF to
> talk about this.
>
>
>
> When do you arrive at Yokohama?
>
>
>
> Sue
>
>
>
> *From:* I2rs-proto-dt [mailto:i2rs-proto-dt-bounces@ietf.org] *On Behalf
> Of *Andy Bierman
> *Sent:* Monday, October 26, 2015 4:18 PM
> *To:* Susan Hares
> *Cc:* Jeffrey Haas; i2rs-proto-dt@ietf.org
> *Subject:* Re: [I2rs-proto-dt] couple YANG details
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
>