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> > 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> 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. 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> /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
