"Alexander Clemm (alex)" <[email protected]> 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.
What happens in your model if a user-defined network has a reference to a server-provided network, and the sever decides to remove its network? I see no special text in your document about this case. /martin > 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/> > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
