Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input

Andy Bierman <andy@yumaworks.com> Wed, 08 June 2016 17:39 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D788112D7B6 for <rtg-yang-coord@ietfa.amsl.com>; Wed, 8 Jun 2016 10:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 DQS8MPclIv9X for <rtg-yang-coord@ietfa.amsl.com>; Wed, 8 Jun 2016 10:39:10 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 46F1412D7B8 for <Rtg-yang-coord@ietf.org>; Wed, 8 Jun 2016 10:39:10 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id c72so14372023ywb.1 for <Rtg-yang-coord@ietf.org>; Wed, 08 Jun 2016 10:39: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; bh=Q8W4/XuhBcsClMt1mqneZ8VUsrTLTbAG1TVaeBAWJI4=; b=h1q7h3WhmnOOkCcgtzWHYR5NxB6D91NUupY/JnWIW/VtAdyTG2JQYsxeMclljIRtaY 6KfzLq51TWCpJFhuc86cCXONyn1dWfT7r69e4R5bWEs/gRnO+usi2T/bkjxT7OdP2THI NJtWFRJh9kcNgOD9dR765PunnC4rQQquiFm9fJJ71WXR7CUNFTQusXx2qiX1GqurluFg dw3Gdsl9TmblQPchgerRY9UrbZfndmKolKQwdpHU20FpOsHK1boqUUT7stvByLy2jWvk mgUu9OhNeLhbhqWzj+LUnjnUAvdxZ0ASlTjVZK45SD3ZkAKJEdO9V+gbQo4aSp6Trpij iFCA==
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; bh=Q8W4/XuhBcsClMt1mqneZ8VUsrTLTbAG1TVaeBAWJI4=; b=cSDxucKHoHbeNQWeZBGhPdszoYlvDD6trInKdYKu0XGvWuTWnTNCJZ+7+bAWs9N8Av d537UVEyXSFOTUI6qgkGwe/KaIdleQ/M1QQs+14dup7Wfj7TOwKOPHNI9v0Vd3H7m4x2 Za/Dp/uxh7K5ZEpZtHgicpYPvm96e9GxIhRwF9IZnD20QINKwT/NdRlOskhG0Q1Tlppk FX3ekbCdVjV7WTF9P+0fvjzzbJ2abispoDg7j1fTHRV7siUJsXhofRI9RE/ZyGRyDaLF 1HQAVa+JFhLN/i6d2APlZ6D8rcQsBrvWQhMEWfDcSWYRAs2xkHNUWya5ATKNmc8TX4t8 4jUw==
X-Gm-Message-State: ALyK8tJvrciIFemLZlR2eLsLAsmyqay4ycTN2/rJgV+C0FQESYtMojR5TnUKvdynmC2c94WJQUGJ9tN4ESFuZQ==
MIME-Version: 1.0
X-Received: by 10.37.10.4 with SMTP id 4mr3405837ybk.160.1465407549316; Wed, 08 Jun 2016 10:39:09 -0700 (PDT)
Received: by 10.37.42.77 with HTTP; Wed, 8 Jun 2016 10:39:09 -0700 (PDT)
In-Reply-To: <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net>
References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net>
Date: Wed, 8 Jun 2016 10:39:09 -0700
Message-ID: <CABCOCHTY6pcW-RzXJsk6Ft2OFwCL2GwixAi_dH923noYKmXo0A@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Lou Berger <lberger@labn.net>
Content-Type: multipart/alternative; boundary=001a113dde166dd84a0534c7c88d
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-yang-coord/NECDRTmlQGlMvuY5StnahohdqKw>
Cc: "rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org>, Benoit Claise <bclaise@cisco.com>, Alia Atlas <akatlas@gmail.com>, Susan Hares <shares@ndzh.com>, "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2016 17:39:14 -0000

Hi Lou,

I would say 2 steps ahead.
Step 1 seems to be to reconfirm the meeting room consensus from Yokohama
(model-based vs. protocol-based)

Step 2 is usually picking a starting point for a solution draft.

Step 3 is when people can start detailed solution reviews.

IMO [4] is a good starting point but there are many open issues that need
to be resolved,
possibly addressed in the other drafts.


Andy


On Wed, Jun 8, 2016 at 9:23 AM, Lou Berger <lberger@labn.net>; wrote:

