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
