Hi Martin, maybe option 1 provides a way out here. This also has the least impact on the existing design and implementation, hence preferable.
However, I still feel that we are dealing with a limitation of the YANG framework here. I think we are dealing with a use case that was not really foreseen in the YANG design, i.e. that we might run into data that has instances that can indeed be authoritatively owned by a server versus others representing more traditional configuration. The one aspect that not really address by making it regular config concerns your assertion that "any other client can modify what this client wrote". Access rights could provide a solution, but not in the way as currently defined via NACM, since we would need to differentiate access rights at the instance level, not at the module definition level. Rather than seeing how we can make our requirements somehow fit a rigid interpretation of the YANG framework (that does not allow for special treatment / behavior of special cases), I would like to see whether the YANG framework can be flexible enough to still support what we are trying to do. Kent made what I thought was a very interesting suggestion at the interim, asking whether this would be an application for metadata. I think this is something that we might leverage here. We could introduce a metadata item that indicates for configuration information whether that was populated by a server, so really should not be modified by other clients (or, when modified, will presumably be "changed back" by the server). Or, that might simply be locked by the server. Thoughts regarding that suggestion? --- Alex -----Original Message----- From: Martin Bjorklund [mailto:[email protected]] Sent: Friday, October 23, 2015 12:17 AM To: Alexander Clemm (alex) <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) "Alexander Clemm (alex)" <[email protected]> wrote: > Hi Martin, > > We can nitpick over how to best express this This isn't nitpicking; I am trying to understand what you had in mind. And it seems Juergen is correct. You essentially want to mix config and operational state in a single list. This is not possible to express in YANG, so you change the semantics of the formal statements with descriptions. I don't think this a good idea. I can think of two alternatives to the current design that don't violate YANG: 1) Keep the single config true list, w/o the server-provided leaf, and explain in text that there might be a client "internal-to-the-server" that behaves just like any other client (specifically respects locks, makes sure the end result is valid, and any other client can modify what this client wrote (module access rights)). 2) Split the model into two, one config list and one oper list. References in the config list can either be by name (implicit) or use the new YANG 1.1 syntax "require-instance false"; /martin > , but hopefully the > general sense of what the requirement is and what I was trying to > express is clear. You can have an outside client application maintain > some topologies / list elements, and have others maintained an > populated by the server - or arguably an app embedded in the server. > The difference from the "normal" client is that really it is that we > want the server / embedded app that is the authoritative owner of the > information. > > Cheers > --- Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:[email protected]] > Sent: Monday, October 19, 2015 11:07 PM > To: Alexander Clemm (alex) <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) > > "Alexander Clemm (alex)" <[email protected]> wrote: > > Hi Martin, > > > > "So how is the server-provided leaf supposed to be implemented, and > > how is it supposed to be used?" > > > > When a network topology is populated by the server, the > > server-provided leaf is supposed to be set to true. > > But you earlier wrote that when the server wants to change something > it would behave as a normal client. > > > When a network topology is populated by a client app (through > > "regular" configuration), the server provided leaf is supposed to be > > set to false. > > > > For any given network topology, when the corresponding > > "server-provided" leaf is set to "true", attempts to edit the > > configuration of that topology are to be rejected. > > This also goes against what you acknowledged previously - "the > server-provided data can be modified by anyone with proper access > rights" > > > /martin > > > > > > Alternatives to the current design include making the leaf "config > > true", or moving it outside (just this leaf) for a list that > > indicates for each topology whether it is server-provided or not (in > > a separate "state" branch). > > --- Alex > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:[email protected]] > > Sent: Monday, October 19, 2015 1:27 PM > > To: Alexander Clemm (alex) <[email protected]> > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected] > > Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) > > > > "Alexander Clemm (alex)" <[email protected]> wrote: > > > Hi Martin, > > > > > > One model for the data that is server-provided is to assume an app > > > (which could be embedded on the same server) that knows how to > > > discover the network, then populates the data accordingly. > > > > > > [Of course, we would not want any random client app just being > > > able to "mess" with that data. The expectation is generally > > > clearly access to this will be restricted / controlled. The > > > topology instances that were populated by the "server-provided > > > app" should not be "touched" by other apps - it is the > > > "server-provided" app that is responsible for maintaining them.] > > > > > > So I assume the answer to your question is "yes", but with a bunch > > > of caveats. > > > > So how is the server-provided leaf supposed to be implemented, and > > how is it supposed to be used? > > > > > > /martin > > > > > > > > > --- Alex > > > > > > > > > -----Original Message----- > > > From: i2rs [mailto:[email protected]] On Behalf Of Martin > > > Bjorklund > > > Sent: Monday, October 19, 2015 11:32 AM > > > To: Alexander Clemm (alex) <[email protected]> > > > Cc: [email protected]; [email protected]; > > > [email protected]; [email protected]; > > > [email protected]; [email protected]; [email protected] > > > Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) > > > > > > 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 > > > > > > _______________________________________________ > > > i2rs mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
