Hi Juergen, Understood, but this doesn't really address our problem here. We want to see how we can apply YANG to meet our needs, not the other way round. Hence the suggestion to explore the use of metadata here. --- Alex
-----Original Message----- From: Juergen Schoenwaelder [mailto:[email protected]] Sent: Monday, October 26, 2015 11:19 AM To: Alexander Clemm (alex) <[email protected]> Cc: Martin Bjorklund <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Kent Watsen <[email protected]> Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) In YANG, it is assumed that config true nodes exist in a datastore where all config true nodes are treated the same. A datastore is the unit of validation and we don't want to have a valid configuration datatore become invalid arbitrarily. This is why config true nodes are not allowed to depend on config false nodes (state data that can change arbitrarily). /js On Sat, Oct 24, 2015 at 01:15:55AM +0000, Alexander Clemm (alex) wrote: > 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 > > > > > > > > > -- 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
