Hi, I agree that adding meta-data will have no affect on a client that thinks it can edit config=true. Especially when the knob that overrides the semantics of the config-stmt is in the configuration itself.
So why can't the interfaces + interfaces-state design be applied here? Given that charter explicitly states read-only topology, why is this even in there? You can define objects in a grouping later. It is OK to reorg objects into/out of groupings if the same "final" syntax and semantics is maintained. Andy On Mon, Oct 26, 2015 at 12:13 PM, Juergen Schoenwaelder < [email protected]> wrote: > I do not think metadata changes the way configuration datastore > validation works. > > /js > > On Mon, Oct 26, 2015 at 07:10:56PM +0000, Alexander Clemm (alex) wrote: > > 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/> > > -- > 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
