Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements

[Andy Bierman <[e-mail]>]

Hi,


I agree with your concerns.  The opstate design team should not be ignoring
ephemeral state
and the I2RS WG should not be ignoring the opstate work.  I prefer to see 1
RFC on datastores
that defines a coherent and cost-effective framework that works for years
to come.
New implementations should opt-in to using new datastores.  Old
implementations must
continue to work even if the new datastores are ignored.

Isn't all operational state ephemeral by definition?
Doesn't proper management of a system with ephemeral data require
just 1 view of operational data which reflects current system behavior?

At some point the WG needs to agree on normative text instead of iterating
on requirements forever.  Some of them will fall out as important vs.
irrelevant
if there is an actual protocol spec to review.  E.g. secondary ID cannot
be "may keep" and "SHOULD report".  Either the standard protocol has an
official use for secondary client ID or it doesn't.


Andy


On Tue, May 31, 2016 at 10:13 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Tue, May 31, 2016 at 11:12:13AM -0400, Susan Hares wrote:
> > Juergen:
> >
> > Thank you for your quick response.  See my comments below.   I believe as
> > you said " I may be ignorant but we have to look at how things fit
> together"
> > - so I have provided more information.  I believe the I2RS model is
> > workable, and I look forward to your informed review of this information.
> >
> > Version -09 of Ephemeral-state is released to make it clear ephemeral
> state
> > has ephemeral configuration and ephemeral operational state.   Click
> below
> > for the draft:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/
> >
> > Sue
> >
> > -----Original Message-----
> > From: i2rs [mailto:[e-mail]] On Behalf Of Juergen
> Schoenwaelder
> > Sent: Tuesday, May 31, 2016 10:26 AM
> > To: Susan Hares
> > Cc: 'Jeffrey Haas'; [e-mail]; 'Benoit Claise'; 'Alia Atlas'
> > Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am -
> 11:00am
> > - Topic: Ephemeral State Requirements
> >
> > On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote:
> > >> Juergen:
> > >>
> > >>
> > >>
> > >> Thank you for the second response.    The questions were on version 8
> of
> > the
> > >> draft.  Jeff wanted to review version 8 before posting - so I delayed
> > >> posting of version 8 until this morning.    I've answered your
> questions
> > >> based on version 08.
> > >>
> > >> I think you understood that the ephemeral datastores defined by i2RS
> > >> are not what you defined in
> draft-schoenw-netmod-revised-datastores-00:
> > >>
> > >>    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]
> > >>
> > >> The difference is that I2RS defines ephemeral configuration and
> > >> ephemeral operational state.  You see this in all of the I2RS data
> > >> modules.  I have augmented your diagram with the proposed I2RS
> datastore.
> > >>
> > >>
> > >>                     +------------+
> > >>                     | <intended> |  //  Subject to validation
> > >>                     | (ct, ro)   | //   e.g., missing resources or
> delays
> > >>                     +------------+   // Here I2RS ephemeral
> configuration
> > fits
> > >>                           |         //  so missing resources/delays
> can
> > be handled
> > >>                           v
> > >>                     +------------+
> > >>                     | <applied>  |    - here I2RS defines ephemeral
> > >>                     | (ct, ro)   |      configuration data store
> > >>                     +------------+
> > >>                           |         // e.g., autodiscovery of values
> > >>                           v
> > >>           +--------------------------------+
> > >>           | <operational-state>            |<-- control plane and
> > >>           | (ct + cf, ro)                  |    ephemeral datastores
> >
> > >> +--------------------------------------------------+
> > >>
> > >>
> > >> Your definitions ignored the WG requirements and the existing
> > discussions.
> > >> Is there a reason why?  I2RS follows the break between operational
> > >> state and configuration data store.
> > >
> >
> > >There needs to be _one_ architectural model.
> > > I may be ignorant but we have to look at how things fit together.
> > >What you are drawing is ignoring for instance the fact that <intended>
> is
> > the subject of configuration
> > > validation while I2RS explicitly states that ephemeral is not part of
> > configuration validation.
> > >So your model is not a workable solution either.
> >
> > Not really, the ephemeral configuration is a part of the configuration
> > validation.  The ephemeral validates as either a stand-alone modules
> > (I2RS-RIB), or as a validation of an augmentation (see examples in the
> > interim presentation).  It is validated at the intended stage of
> > configuration.   Therefore, the proposal discussed by I2RS is workable.
> Your
> > opinion goes against years of NETCONF people suggesting to I2RS that
> > ephemeral configuration and ephemeral operational state is possible.
>
> I understand YANG validation rules and I understand YANG's notion of
> configuration datastores. I do not think this matches your ephemeral
> configuration validation.
>
> > >> o  configuration datastore: When modeled with YANG, a configuration
> > >>       datastore is realized as an instantiated data tree with
> > >>       configuration data.
> > >>
> > >> o  Operational state data is a set of data that has been obtained by
> > >>       the system at runtime and influences the system's behavior
> similar
> > >>       to configuration data.  In contrast to configuration data,
> > >>       operational state is transient and modified by interactions with
> > >>       internal components or other systems via specialized protocols.
> > >>
> > >> This document is proposed on May 12, 2016 and we have been working on
> > >> I2RS for over 3 years.  You provided something that does not satisfy
> > >> the requirements of the existing I2RS data models (prepared for over
> 18
> > months).
> > >
> >
> > > Which I2RS requirements? Please be specific.
> > ==================
> > Ephemeral-REQ-01 to Ephemeral-REQ-04 cover both configuration and
> > operational state.  If that's not clear, then I guess we need to add
> them.
> > Here's the Ephemeral-REQ-01 for version -09 of the text.
> >
> >     Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
> >    not persist across reboots.  If state must be restored, it should be
> >    done solely by replay actions from the I2RS client via the I2RS
> >    agent.  Ephemeral state may consist of ephemeral configuration
> >   or ephemeral operational state, or both.
> > ========
>
> So how is this broken? This is the only time 'ephemeral operational
> state' shows up in -09. So please elaborate whether this is by
> intention in order to express that 'ephemeral operational state' is
> something different than a subset of 'operational state' or even
> better please explain how you think 'ephemeral operational state'
> relates to 'operational state'.
>
> In fact, it would help if terminology would be clearly defined. How do
>
> - ephemeral operational state
> - ephemeral state
> - ephemeral config
> - derived state (ephemeral)
> - derived state (opstate)
> - ephemeral configuration
> - mixed ephemeral config (ephemeral + config)
>
> relate to each other? Let me check draft-ietf-i2rs-architecture-15.txt:
>
> - ephemeral state
> - ephemeral configuration
> - ephemeral data - is data which does not persist across a reboot
>       (software or hardware) or a power on/off condition. Ephemeral
>       data can be configured data or data recorded from operations of
>       the router.
> - ephemeral static state (?)
>
> So is my interpretation right that 'ephemeral data' is the union of
> 'ephemeral configuration' and 'ephemeral state'?  (If my
> interpretation of these terms is correct the probably not all usages
> of the terms are correct in draft-ietf-i2rs-architecture-15.txt; so
> more likely my interpretation is incorrect.)
>
> Given the operational state is by its nature ephemeral, is there a
> distinction between 'operational state' and ephemeral state? Or is
> 'ephemeral state' just a subset of 'operational state' that has been
> influenced by 'ephemeral configuration'?
>
> > > There needs to be _one_ architectural model for all the datastores
> people
> > to introduce in various places
> > > and it does not help to complain.
> >
> > One model for data stores people is reasonable.  However, your model does
> > not work for I2RS.  You have not explained why technically the i2RS model
> > does not work for you.
> >
> > >Please get down to the I2RS requirements that the above proposal does
> not
> > address.
> > See Above.
> >
> > > Make a better proposal. Iterate. There have been quite a few calls
> related
> > to the intended and applied
> > > data store discussions that are not taking place in I2RS land and as I
> > said above we need to come up with a
> > > common architectural model.
> >
> > Been iterating for a while in I2RS.   Love to hear technical reasons why
> the
> > ephemeral datastore architecture does not work for you.
>
> There are many datastores being proposed and at the end they all need
> to work together. Implementations can't support N different datastore
> models that are not aligned. I understand that this concern is not
> your prime problem since your focus is I2RS but please understand that
> other people are proposing other datastores and I do believe
> NETMOD/NETCONF needs to find agreement on a bigger architectural
> picture that addresses the various requirements and enables
> implementations that work in a predictable manner.
>
> > If mention a few NETCONF calls/ your individuals draft, you must compare
> it
> > against the i2RS WG 3 years plus  3 WG drafts to IESG (pub/sub,
> > traceability, protocol-security), and  2 in final review
> (protocol-security
> > environment, ephemeral state).  May I suggest suggesting your draft has
> > precedence or personal behaviors is not a fruitful discussion.  Let's
> keep
> > on the technical discussion.
>
> I just tried to make you aware that some people think we need a common
> and consistent architectural model within NETMOD and NETCONF. I
> pointed to one proposal. There can be others. But at the end, there
> needs to be a single unifying architectural model if we want
> implementations being able to address requirements coming from
> different communities and still behave in a predictable manner.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>