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