> Sue,
>
> I think you're looking a step beyond the scope of decision we're
> considering now. This is a fine thing, and certainly the right thing to
> be thinking about from the I2RS (or any other WG working on YANG models
> that is considering operational state for that matter) perspective.
>
> The decision at hand is to choose between directions A and B.  I think
> you are saying you that you like direction B but that the details aren't
> sufficient for your (WG's) needs.  Is this correct?
>
> If so, then I think you're point is that [4] and [5] need work.  We
> agree with this statement and we believe consistent with the statement in
> B:
>
>     -- and that the WG needs to
>        formalize an opstate solution based on the approach
>        discussed in [4] and [5].
>
> So, once the WG closes on direction B (before Berlin), the WG can then
> start discussing details of the WG's version of [4] and [5] -- and
> issues on ephemeral support makes sense to discuss then if they still
> haven't been addressed.   Of course discussion on the individual drafts
> don't need to wait for the decision on basic direction.
>
> Make sense?
>
> Lou
>
> On 6/8/2016 12:10 PM, Susan Hares wrote:
> > Lou:
> >
> > Thank you for your work on the two options.  I'd like to comment on the
> > following statement in your message statement, and reference a few
> things in
> > [4] and [5] regarding ephemeral state:
> >
> > You state:
> > "  2) Model OpState using a revised logical datastore definition
> >        as introduced in [4] and also covered in [5]. There is
> >        also a variant of this that we believe doesn't significantly
> >        impact this choice.
> >        With this approach, model definitions need no explicit
> >        changes to support applied configuration."
> >
> > In [4], the author states:
> >
> >    "o  The model foresees ephemeral datastores that are by definition not
> >       part of the persistent configuration of a device.  These ephemeral
> >       datastores are considered to interact with the rest of the system
> >       like any other control-plane mechanisms (e.g., routing protocols,
> >       discovery protocols).  [XXX Note that this is different from what
> >       is described in some of the I2RS documents.  XXX]"
> >
> > In [5], the author states:
> >
> > "5.5.  Ephemeral Configuration Datastore (Optional)
> >    This document does not intend to formally define an Ephemeral
> >    Configuration Datastore.  In particular, it must be noted that the
> >    ephemeral configuration datastore described here does not match that
> >    described in version -09 of draft-ietf-i2rs-ephemeral-state
> >    [I-D.ietf-i2rs-ephemeral-state].  Instead, it describes conceptually
> >    how such a datastore (restricted to configuration only) might fit
> >    into a conceptual refined datastore model."
> >
> > Therefore, the result of I2RS WG spending 2 years writing requirements
> for
> > the ephemeral data store that both option 2 documents "do not  match" the
> > I2RS ephemeral requirements set.  [4] lumps ephemeral with operational
> > state.  [5] provides an ephemeral architecture closer to I2RS ephemeral
> > requirements, but does not understand that
> draft-ietf-i2rs-ephemeral-state
> > is a requirements document.    Your statement " With this approach, model
> > definitions need no explicit changes to support applied configuration"
> > cannot be true if you consider the I2RS data models (RIB, topology).
> >
> > How is option (2) a reasonable design for ephemeral state?  I have spent
> the
> > last week answering questions to Juergen [4] on the I2RS ephemeral state.
> > After our discussion, he did not have any specific suggestions to change
> > these requirements
> > (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html).
> >
> > Can I have an option 2b that considers ephemeral state based on the
> > requirements listed by I2RS?
> >
> >  Sue Hares
> >  I2RS WG-chair
> >
> > -----Original Message-----
> > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf
> Of
> > Lou Berger
> > Sent: Wednesday, June 08, 2016 9:06 AM
> > To: Rtg-yang-coord@ietf.org
> > Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions:
> > update and request for WG input
> >
> > FYI this decision is likely to have some impact on models under
> development,
> > including in the routing area. Comments on the message itself should go
> to
> > netmod.
> >
> > Lou
> >
> >
> > --- Forwarded message ---
> > From: Lou Berger <lberger@labn.net>;
> > Date: June 7, 2016 10:20:23 AM
> > Subject: [netmod] Opstate solutions discussions: update and request for
> WG
> > input
> > To: netmod WG <netmod@ietf.org>;
> > CC: netmod-chairs@ietf.org
> >
> > All,
> >
> > We want to provide an update based on the off line discussions related to
> > OpState Solutions that we have been having and solicit input from the WG.
> >
> > All authors of current solution drafts [1,2,3] together with those who
> > helped conduct the solutions analysis* were invited to the these
> discussions
> > -- with the objective of coming up with a single consolidated proposal to
> > bring to the WG. (I/Lou acted as facilitator as Kent and Juergen were and
> > are involved with the technical details.)
> >
> > The discussions have yielded some results but, unfortunately, not a
> single
> > consolidated proposal as hoped, but rather two alternate directions --
> and
> > clearly we need to choose one:
> >
> >     1) Adopt the conventions for representing state/config
> >        based on Section 6 of [1].
> >
> >        From a model definition perspective, these conventions
> >        impact every model and every model writer.
> >
> >     2) Model OpState using a revised logical datastore definition
> >        as introduced in [4] and also covered in [5]. There is
> >        also a variant of this that we believe doesn't significantly
> >        impact this choice.
> >
> >        With this approach, model definitions need no explicit
> >        changes to support applied configuration.
> >
> > >From a technology/WG standpoint, we believe an approach
> > that doesn't impact every model written (i.e., #2) is superior.
> > The counterpoint to this is that the conventions based approach (i.e.,
> #1)
> > is available today and being followed in OpenConfig defined models.
> >
> > We would like to hear opinions on this from the WG before declaring one
> of
> > the following as the WG direction:
> >
> >     A) models that wish to support applied configuration MUST
> >        follow conventions based on [1] -- and the WG needs to
> >        formalize these conventions.
> > or
> >     B) no explicit support is required for models to support
> >        applied configuration -- and that the WG needs to
> >        formalize an opstate solution based on the approach
> >        discussed in [4] and [5].
> >
> > We intend to close on this choice before Berlin.
> >
> > Thank you,
> > Lou (and co-chairs)
> >
> > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
> > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
> > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
> > [4]
> https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
> > [5]
> https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
> > * - Chris H. and Acee L.
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >
> >
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>