Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > On Thu, Aug 06, 2015 at 02:50:04PM +0200, Ladislav Lhotka wrote: >> >> >> If there is no ephemeral data, then config data is what counts. However, if >> some config parameters may be overriden by ephemeral values, then a separate >> validation of running is not sufficient - it may be in conflict with >> ephemeral data. >> >> I guess the purpose of semantic rules and validation is to make sure the >> parameters that the device uses, no matter where they come from, are correct. >> > > So far, validation concerns a configuration data store, no more and no > less. Expanding this to something different will be a major change how > the curent protocol and its implementations work. > >> Of course it was. You didn’t answer my question though, so let me expand my >> example into the following scenario: >> >> 1. The device boots, values of valid-lifetime and preferred-lifetime in >> running are initialized from startup to v and p, respectively, where p < v. >> The device sends RAs with there values, everything’s OK. >> >> 2. I2RS sets the ephemeral value of valid-lifetime to v’ where p < v’ < v. >> The device now sends RAs with p and v’, which is still OK. >> >> 3. A NETCONF client attempts to change preferred-lifetime in running to p’ >> where v’ < p’ <= v. Should this edit be rejected? On one hand, running >> continues to be perfectly valid, but on the other hand RAs with values of p’ >> and v’ are broken. > > The running config is valid. I think it is today an implementation > issue how any conflicts with other dynamic information are resolved > (e.g., whether the running config in this case overwrites or deletes > the now broken ephemeral value or whether the NC server signals a > runtime error while processing the edit-config - which would not be a > validation error). > > We currently understand what a valid configuration datastore > means. This is goodness and we should work hard to preserve this. > > When we add ephemeral configuration datastores, it is not clear what > it means for them to be valid or whether we also have to think in > addition in terms of validation of the resulting 'merged > datastore'. Some people also wanted to allow references from ephemeral > configuration data to operational state data, which adds another > dimension of complexity to the picture. > > All I can say at this point in time is that the precise semantics of > validation of ephemeral data are rather unclear to me. And there may > also be a risk to define validation semantics that at the end nobody > will implement fully because it does not scale (e.g., because it > requires to monitor significant amounts of operational state to detect > changes that trigger re-validation).
RFC 6241 says that running datastore contains "the complete configuration currently active on the device". However, ephemeral datastore is also designed to contain active (non-persistent) configuration, and I understand it can sometimes override running so that certain parameters in running become inactive. In other words, the ephemeral datastore competes with running for providing active configuration to the device. I think there have to be rules for merging configurations from running and ephemeral, and producing configuration that's really active on the device. To this end, the openconfig idea of intended versus applied configuration might be useful. We would in fact have - running = configuration intended by NETCONF, - ephemeral = configuration intended by I2RS, - applied = active configuration, result of merging/arbitrating running and ephemeral The intended configurations may be validated separately but it is the applied configuration whose validity really matters. This approach could also be generalised - an additional management interface would just contribute its own intended configuration. Lada > > /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/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
