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

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

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

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. 


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