Alex, I can have config that applies to a node named 'foo'. If the node named 'foo' does not exist, the config will not be applied but it remains valid config. This is how we deal with interfaces. You write config for an interface with a certain name. As long as a corresponding interface does not exist, this config will be ignored. The point of this exercise is that it decouples the lifetime and validity of the config from the lifetime of something that may change arbitrarily.
/js On Mon, Oct 19, 2015 at 09:42:31PM +0000, Alexander Clemm (alex) wrote: > Hello Juergen, > > can you please explain what you mean by name bindings? YANG does not provide > support for name bindings (at least not a la GDMO). > > Looking at RFC 7223, I can see the distinction between interface-ref and > interface-state-ref. There certainly is an analogy between interfaces and > topology, and the discussion section 3.1 of RFC 7223 and the discussion here. > Still, the interfaces model is different and follows different > requirements/patterns that don't make it directly applicable. Layering etc > are not included as part of the base model, but supported via a design > pattern where it is added as part of augmentation specific to a given > interface type, and being specific which type of interface to reference. I > don't see anything describing the analogy of having a (configured) set of > data - e.g. a (configured) topology with a (configured) set of nodes, links, > etc - and allowing the items in this to refer to e.g. a (server-provided) > topology. > > In your email, you state "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". How would this work? With "refer by name" you > don't mean an actual reference, you mean use "refer by name" to refer to data > that is operational state. In other words, you are punting the problem and > leave it to the user and implementation to deal with it. Instead of using > e.g. an actual reference, you are using simply a string. The concern is that > when using a reference, a framework might have problems ensuring referential > integrity in case the referred object goes away etc - but this solution does > not address the concern, it simply pushes it to somewhere else. > > At the same time, you do now have two parallel trees, providing additional > complexity as outlined earlier, specifically if we want to be able to express > some of the integrity constraints (supporting nodes of a node have to be part > of a supporting topology, etc). Well, perhaps we no longer need to be > concerned about these, since we are pushing this problem to the user anyway. > However, I am not sure why we would trust users to deal with all those > integrity problems, but not trust them e.g. with a "server-provided" > attribute. Additional complexity in the model would be fine if it resulted > in a gain, but I don't think this would be the case - to the contrary. > Introducing what you call a "fence" instead seems to be the preferrable > solution. The ability to support this could be indicated by a feature, if > that helps. > > --- Alex > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:[email protected]] > Sent: Monday, October 19, 2015 12:56 PM > To: Alexander Clemm (alex) <[email protected]> > Cc: Andy Bierman <[email protected]>; [email protected]; Martin Bjorklund > <[email protected]>; Ladislav Lhotka <[email protected]>; 'Alia Atlas' > <[email protected]>; 'Jeffrey Haas' <[email protected]>; Susan Hares > <[email protected]> > Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) > > 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/> -- 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
