Alex, Is the idea that the server-provided data is normal config? I.e., if the server wants to modify this data it behaves like a normal client? (conceptually...) And the server-provided data can be modified by anyone with proper access rights?
/martin "Alexander Clemm (alex)" <[email protected]> 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). > > 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. > > 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). > > Thoughts? > --- Alex > > > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:[email protected]] > Sent: Sunday, October 18, 2015 3:13 AM > To: Alexander Clemm (alex) <[email protected]> > Cc: Ladislav Lhotka <[email protected]>; [email protected]; Martin Bjorklund > <[email protected]>; Andy Bierman <[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 Thu, Oct 15, 2015 at 10:59:31PM +0000, Alexander Clemm (alex) > wrote: > > Hello Juergen, > > > > responses inline, delimited with <ALEX> > > > > --- Alex > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:[email protected]] > > Sent: Wednesday, October 14, 2015 11:35 PM > > To: Alexander Clemm (alex) <[email protected]> > > Cc: Susan Hares <[email protected]>; Andy Bierman <[email protected]>; > > [email protected]; Martin Bjorklund <[email protected]>; Ladislav Lhotka > > <[email protected]>; 'Alia Atlas' <[email protected]>; 'Jeffrey Haas' > > <[email protected]> > > Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) > > > > On Fri, Oct 09, 2015 at 09:55:19PM +0000, Alexander Clemm (alex) > > wrote: > > > > > > The only item in the topology that is read-only concerns the > > > "server-provided" flag, but this concerns a separate issue that was > > > also discussed (I am not sure if this is what you are referring to). > > > It is analogous to the other discussion concerning distinguishing > > > configuration that has been intended, versus one that is in effect > > > etc . This concerns the issue that some topologies are populated by > > > the server whereas some topologies can be populated by client > > > applications. > > > > Yes, this is what the concern is about. > > > > > We have had discussions in the past whether to "split this up", > > > having a (rw) branch to populate "intended" topologies and a (ro) > > > branch for topologies "in effect". > > > > This is the normal way to do this in YANG. And this goes back to what > > was driving us for years, namely to clearly separate config from > > state. This module makes this distinction a runtime property > > controlled by a data model specific mechanism. None of the generic > > tools out there will be able to understand this. > > > > <ALEX> > > I think the issue is more related to the current discussion with > > regards to openconfig and "intended configuration" and "applied > > configuration". If YANG had an existing solution for this, we would > > not have this discussion. The reason I believe this is similar is > > that you can view the "applied configuration" as the "server-provided > > configuration" (network topology, in our case), and the "intended > > configuration" as the, well, configured or intended network topology > > in our case. That said, the issue is not identical - whereas in the > > openconfig case every "applied configuration" has an accompanying > > "intended configuration", in our case this is not necessarily the case > > - you can have "applied" [network topologies] that were provided by > > the server / the network itself, not configured by anybody. > > </ALEX> > > I think this has nothing to do with intended or applied config. Your > 'server supplied topology' appears to me to be operational state and > not configuration data. > > > > We decided against it for various reasons - every piece of > > > information would essentially be duplicated inside the model (this > > > is not your normal config vs oper data distinction, but would > > > essentially reflect a limitation of the framework), leading to > > > unnecessary additional complexity in the model (every augmentation > > > has to be conducted in two places), more complex validation rules, > > > etc. > > > > I do not understand why this is not a normal config vs oper data > > distinction. Please explain. > > > > <ALEX> > > A normal distinction would be e.g. the type of model we have in RFC > > 7233 - separate trees with distinct data, some clearly part of > > configuration, other clearly operational data. > > In this case, this is different. You have the same data. However, in > > some cases it is populated by a client, in other cases by the server. > > YANG requires the categorization of data as config false or true. In > > this case, this categorization does not always apply - or, the > > categorization depends on the particular instance. > > </ALEX> > > So you have operational state which is partially populated by the > server and partially populated from config. I fail to see how this is > any different from other cases, including network interfaces as > defined in RFC 7233. Recall also that YANG does not allow > configuration data to depend on state data. > > > I do not understand how this leads to more complex validation rules. > > Please explain. > > > > <ALEX> > > > > One example concerns the supporting nodes/links/TPs. > > > > We want to be able to express that, for example, a node in one network > > is supported by a node in an underlay network. For this purpose, we > > are referencing a node in another (underlay) network. So that we > > cannot reference an arbitrary node in an arbitrary network, we want to > > make sure that the supporting node is part of a "supporting-network" > > of the same network. > > > > Currently, we have the following definition: > > > > list supporting-node { > > key "network-ref node-ref"; > > description > > "Represents another node, in an underlay network, that > > this node is supported by. Used to represent layering > > structure."; > > leaf network-ref { > > type leafref { > > path "../../../supporting-network/network-ref"; > > } > > description > > "References the underlay network that the > > underlay node is part of."; > > } > > leaf node-ref { > > type leafref { > > path "/network/node/node-id"; > > } > > description > > "References the underlay node itself."; > > } > / > > } > > > > > > If we were to split the model, when we configure a node, we will have > > to account for the fact that the supporting node could be either part > > of a "configured" network itself, or of a network that has been > > "server-provided". That is, we need to be able to allow for both > > possibilities. > > Again note that YANG requires that configuration data does not depend > on state data. You seem to be breaking this rule, no? > > > To do this, we would no longer be able to have the network-ref to be > > part of the key for supporting-node - we would have to replace > > network-ref with a choice of two nodes that reference either a > > server-provided network ("branch 1"), or a configured network ("branch > > 2"). As a result, we will have to introduce a separate way to > > reference elements in list supporting-node. All of this results in > > considerable additional complexity. Or do you see an easier way? > > > > </ALEX> > > I do not think this is the solution. YANG requires that constraints on > config true nodes can only refer to other config true nodes in the > datastore where the node with the constraint exists. See section 7.5.3 > and section 7.19.5. And concerning leafref, section 9.9 says that a > leafref may only point to configuration. I believe this I-D is > violating the distinction between configuration and state data. > > /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
