On Mon, Oct 19, 2015 at 06:24:10PM +0000, Alexander Clemm (alex) wrote: > Hi Juergen, > > I think one of the key statements you make below is this: > " Recall also that YANG does not allow configuration data to depend on state > data." > > Note that this is not the case in the current model. The current model is > essentially all configuration data. Of course, we have this flag to indicate > who supplied that data (and is hence maintaining it). >
I expect that config true objects can be modified by clients. And I expect that client maintained config true objects do not depend on server provided operational state. The 'server-provided' leaf seems to 'overrule' both principles. > You argue that we should instead "split" the model and introduce operational > data to reflect what is populated by the server. However, doing that > introduces precisely new issues - and you have just brought another argument > why this may be a bad idea and may not even work. Topologies _are_ layered, > and we need to be able to express that in the model. Now, if we have a > topology that is server-provided, hence (per your statement) to be > represented by operational data only, how do we build an overlay topology > that is "configured" on top of it? If the answer is "we can't, unless we > replicate the server-provided topology into the network configuration (which > makes no sense)", we are screwed. Now, we might build it on top if we remove > all references / dependencies on the underlay from the model and punt the > problem to the user. Basically, no longer have the model express vertical > relationships. Not a good solution, IMHO. > How do you suggest we address this? The ability to express layering > relationships between topologies, including cases where topologies originate > from different sources (discovered/server-provided vs configured), is a > requirement. It is not an artefact of our model, it is something that we > need to capture as part of the model. There may not be a "nice" way of doing > this within the YANG framework, yet it is important that we find a way to do > this. The current solution to this - having the model as configuration data, > and including a parameter to indicate who supplies the data and is > maintaining it - appears to be cleanest and clearest solution (or perhaps the > "least bad") that results in the model of least complexity. In the interfaces model, this problem got solved via name bindings. I can configure an interface but as long as the matching interface is not present, the config won't be applied to the interface. Translated to your domain, I can configure an overlay that refers by name to other layers. If those layers do not operationally exist, the overlay will exist in config but not in the operational state tree. > Perhaps there is something we can simply change about the "server-provided" > object to address your concerns? We can make it config (to address your > issue that triggered this, the presence of a r/o object in a tree that is > otherwise r/w). You can address my concern by doing away with 'server-provided' and by properly separating config from operational state. ;-) Assuming proper authorization, a NC/RC client should be able to change any object in a configuration datastore. I am concerned about data model specific 'fences' that indicate that some portions of a configuration datastore are behaving in special ways. /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
