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

["Susan Hares" <[e-mail]>]

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:[e-mail]] On Behalf Of
Lou Berger
Sent: Wednesday, June 08, 2016 9:06 AM
To: [e-mail]
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 <[e-mail]>
Date: June 7, 2016 10:20:23 AM
Subject: [netmod] Opstate solutions discussions: update and request for WG
input
To: netmod WG <[e-mail]>
CC: [e-mail]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod



_______________________________________________
Rtg-yang-coord mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtg-yang-coord