> -----Original Message----- > From: Martin Bjorklund [mailto:[email protected]] > Sent: Monday, October 19, 2015 4:27 PM > To: Xufeng Liu > Cc: [email protected]; [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) > > Xufeng Liu <[email protected]> wrote: > > Hi Martin and Alex, > > > > Some of such objects might not be changeable, no matter what access > > right that the client has. Such non-changeable objects are derived > > from other objects in the system. > > That would be config false nodes, right? [Xufeng] Yes. Agree. > > > /martin > > > > > > > Regards, > > > > - Xufeng > > > > > > > -----Original Message----- > > > From: i2rs [mailto:[email protected]] On Behalf Of Alexander > > > Clemm > > > (alex) > > > Sent: Monday, October 19, 2015 3:05 PM > > > To: Martin Bjorklund > > > 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) > > > > > > 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. > > > --- 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]; j.schoenwaelder@jacobs- > > > university.de; [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 > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
