Juergen:
>I understand YANG validation rules and I understand YANG's notion of configuration datastores. I do not >think this matches your ephemeral configuration validation. This does not provide a technical discussion of: a) what you understand the ephemeral configuration validation rules to be, b) why you do not the model matches the configuration validation rules. 1 Data Model is a great idea for NETCONF/NETMOD. However, it should encompass Ephemeral data:== ephemeral state ::== Ephemeral configuration + Ephemeral operational state Cheers, Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:[email protected]] Sent: Tuesday, May 31, 2016 1:13 PM To: Susan Hares Cc: 'Jeffrey Haas'; [email protected]; 'Benoit Claise'; 'Alia Atlas' Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements [snip] > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, May 31, 2016 10:26 AM > To: Susan Hares > Cc: 'Jeffrey Haas'; [email protected]; '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. >[Juergen]: I understand YANG validation rules and I understand YANG's notion of configuration datastores. I do not think this matches your ephemeral configuration validation. [sue:] This is not a technical response. Please provide: a) what is the understand you have of the I2RS ephemeral validation rules, b) Why you think it does not match Yang validation rules or Yang's notion of configuration datastores. > >> 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. > ======== Juergen: >So how is this broken? This is the only time 'ephemeral operational state' shows up in -09. Sue: The inclusion of operational state has been in the I2RS RIB data model for over 18 months. The I2RS WG had assumed that the I2RS Data models would be examined when creating ephemeral datastore models. So, the inclusion in -09.txt is for your benefit and for others who do not read the I2RS ephemeral-only data models. Juergen: >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'. Ephemeral comes in two varieties: configuration and operational state. The examples in my interim presentation provide you with an example of configuration state. The operational state can also be see by BGP using the node-type as an operational state variable. >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) The problems with the definitions come to the fact the netmod WG has not settle on a definition of operational state. - ephemeral operational state - ephemeral state which is operational (Node-type as operational state in the examples in my presentation) >- ephemeral state - the combination of I2RS ephemeral configuration and I2RS ephemeral operational state >- ephemeral config - configurations which are ephemeral (see the requirements). Ephemeral configuration only - would be I2RS RIB. >- derived state (ephemeral) - derived state = operational state that exists which is defined by ephemeral object in an I2RS data model. Derived state is a NETMOD's term. >- derived state (opstate) - derived state = operational state that is not ephemeral >- mixed ephemeral config (ephemeral + config) - see the BGP examples in my interim slide Juergen: >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.) Ephemeral data = ephemeral state = ephemeral = ephemeral configuration + ephemeral operational state >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'? See above. To answer your question, no it is not. Snip to next technical discussion >> Been iterating for a while in I2RS. Love to hear technical reasons why the >> ephemeral datastore architecture does not work for you. Juergen: >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. The fact that the NETCONF/NETMOD people are proposing one model is great. The I2RS work has been existing for 2 years and I2RS should be considered as one of the key requirements for NETCONF datastore definitions. > 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. Excellent technical point on 1 model. The problem is your model does not support: Ephemeral data == ephemeral state == ephemeral configuration + ephemeral operational-state /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
