"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
