Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics

From: Randy Presuhn <[email-masked]>
Date: Thu, 2 Apr 2015 11:02:56 -0700 (GMT-07:00)

Hi -

I think what they're really asking for is an automated way
to identify the bits and pieces that correspond to a particular
aspect of a managed thingie.  This has already happened with
"config true".  Module structure is a really lousy mechanism
for identifying aspects; a given bit of information may
participate in more than one aspect.  So I'm agreeing with
Andy that structure is a lousy tool for the job.

However, the job is an important one.  Structure is not the
solution.  Look for another tool.

Randy

-----Original Message-----
>From: Andy Bierman <[email-masked]>
>Sent: Apr 2, 2015 10:49 AM
>To: Anees Shaikh <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] New 6087bis issues - connect config - state -	statistics
>
>On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <[email-masked]> wrote:
>> We've laid out why this is a problem (even for existing RFC models) in
>> draft-openconfig-netmod-opstate-00 and summarized during the presentation in
>> Dallas.  The problem is exacerbated when trying to compose multiple models
>> into a coherent whole -- clearly it's not possible to manage a service or
>> device with an interfaces model alone.
>>
>> Reading the description statements to learn where different types of data is
>> stored is not a solution IMO -- we need to think how this will be use
>> programmatically by users.  And we made the deliberate tradeoff to introduce
>> some extra work in building a consistent model for the benefit of a simple
>> programming construct to set and retrieve the data.
>>
>
>I disagree.
>Many times the relationship between a config knob setting
>and operational state is not simple.  There may be all kinds of
>overlap and dynamic conditions that change the set of
>interesting objects at the moment.  Forcing a certain structure
>between config and operational nodes will not work as a general solution.
>You should develop some YANG extensions if you think the
>problem can be solved without description-stmts.
>
>
>
>
>> thanks.
>> -- Anees
>
>Andy
>
>>
>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <[email-masked]> wrote:
>>>
>>> Hi,
>>>
>>> You need to read the description-stmts of the relevant data nodes
>>> to find out where other related data nodes can be found.
>>> IMO the sibling config/state approach should only
>>> be used if the state can exist without the config.
>>>
>>> If I have an ACL or some filter that may be nested within lists
>>> with lots of keys, then it is extremely wasteful to replicate
>>> all the scaffolding and keys, just to store a couple counters
>>> for that ACL.  It is much better to just put the counters in the ACL
>>> entry.
>>>
>>> But many times the set of interesting objects related to some
>>> config is far more complicated than that, so the description-stmt
>>> is the only place to document this information.
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel
>>> <[email-masked]> wrote:
>>> > Hello,
>>> > As indicated by operators in Dallas and as experienced by Ericsson as
>>> > well,
>>> > it is sometimes not easy to find the status data for a given bit of
>>> > configuration (interface, route, etc.). Often the state and
>>> > configuration
>>> > are handled in parallel subtrees with the same structure. However this
>>> > is
>>> > not part of the guidelines. Also counters are often separated from state
>>> > data again without a clear guideline to connect statistics with the
>>> > config.
>>> > I believe 6087 should provide guidelines how to find state and staistics
>>> > information for a give piece of configuration. E.g. how do find the
>>> > number
>>> > of outgoing packets for an interface?
>>> > regards Balazs
>>> >
>>> > On 2015-04-02 14:47, Martin Bjorklund wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Here's a list of some things that maybe should be added to 6087bis.
>>> >> Some of them are stylistic; I don't know if we should add those or
>>> >> not.
>>> >>
>>> >>
>>> >>
>>> >> 3.6  References
>>> >>
>>> >>    The RFC Editor prefers the style:
>>> >>
>>> >>      reference
>>> >>        "RFC <NNNN>: <title>";
>>> >>
>>> >>      reference
>>> >>        "RFC <NNNN>: <very long title that spans
>>> >>          more than one line>";
>>> >>
>>> >>
>>> >>    I think we should document this.
>>> >>
>>> >>
>>> >> 4.1
>>> >>
>>> >>   Update this wrt. example modules.  Should they be marked with CODE at
>>> >>   all?
>>> >>
>>> >>
>>> >> 5.1.  Module Naming Conventions
>>> >>
>>> >>
>>> >>    Add: IETF modules SHOULD (MUST?) start with "ietf-".
>>> >>
>>> >>    Example modules SHOULD start with "example-" or "ex-".
>>> >>
>>> >>
>>> >> 5.2.  Identifiers
>>> >>
>>> >>    Add: avoid unnecessary prefixes on names.
>>> >>
>>> >>    BAD:
>>> >>
>>> >>      list interface {
>>> >>        ...
>>> >>        leaf interface-name { ... }
>>> >>        leaf interface-type { ... }
>>> >>      }
>>> >>
>>> >>    GOOD:
>>> >>
>>> >>      list interface {
>>> >>        ...
>>> >>        leaf name { ... }
>>> >>        leaf type { ... }
>>> >>      }
>>> >>
>>> >>
>>> >>    use-hypened-names
>>> >>
>>> >>
>>> >>
>>> >> 5.8  Namespace Assignments
>>> >>
>>> >>    OLD:
>>> >>
>>> >>     The following examples of non-Standards-Track modules are only
>>> >>     suggestions.  There are no guidelines for this type of URN in this
>>> >>     document:
>>> >>
>>> >>         http://example.com/ns/example-interfaces
>>> >>
>>> >>         http://example.com/ns/example-system
>>> >>
>>> >>    NEW:
>>> >>
>>> >>     There are no guidelines for non-Standards-Track modules.
>>> >>
>>> >>     Example modules SHOULD use RFC 6963 style URNs:
>>> >>
>>> >>      urn:example:<module-name>
>>> >>
>>> >>     Or 2606-style
>>> >>
>>> >>      http://example.com/...
>>> >>
>>> >>
>>> >>
>>> >> /martin
>>> >>
>>> >> _______________________________________________
>>> >> netmod mailing list
>>> >> [email-masked]
>>> >> https://www.ietf.org/mailman/listinfo/netmod
>>> >>
>>> >>
>>> >
>>> > --
>>> > Balazs Lengyel                       Ericsson Hungary Ltd.
>>> > Senior Specialist
>>> > ECN: 831 7320
>>> > Mobile: +36-70-330-7909              email: [email-masked]
>>> >
>>> > _______________________________________________
>>> > netmod mailing list
>>> > [email-masked]
>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 2 Apr 2015 12:00:53 -0700

I'm not sure what identifying aspects mean -- I'm talking about the problem
of finding corresponding data in a model (and more importantly, a composed
model) in a consistent way.  It doesn't solve the issue of semantics
relationship of config and state knobs (except for the convention on
intended vs. actual config that we explain in the document).  And it's not
that we need an automated way, we need a schema that lends itself to a
simple programming model / convention  (maybe you meant the same thing).

"Config true" doesn't help with this , it only labels a piece of data as rw
or ro.  And neither does anunstructured text description embedded in the
schema document.  The alternative is to maintain an external mapping for
every data item (since the locations in the schema can be arbitrary when
putting models together).  This was not pursued because it doesn't scale
and is not easy to maintain.

(Juergen, in section 2.5 we are not talking about devices that support
different models -- we are talking about a device for which multiple models
are needed to fully manage all aspects -- again, I can't turn up a device
with just an interfaces model.  sorry if it wasn't clear from the example).

thanks.
-- Anees

On Thu, Apr 2, 2015 at 11:02 AM, Randy Presuhn <[email-masked]
> wrote:

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 3 Apr 2015 10:26:18 +0200

Hello,
I think the problem is real, needs solving, so just some ideas:
- put state, statistics and config in the same container/list, but 
enhance Netconf/restconf to be able to <get> just config, just state, 
just counters or some combinations of all this. As I remember the main 
reason to put state and config in separate branches was the need to be 
able to read them separately. At that time I tought it a mistake that we 
use module structure instead of extending netconf. As Andy stated: 
"structure is a lousy tool". Still in RFC6087bis we have:
"The separation of configuration data and operational state SHOULD be
    considered carefully.  It is often useful to define separate top-
    level containers for configuration and non-configuration data."
This uses the structure as a tool. :-)

or
- a new YANG statement that links together two lists indicating that one 
is the config part while the other is the state
regards Balazs

P.S. IETF was always asking for operator input. Now we got it, will we 
do something about it?

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Apr 2015 02:14:42 -0700

On Fri, Apr 3, 2015 at 1:26 AM, Balazs Lengyel
<[email-masked]> wrote:
> - put state, statistics and config in the same container/list, but enhance
> Netconf/restconf to be able to <get> just config, just state, just counters
> or some combinations of all this. As I remember the main reason to put state
> and config in separate branches was the need to be able to read them
> separately. At that time I tought it a mistake that we use module structure
> instead of extending netconf. As Andy stated: "structure is a lousy tool".
> Still in RFC6087bis we have:

RESTCONF already has the 'content' query parameter that allows
config, operational, or both.  This is good enough.
It is trivial for you to add your own content filters to
the RPC operations (if you want to prove that standards
for more classifications are needed)

Andy

> or
> - a new YANG statement that links together two lists indicating that one is
> the config part while the other is the state

Prove this works as an extension first.
IMO it is easy to come up with simplistic solutions for
trivial test-cases.  Create a general solution first,
prove that it helps, then ask the IETF to standardize it.

Andy

>
> P.S. IETF was always asking for operator input. Now we got it, will we do
> something about it?
>

---

From: Rob Shakir <[email-masked]>
Date: Fri, 3 Apr 2015 15:53:36 -0700

Andy,

Your arguments here are too abstract for me — sorry. I struggle to understand really what you are proposing as an alternative approach.

Let’s talk about a specific example (which I appreciate that you might think is overly simplistic — but my requirement here is to have usable models that we can interact with, not just YANG models for the sake of YANG models) — configuring a BGP peer in a network where there are multiple configuration writers. If I want to perform the operation of:

* Configure a new peer on a network element.
* Determine whether the configuration that is active in the system is the one that I wrote (rather than another system’s intention).
* Retrieve operational counters that correspond to the peer.

Primarily, I push some configuration to neighbor[peer-address=172.0.2.1]/config/{peer-as,description}  —  I can immediately get the actual active configuration by pulling the corresponding ‘state’ container. Since I have duplicates that tell me the ‘active’ configuration as well as what was pushed, then I know whether my config that I tried to apply was the one that was accepted, rather than another writer’s.

Indeed, I can write a generic method that does this verification given a certain path (always check that the ‘state’ container next to the ‘config’ one matches) - so I don’t need to have any kind of mapping that says /device/routing-protocols/bgp/state/neighbor… is the corresponding place for state for a neighbour configured at /device/routing-protocols/bgp/config/neighbor…. for each leaf [Note: the problem with splits “higher in the tree” like this is that it is not clear where the state container starts — is it at routing-protocols/state or bgp/state?]

I then want to check that the peer came up - and get any counters related to it - I can do this by just pulling the ‘operational: true’ parameters from the state container - which lets me make a targeted query for the thing that I am actually interested in - and only receive the data that the actual network element has derived - rather than duplicating things on the wire.

This is quite a typical workflow where we need to be able to easily relate intended state (config), active state (running configuration parameters), and derived state to one another to verify a change on the network.

The proposal that is in draft-openconfig-netmod-opstate-00, seems to me to be relatively simple solution that fits requirements quite neatly — and as of yet, I don’t think we have found a case where it does not work. Multiple folks are starting to write code to interact with these models - so this will be a good test of whether it works as we expect.

I don’t see the need for a mapping dictionary between config and state nodes - and find the idea that the mapping is included in human-readable prose somewhat bizarre, when we are talking about programmatic interaction.

Can you outline a case where you don’t think that the approach works please? I’d really love to see some alternative proposals - since we had a lot of discussion on this topic over the last few months with a bunch of different folks - and if we’ve missed some better way of doing this, or some flaw in our approach, then I’d be keen to iterate it!

r.

On 3 April 2015 at 02:14:58, Andy Bierman ([email-masked]) wrote:

Andy  

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Apr 2015 16:28:51 -0700

On Fri, Apr 3, 2015 at 3:53 PM, Rob Shakir <[email-masked]> wrote:
> Andy,
>
> Your arguments here are too abstract for me — sorry. I struggle to
> understand really what you are proposing as an alternative approach.
>
> Let’s talk about a specific example (which I appreciate that you might think
> is overly simplistic — but my requirement here is to have usable models that
> we can interact with, not just YANG models for the sake of YANG models) —
> configuring a BGP peer in a network where there are multiple configuration
> writers. If I want to perform the operation of:
>
> * Determine whether the configuration that is active in the system is the
> one that I wrote (rather than another system’s intention).
> Primarily, I push some configuration to
> neighbor[peer-address=172.0.2.1]/config/{peer-as,description}  —  I can
> immediately get the actual active configuration by pulling the corresponding
> ‘state’ container. Since I have duplicates that tell me the ‘active’
> configuration as well as what was pushed, then I know whether my config that
> I tried to apply was the one that was accepted, rather than another
> writer’s.
>
> Indeed, I can write a generic method that does this verification given a
> certain path (always check that the ‘state’ container next to the ‘config’
> one matches) - so I don’t need to have any kind of mapping that says
> /device/routing-protocols/bgp/state/neighbor… is the corresponding place for
> state for a neighbour configured at
> /device/routing-protocols/bgp/config/neighbor…. for each leaf [Note: the
> problem with splits “higher in the tree” like this is that it is not clear
> where the state container starts — is it at routing-protocols/state or
> bgp/state?]
>
> I then want to check that the peer came up - and get any counters related to
> it - I can do this by just pulling the ‘operational: true’ parameters from
> the state container - which lets me make a targeted query for the thing that
> I am actually interested in - and only receive the data that the actual
> network element has derived - rather than duplicating things on the wire.
>
> This is quite a typical workflow where we need to be able to easily relate
> intended state (config), active state (running configuration parameters),
> and derived state to one another to verify a change on the network.
>
> The proposal that is in draft-openconfig-netmod-opstate-00, seems to me to
> be relatively simple solution that fits requirements quite neatly — and as
> of yet, I don’t think we have found a case where it does not work. Multiple
> folks are starting to write code to interact with these models - so this
> will be a good test of whether it works as we expect.
>
> I don’t see the need for a mapping dictionary between config and state nodes
> - and find the idea that the mapping is included in human-readable prose
> somewhat bizarre, when we are talking about programmatic interaction.
>
> Can you outline a case where you don’t think that the approach works please?
> I’d really love to see some alternative proposals - since we had a lot of
> discussion on this topic over the last few months with a bunch of different
> folks - and if we’ve missed some better way of doing this, or some flaw in
> our approach, then I’d be keen to iterate it!
>

I do not see any interesting solutions in your draft.
I am strongly opposed to allowing config=true child nodes
of config=false data nodes.  This is too complicated to implement.

Each data model designer can decide how to split up
config and state in a way that makes the most sense for
that data model. There is no rigid formula that will work all the time.

The argument that the operator or designer must understand each data model
they use to fully utilize it is not very compelling.  Yes -- that's right.
Generic tools will only do so much, and to really use a YANG module,
even the description-stmts must be read.

If you have specific changes to the routing modules to organize
them better then that's fine, but I do not see any general solution
in the draft that should be followed.

Andy

---

From: Anees Shaikh <[email-masked]>
Date: Fri, 3 Apr 2015 18:17:05 -0700

<snip>

> of config=false data nodes.  This is too complicated to implement.

Since we don't actually do this in our solution (though we mentioned it in
the draft as a way to further simplify the structure), I'm wondering if
you've looked at the draft at all to understand the problem.   Rob also
just laid out a detailed example of the problem.

> that data model. There is no rigid formula that will work all the time.

Please be specific about situations in which this proposal does not work --
we are honestly interested to understand the limitations.  If I understand
you correctly, your proposal is to let modelers create arbitrary
constructions of configuration and operational state and let the users of
the models just figure it out.

> even the description-stmts must be read.

That's not the argument at all -- obviously the API of any system (in this
case, the model) has to be understood to be used, including reading the
documentation of each API call (description-stmts).  Rather, the argument
here is that making the API much easier to use and useful in more
situations, is worthwhile even if it makes the initial implementation of
the backend slightly more difficult.

thanks.
-- Anees

> enhance
> do
> >>>>> into a coherent whole -- clearly it's not possible to manage a
> service
> >>>>> or

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Apr 2015 18:39:12 -0700

On Fri, Apr 3, 2015 at 6:17 PM, Anees Shaikh <[email-masked]> wrote:
> you've looked at the draft at all to understand the problem.   Rob also just
> laid out a detailed example of the problem.
>
>>
>>

It's hard to find specific solutions in your draft.
You do mention config inside operational data as part of the solution.
Your example shows the interfaces table re-done so the operational state
inside the config.  The the config is repeated inside the operational state.

The interfaces-state container was designed that way so system-known
interfaces could be populated in the operational state, even if these
interfaces were not configured by the operator.

Moving the state inside the config breaks this design because
the server would have to populate the configured interfaces
in order to create any child nodes.

Sometimes operational state inside config is
the right choice -- sometimes it isn't.
Sometimes the operational value can be different
than the configured value, but usually not, so
replicating the config as operational state is not
usually required.

I don't think YANG modules should have any extra complexity or cruft
just so they all look kind of the same.  If the extra containers and
duplicated config are needed for a given data model, then fine.
That is something domain experts need to decide for each YANG module.

Andy

> situations, is worthwhile even if it makes the initial implementation of the
> backend slightly more difficult.
>
> thanks.
> -- Anees
>
>
>>
>> > r.
>>
>> Andy
>>
>>
>> >

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 04 Apr 2015 11:46:29 +0200 (CEST)

Hi,

I have three problems with your proposal (as described in
draft-openconfig-netmod-opstate-00)

1.  Duplication of config schema

  In order to support "asynchronous" management systems, you rely on a
  convention that leads to duplication of all config data nodes.  I
  think this is error prone (what happens if some model doesn't follow
  this convention?) and unnecessarily results in big and complex data
  models.

  Another solution would be to introduce a new "datastore" and a new
  RPC operation: <get-intended-config>, which would use the same
  config true schema as the normal config, but return whatever your
  solution with the duplicated nodes would return.

  This solution works regardless of conventions, keeps the data model
  small and focused, and would be optional to implement, so that a
  server that is "synchronous" would not have to implement this.

  Also, I do not understand the term "intended config" for the data
  that copied into the operational state.  I would think that the
  intended config is what the operator wanted, i.e., the config part
  of the schema.

2.  config true nodes under config false nodes.

  As Andy pointed out, this is not legal in YANG.  It is unclear what
  it would mean.  What happens with the config that is there if the
  state node disappears?

3.  The convention of having a node called "config" (in the config...)
  in order to correlate the config to state.  As has been said by
  others already, this is probably a bit too simplistic.  (and again
  error prone b/c it is just a convention) The relation between the
  configuration and how it impacts the operational state can be much
  more complex than this.  For example, all state that is affected by
  disabling an interface might not be visible under the interface's
  "state" container.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 4 Apr 2015 07:50:27 -0700

Hi,

https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00

Your draft expired in 2013 but I think we should take another look
and solve this problem in the protocols, not the data models.

As an analogy, why don't we replicate the startup config in the data model?
It is possible for the next-reboot value to be different than the
configured value, just like the operational value can be different
than the configured value.

But we never do that because there is a conceptual 'startup' datastore
to retrieve that information.  We need a conceptual 'operational'
datastore, so replicated config in the data model can be avoided.

Andy

---

From: Anees Shaikh <[email-masked]>
Date: Mon, 6 Apr 2015 02:24:29 -0700

>   this convention?) and unnecessarily results in big and complex data

this convention is actually very easy to check in a model, e.g. could be
made part of YANG compilation.  As we said in our presentation, there is
some additional complexity in writing the model, but the tradeoff is that
it makes using it much easier (and I don't think it is that difficult to
grok the model, look at the -jstree output).

>   server that is "synchronous" would not have to implement this.

possibly this could work, but there will be issues if one is not using
NETCONF as I mentioned in the earlier response to Andy's mail.  I hope the
answer is not that I can't use YANG for modeling config and state data
unless I am using NETCONF.   But as we discussed at the Dallas meeting, we
can think through datastore solutions in parallel.

For a server that is synchronous we proposed to tag the non-config related
operational data in the model to distinguish it from the duplicated config
nodes.  This makes it optional for a user to get that data if it's
redundant (and a server may choose not to support those nodes in the model).

>   intended config is what the operator wanted, i.e., the config part

yes, this could be clearer -- the duplicate data is perhaps better called
actual config, but it's there to check against the intended config.

>   it would mean.  What happens with the config that is there if the

Our proposal does not violate YANG rules -- config (config: true) and state
(config: false) containers live only under config: true nodes.  We would
perhaps like to do things a bit more simply, but are working within the
constraints of what we have in YANG.

I assume you mean, for example,  if a linecard is removed, the
corresponding interface state would disappear?  The config for those
interfaces should also be deleted in that case.

>   disabling an interface might not be visible under the interface's

As I mentioned earlier, I don't entirely agree this convention has to be
error prone, it's simple to check.  And when doing something like disabling
an interface, certainly state in several paths in the model might be
affected (e.g., under the Ethernet portion, the aggregate portion, the VLAN
portion, etc.). If I need to see the change in those parts of the interface
state, I'd need to query those paths.

thanks.
-- Anees

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Apr 2015 20:10:34 +0200 (CEST)

Anees Shaikh <[email-masked]> wrote:
> made part of YANG compilation.

Agreed, but that is not the point.  The problem is that perfectly
legal YANG modules (that don't follow the convention) cannot be used
in systems that need the convention.

> As we said in our presentation, there is

I don't you should view these datastores as being just of NETCONF.
They could certainly be exposed over RESTCONF as well (and other
protocols).

> redundant (and a server may choose not to support those nodes in the model).

Then they should be marked with an if-feature.  But I still do not
prefer this solution...

> (config: false) containers live only under config: true nodes.

Ok!

> We would

This would be an example of the server changing the user-specified
configuration depening on operational events.  I would strongly
recommend against this.  Also, it cannot be implemented on a system
that faithfully implement NETCONF with its "lock" operation.  (If user
A has a lock on the config, noone is allowed to modifiy the config).

> error prone, it's simple to check.

See above - yes I agree it is easy to check.  That's not the point.
The problem is again that some perfectly legal YANG models cannot be used.

> And when doing something like disabling

So why is it problematic to query /interfaces-state/interface if you
want to check the operational state of an interface?

/martin

---

From: Rob Shakir <[email-masked]>
Date: Tue, 7 Apr 2015 12:07:31 +0100

Hi Martin,

> in systems that need the convention.

This is not true — any system can support whichever subset of modules it would like. If there is demand for the set that is supported to have common conventions, then it is likely that these can be supported *alongside* any other modules that are required. 

From the consumer’s perspective - which I think is not being taken into account here — I would very much like to have some common conventions, rather than work out the different way that each model has decided to do things. Having to do this just moves the dimension in which we have diversity from being based on the vendor today, to being based on the model tomorrow. Either way, it’s diversity that adds complexity with zero benefit to consuming systems.

> They could certainly be exposed over RESTCONF as well (and other

But *are* they being defined for these protocols? If the answer is no, then we can hardly rely on something that does not exist - when we can make a solution using today’s YANG work!

r.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 07 Apr 2015 13:11:13 +0200

> and solve this problem in the protocols, not the data models.

I'd support that. In fact, the only part of the YANG language that's
really NETCONF-specific is the "config" statement.

> than the configured value.

The essential assumption is that "startup" has the same schema as
"running". This needn't be the case for non-NETCONF management
protocols.

> datastore, so replicated config in the data model can be avoided.

I would go even farther: the operational datastore should be of primary
interest for data modelling because it is where all semantic constraints
really matter, and also because it would be (I assume) common for all
management protocols.

It should then be a task for each management protocol (including
NETCONF) to specify the workflow for accessing and modifying the
operational datastore. This may also include schemas for
protocol-specific datastore(s), if they are needed.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Apr 2015 13:34:23 +0200 (CEST)

Rob Shakir <[email-masked]> wrote:
> This is not true — any system can support whichever subset of modules
> it would like. If there is demand for the set that is supported to
> have common conventions, then it is likely that these can be supported
> *alongside* any other modules that are required.
> 
> From the consumer’s perspective - which I think is not being taken
> into account here — I would very much like to have some common
> conventions, rather than work out the different way that each model
> has decided to do things.

When you rely on conventions, different modules may have different
conventions.  Thus, consumers have to adapt to all different
conventions present in the systems they want to manage.  Compare this
with having a separate datastore for "actual config".  With such a
datastore, the consumer can get the intended and actual config in
exactly the same way across implementations, for all data models.

Why is this idea not taking the consumer's perspective into account?

> Having to do this just moves the dimension
> in which we have diversity from being based on the vendor today, to
> being based on the model tomorrow. Either way, it’s diversity that
> adds complexity with zero benefit to consuming systems.
> 
>  
> But *are* they being defined for these protocols?

If we decide that a new datastore is the way forward, then I expect
this to be defined in such a way that it works for both NETCONF and
RESTCONF.

/martin

---

From: Rob Shakir <[email-masked]>
Date: Tue, 7 Apr 2015 12:52:14 +0100

> Why is this idea not taking the consumer's perspective into account?

I think it is — and actually, it was the one that I originally favoured. :-)

If you look at https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxvcGVuY29uZmlnbmV0fGd4OjQ5ZjdlMmY4YmQxYWZhNTI [0] slide 5, then we even documented this as one of the preferred two solutions that we had. Essentially, the logical split (to me) is:

a) outside of the path — which is what you are proposing with datastores. we can then always just check the datastore in question to find intended vs. actual vs. state.
b) at the very end of the path — which is the proposal that is being made in draft-openconfig-netmod-opstate

The problems we noted with this approach were:

1. To the audience reviewing it (and conversations with experts, including yourself, I believe) the concept of datastores was very tightly coupled with NETCONF. It seemed that the lack of inclusion of datastore support (as far as I read) in RESTCONF indicated that even within the IETF net{conf,mod}-defined protocols, we cannot rely on support for datastores in the protocol.

2. Some approach allowing the augmentation of a model within an individual datastore would be required. This seems very similar to the operational: true flag, that we proposed. However, if such an extension is not supported by a device then we do not have the advantage that we can still get all of the different leaves (actual/intended/state) since they are duplicated.

I understand that we are not making pretty YANG (and hey, I did a refactor of the BGP YANG model to support this approach, so I understand the modeller’s pain) - but quite frankly, we *HAVE* to prioritise actually meeting the requirements that we abstracted this to. [1]

Cheers,
r.

[0]: Apologies for the unwieldy Google Docs link, I uploaded the PDF at http://www.openconfig.net/file-cabinet/Modelling-Operational-State.pdf?attredirects=0&d=1.

[1]: Of course, I cannot claim that these requirements are complete *for all operators*, but amongst the folks that talked about this - we thought that these were a reasonable set of requirements. Indeed, we iterated them quite a lot based on feedback.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Apr 2015 09:17:14 -0700

> 1. To the audience reviewing it (and conversations with experts, including yourself, I believe) the concept of datastores was very tightly coupled with NETCONF. It seemed that the lack of inclusion…

This is wrong.  Datastores are not tightly coupled to NETCONF.
RESTCONF works with NETCONF without being a clone of NETCONF.
You cannot rely on RESTCONF because it is still an I-D.
This process argument is the weakest of all.

> 2. Some approach allowing the augmentation of a model within an individual datastore would be required. This seems very similar to the operational: true flag, that we proposed. However, if such an…

Why is this needed?
Your approach of duplicating the config tree under itself as operational data
does not support this approach.  Duplicating data is expensive.
IMO too expensive for the small amount of value it provides.

There are 3 main concerns I have with replicating config as operational state

1) makes modules much harder to read.  I do not agree that modules will be
easier to use, once they are much harder to read.

2) there is an assumption that all config can be over-ridden by operational
state,  Even in the minority of cases where this is true,  just knowing the
different value is not enough.  Is it OK that the config and operational
values differ?  How did the operational value become different?  Is this
a temporary issue?  What config knobs would change the operational value?
None of these questions are answered by merely replicating config as state.

3) The YANG constraints are not designed to be relocated from config to state.
All of the YANG constraints still apply when moved, only they apply to
the config=false version, which may or may not be correct.

IMO, the only tool being abused here is cut-and-paste YANG.
An operational datastore or protocol operations to retrieve
the operational values of config=true nodes would not have these problems.

Andy

---

From: Rob Shakir <[email-masked]>
Date: Tue, 7 Apr 2015 18:57:14 +0100

Hi Andy,

> This process argument is the weakest of all.

This isn’t a process argument - and I will freely admit that I am not an expert in what the RESTCONF spec might say (although I did my best to study it). The key point here is whether we can expect _all protocols_ via which we might want to interact with the data model that we are expressing to support data stores. Some of the operators that were involved in the conversation suggested that their requirements for these protocols may include non-IETF defined technologies in the future.

I am not religious about either approach - and I agree with you that duplication can be expensive. One of the reasons that we asked for an 'operational: true’ flag is to allow a hook for an RPC that can cut down the expense of data retrieval where we have systems that we expect that the config/X and state/X leaves are always identical (although we continue to discuss cases where even systems we expect to be synchronous may not be able to guarantee this). [0]

It feels rather like, right now, I am being told that the current proposal we put forward is wrong, but also not being offered another solution that meets the requirements. We did reach out to Martin to discuss his (expired) draft [1] back in December - he counselled us that the approach did not seem usable to him.

I encourage you to do what we tried to - and document the alternative proposal in a draft - and ideally test it against real use-cases - so that the working group can objectively compare it to that in draft-openconfig-netmod-opstate-00. I am not sure we’re going to get much further in this email thread.

r.

[0]: With such an RPC hook, then in NETCONF, we could do <get-config> which will get us the config/X leaves, and <get-operational> which will get only the state/Y leaves that do not have a corresponding config leaf.
[1]: https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Apr 2015 11:27:06 -0700

> I encourage you to do what we tried to - and document the alternative proposal in a draft - and ideally test it against real use-cases - so that the working group can objectively compare it to that…

This is not a new problem.
Sometimes we have "admin-state" and "oper-state" objects when we know they
are needed.  There have been proposals to fix NETCONF to properly support
operational state. So far, the NETCONF WG has not decided the problem
is worth solving.  Maybe your input will change that decision.

The ietf-interfaces module was intentionally designed with separate interfaces
and interfaces-state.  Your example solution places the operational state
of each interface under the config for the interface.  This specific solution
was rejected by the NETMOD WG.  I am not saying that the WG is right,
but republishing RFC 7223 would require a lot of work, revisiting that decision.

IMO, without any sort of meta-data to indicate who/what/when/how the
operational state is different than the configured value, the operator cannot
do very much other than discover a configured leaf is not the same
as the operational leaf.

Duplicating the YANG duplicates all the YANG constraints.
I have not seen any real modules where the configuration constraints
were intended to be enforced in config=false subtrees.
YANG does not automatically relocate must-expressions,
or allow the operator to decide which config=false constraints
to ignore.  IMO this problem is harder to solve than just adding
a <get-operational> command to the protocol(s).

Andy

---

From: Paul Doolan <[email-masked]>
Date: Tue, 7 Apr 2015 16:20:50 -0400

Hello Andy,

forgive me for picking one line in this complex discussion but I'm 
having a hard time reconciling this statement:

On 4/7/15 12:17 PM, Andy Bierman wrote:
> Datastores are not tightly coupled to NETCONF.

With what I find in RFC6241:

To account for these issues, the NETCONF protocol recognizes the
    difference between configuration data and state data and provides
    operations for each.  The <get-config> operation retrieves
    configuration data only, while the <get> operation retrieves
    configuration and state data.

Did you mispeak? Am I taking something out of context? Or am I making a 
mistake equating data with data-store?

thanks,
pd

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Apr 2015 13:35:46 -0700

On Tue, Apr 7, 2015 at 1:20 PM, Paul Doolan <[email-masked]> wrote:
> Hello Andy,
>
> forgive me for picking one line in this complex discussion but I'm having a
> hard time reconciling this statement:
>

A new protocol like RESTCONF can define how NETCONF datastores
work in that protocol. I2RS can do the same and even add a new
ephemeral datastore.  I know RFCs written before RESTCONF and I2RS
were chartered only mention NETCONF, just as YANG 1.0
only mentions NETCONF.

What is your concern exactly?
NETCONF and RESTCONF do not limit the operations via YANG rpc-stmt
that can be defined.  Adding a new protocol operation does not require
a new protocol version.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Apr 2015 13:47:48 -0700

On Tue, Apr 7, 2015 at 1:43 PM, Paul Doolan <[email-masked]> wrote:
> To ascertain whether the statement "Datastores are not tightly coupled to
> NETCONF"  is true or not.
>
> I did offer the option that I may have taken your remark out of context and
> it appears from your response that I did i.e you were focussed on RESTCONF.
> I note however that you refer to "NETCONF datastores". So, again, I slightly
> confused, but going to assume that NETCONF and it's datastores are
> (somewhat) tightly coupled.
>

There have been multiple drafts that proposed new NETCONF operations.
RFC 6241 defines how <get> and <get-config> behave, but a new
operation can be added in a new RFC with different behavior.

Andy

>
> On 4/7/15 4:35 PM, Andy Bierman wrote:
>>

---

From: Paul Doolan <[email-masked]>
Date: Tue, 7 Apr 2015 16:43:22 -0400

>What is your concern exactly?

To ascertain whether the statement "Datastores are not tightly coupled 
to NETCONF"  is true or not.

I did offer the option that I may have taken your remark out of context 
and it appears from your response that I did i.e you were focussed on 
RESTCONF. I note however that you refer to "NETCONF datastores". So, 
again, I slightly confused, but going to assume that NETCONF and it's 
datastores are (somewhat) tightly coupled.

thanks,
pd

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 08 Apr 2015 11:04:52 +0200

> This is wrong.  Datastores are not tightly coupled to NETCONF.

I think they are, and not only due to the particular wording in RFC
6020. For instance, it is IMO incorrect to interpret config true/false
simply as RW/RO. Sec. 7.19.1 in RFC 6020 makes it very clear that
"config true" nodes are part of NETCONF configuration datastores.
This in turn implies certain semantics, e.g. that the data can be
locked, and RFC 6241 is also very clear about locking semantics:

    Additionally, the system will ensure that these locked configuration
    resources will not be modified by other non-NETCONF management
    operations such as SNMP and CLI.

> None of these questions are answered by merely replicating config as

Such questions are hard to answer because RFC 6241 is rather vague about
the semantics of NETCONF datastores and their interaction with the rest
of the system. I think the basic assumption was that the contents of
running are what's used operationally. Perhaps this can be guaranteed on
closed systems where all software is controlled by a single vendor - the
user then isn't given access to the underlying operating system, and all
configuration interfaces (CLI, SNMP) are built on top of the NETCONF
datastores.

However, on more open systems this assumption doesn't work. A trivial
example: consider a server or router based on Linux/*BSD that uses
NETCONF and implements the ietf-system module. Anytime, an admin can log
in and use the "hostname" command so that the hostname that's actually
used differs from the value in sys:hostname. That change is for sure
ephemeral but is it also temporary - i.e., is something expected to
happen before reboot? In fact, NETCONF clients are even unable to learn
about the change because sys:hostname has no counterpart in state data.

> the config=false version, which may or may not be correct.

But it is the operational state where the constraints really matter.

> the operational values of config=true nodes would not have these

I think a very good model for the operational datastore is the /proc
filesystem.

But we still have the problem that config data needn't always exactly
mirror the state.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Apr 2015 09:15:00 +0200 (CEST)

Hi,

Rob Shakir <[email-masked]> wrote:
> It feels rather like, right now, I am being told that the current
> proposal we put forward is wrong, but also not being offered another
> solution that meets the requirements.

It is easier to shoot down a proposed to solution to the P vs NP
problem than providing a correct solution ;-)

> We did reach out to Martin to
> discuss his (expired) draft [1] back in December - he counselled us
> that the approach did not seem usable to him.

Correct.  Specifically, the idea was that in order to avoid data model
duplication, where more or less every config knob had a corresponding
state knob, we could introduce an operational data store with the same
schema as the config data stores (+ more).  This doesn't seem usable
b/c:

  1. There is often not a 1-1 relationship between config and state
     nodes.

  2. The value space is sometimes not the same in config and
     state (e.g., "duplex" which could be {auto,half,full} in config vs
     {half,full} in state; or "state" which could be {up,down} in
     config vs {up,testing,error,down,...} in state.)

  3. The semantics of the nodes are different, leading to description
     statements on the form:  "In config, this node means..., but in
     state it means ...".

Your proposed solution with explicitly duplicating all config nodes
as config false nodes has the same problems, and in addition it has
some problems of its own, e.g., the relocation problem that Andy
mentioned, where leafrefs don't point to the correct leaf, and the
lifecycle problem (where non-configured nodes do nto show up in
state).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 9 Apr 2015 11:00:53 +0200

> On 09 Apr 2015, at 09:15, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

Yes, although maybe there was one thing that we got right in that draft, and that still seems to me as a reasonable starting point:

   The operational state datastore consists of all parameters that
   provide information about the instantaneous state of the device and
   immediately influence the device's behavior.

   The configuration datastore can be thought of as a blueprint for the
   operational datastore.

The first definition IMO sufficiently discriminates state data from statistics, although one could also argue that a device may change its behaviour based on traffic statistics. Anyway, this distinction is not that important.

The second definition could perhaps use “instructions” instead of “blueprint”, thus emphasizing the fact that configuration needn’t always have the same structure and content as state data. 

This view of state versus configuration also opens the possibility of having alternative management protocols, each with its own schema and scope of configuration instructions.

>     state it means …".

Agreed, and the moral of the story is that state and configuration are related but still distinct entities.

One of the reasons why we failed was IMO that we didn’t dare to move away from the configuration-centric data modelling where almost all relevant semantic constraints are specified for configuration data.

In my opinion, application of a new configuration could proceed in the following steps:

1. Configuration is tentatively applied to the current operational state.

2. The new state is completely validated.

3. If all constraints are met, the new state is (atomically) installed in the device.

In order to be able to use a data model in #2, semantic constraints, default values etc. need to be specified for state data.

This doesn’t prevent validation of configuration(s) but that is really a separate action.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Apr 2015 11:54:19 +0200

> One of the reasons why we failed was IMO that we didn’t dare to move away from the configuration-centric data modelling where almost all relevant semantic constraints are specified for configuratio…

I disagree with the notion that we 'failed'. I believe it is a feature
that we validate configuration data and that we resisted to try to
validate operational state (which changes dynamically).

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 9 Apr 2015 12:23:18 +0200

> On 09 Apr 2015, at 11:54, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Of course I was only talking about draft-bjorklund-netmod-operational-00.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Apr 2015 09:24:47 -0700

> validate operational state (which changes dynamically).

I also do not understand the comment that we have "configuration-centric"
data modeling.  NETCONF was chartered to work on a Network
Configuration Protocol, so not surprising that it focuses on configuration.

It is not a defect or failure that new functionality related to
ephemeral config or correlation of config to operational state
would require new data modeling and/or protocol features.

Failure would be if the leadership did not understand that the
protocols, the YANG language, and the data models need to
evolve together.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Apr 2015 10:37:21 +0200

> Configuration Protocol, so not surprising that it focuses on

Validity of a configuration may depend on things that are external to it
- such a configuration in itself can satisfy all constraints of a data
model but still be in conflict with the current state of the device, and
has to be rejected.

This becomes really important when there are mechanisms that modify the
state but don't sync the changes with NETCONF configuration
datastores. Maybe this is not everybody's problem but I do work with
devices where this possibility has to be addressed.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Apr 2015 12:33:34 +0200

> devices where this possibility has to be addressed.

Yes, operational state can differ from config state. I think we
understand that pretty well since the IAB workshop. There is nothing
new here (except that perhaps some people describe this same idea now
with different terms).

Your idea of extending validity of configuration as we have it today
to validity of configuration with regard to operational state (which
is changing dynamically and also impacted by device and implementation
constraints) scares me a lot. The ultimate arbitrator is the device
and it is an illusion to believe they will all handle all possible
conflict situations in the same way.

We may be able to control this process for ephemeral datastores as
they are newly designed (so we can design in rules and priorities) but
everything beyond that scares me.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Apr 2015 13:25:56 +0200

> On 10 Apr 2015, at 12:33, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Does RFC 6241 really discriminate between running config and state?

   o  running configuration datastore: A configuration datastore holding
      the complete configuration currently active on the device.

What does “currently active” mean? If a parameter changes in running, does it mean that it becomes the value that’s used operationally? Immediately or eventually? If such a state parameter is changed through other means, will the (different) value in running override it, and if so, when?

> conflict situations in the same way.

I am not saying an upfront validation can catch everything, run-time errors certainly cannot be avoided. On the other hand, I do claim that some validity errors could be discovered if state is also taken into account. Since we allow system-controlled list entries that may exist only in *-state lists, some properties such as “unique” leafs need to be satisfied in the state version of the list.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Apr 2015 13:44:49 +0200

> What does “currently active” mean? If a parameter changes in running, does it mean that it becomes the value that’s used operationally? Immediately or eventually? If such a state parameter is chang…

I recommend reading RFC 6244 Section 4.3.2.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Apr 2015 13:59:12 +0200

> On 10 Apr 2015, at 13:44, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Maybe I can’t properly read between the lines but I don’t see an answer to ANY of my questions there.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Apr 2015 14:24:15 +0200

> Maybe I can’t properly read between the lines but I don’t see an answer to ANY of my questions there.

config = configuration data (as in RFC 6244 Section 4.3.2)

config != current operational state (as in RFC 6244 Section 4.3.2)

running config = configuration data currently used

startup config = configuration data used at next startup

=> running config != current operational state

The device implementation arbitrates and decides. Config is passed to
the device at certain events (e.g., when the config is loaded or a
change committed or the device or a function of it restarted). From
the perspective of the internal code, config is one of the many
sources of information that tells it how to behave. Control protocols
inject additional information, the device learns additional
information, the device has limitations and policies that tell it how
to arbitrate the information.

NETCONF validates configuration data in configuration datastores. And
going beyond that is IMHO not feasible nor helpful. What matters
operationally is what the device actually does. This is represented by
the operational state. What a device actually does might not be valid
(due to bugs, resource limitations, hardware changes, broken control
protocols, bad karma, whatever). Network management systems have to
check whether device behavior do matches the expectations. This check
is essential and can't be replaced by validation.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Apr 2015 08:20:09 -0700

> is essential and can't be replaced by validation.

+1

Validation of the configuration MUST NOT include the operational state.
The config represents the desired state of operator controlled settings.
There may be lots of ways for the system to behave in response
to the config contents.  Some operational state will never mirror
the config (e.g., duplex=auto).  Some operational state will reflect
higher priority ephemeral config (from I2RS).  Some operational
state will reflect problems in the network preventing the operator's
settings from being used.

Proper network management protocol mechanisms are needed
to understand the current operational state of a device.
The I2RS pub/sub work might be the right hammer for this nail.
The problem is not the YANG config-stmt, or the lack of 'config'
containers.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Apr 2015 18:41:19 +0200

> On 10 Apr 2015, at 17:20, Andy Bierman <[email-masked]> wrote:
> 

Even if ephemeral config is declared as having higher priority, it can still happen that its combination with “normal” config is invalid. For example, running defines some RIBs, ephemeral defines other RIBs, each datastore satisfies all data model constraints but the joint list of RIBs may be invalid. That’s why I think it is the combined effect of all “desired states” and other contributions to the operational state that have to be considered.

> The problem is not the YANG config-stmt, or the lack of 'config'

You also proposed the operational state datastore. What properties should it have?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Apr 2015 09:56:51 -0700

> Even if ephemeral config is declared as having higher priority, it can still happen that its combination with “normal” config is invalid. For example, running defines some RIBs, ephemeral defines o…

This sounds like a bug in the vaporware.

The persistent configuration is self-contained.
The ephemeral config does not exist when the device boots.
It may never get added to the device (e.g., controller is missing).
The validation of I2RS config as it is added to the device
needs to be handled correctly.

> You also proposed the operational state datastore. What properties should it have?

No I did not propose an operational datastore.
I agree with Martin that mirroring the config data is
mostly pointless.  Protocol operations would work better.

I hope whatever properties the I2RS WG agrees on can
be implemented efficiently.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Apr 2015 19:38:51 +0200

On Fri, Apr 10, 2015 at 06:41:19PM +0200, Ladislav Lhotka wrote:
> 
> Even if ephemeral config is declared as having higher priority, it
> can still happen that its combination with “normal” config is
> invalid. For example, running defines some RIBs, ephemeral defines
> other RIBs, each datastore satisfies all data model constraints but
> the joint list of RIBs may be invalid. That’s why I think it is the
> combined effect of all “desired states” and other contributions to
> the operational state that have to be considered.
>

Yes. The device itself is the final arbitrator. In many cases, it will
know how to resolve conflicts - and this will be implementation
dependent or even specific to the different pieces of hardware plugged
into a device, in some (hopefully rare) cases the device might simply
die and reboot.

> You also proposed the operational state datastore. What properties

Operational state is defined in RFC 6244 section 4.3.2. Section 4.3.3
of the same RFC discusses how to deal with operational state from a
NETCONF perspective. What we are doing so far is what is described in
Section 4.3.3.1. And we noted that config and state data models or
often different in the details. The most important point I think is
that the operational state model must report what the device is
actually doing. If it does something wired, then this wiredness should
show up in the operational state. In other words, saying operational
state is invalid (from the device perspective) is not meaningful - if
the state is there, it should be reported. Operational state is the
ultimate ground truth. (And as a consequence, you should have few
constraints on the operational state part of the data model.)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Apr 2015 20:04:38 +0200

> On 10 Apr 2015, at 19:38, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Sure, but I was talking about validating *tentative* operational state. If it’s broken, then it cannot be installed as “real” operational state. So it boils down to considering what would happen if certain changes are applied. This problem cannot be fully assessed just by looking into the desired state submitted by a single management protocol. Yes, the device is the final arbiter and some errors can only be checked at runtime, but I still think at least a part of business rules for device operation could be expressed in a data model and discovered without going through trial and error.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Apr 2015 20:29:19 +0200

> Sure, but I was talking about validating *tentative* operational state. If it’s broken, then it cannot be installed as “real” operational state. So it boils down to considering what would happen if…

I have no clue what *tentative* operational state is. I believe trying
to validate anything that involves operational state is a bad idea. I
guess I am done here since I am just repeating myself.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Apr 2015 21:05:59 +0200

> guess I am done here since I am just repeating myself.

OK, here's an example:

{
  "ietf-interfaces:interfaces-state": {
    "interface": [
      {
        "name": "eth0",
        "type": "iana-if-type:ethernetCsmacd",
        "ietf:ip": {
          "ipv4" : {
            "address": {
              "ip": "192.0.2.1",
              "prefix-length": 24,
              ...
            }
          }
        },
        ...
      },
      {
        "name": "eth1",
        "type": "iana-if-type:ethernetCsmacd",
        ...
      }
    ]
  }
}

No interface configuration present, which means that
the address 192.0.2.1 was assigned e.g. via DHCP.

Now if a client creates an "interface" entry that tries to configure
address 192.0.2.1/24 on eth1 (such a configuration is valid). The tentative
operational state than is:

{
  "ietf-interfaces:interfaces-state": {
    "interface": [
      {
        "name": "eth0",
        "type": "iana-if-type:ethernetCsmacd",
        "ietf:ip": {
          "ipv4" : {
            "address": {
              "ip": "192.0.2.1",
              "prefix-length": 24,
              ...
            }
          }
        },
        ...
      },
      {
        "name": "eth1",
        "type": "iana-if-type:ethernetCsmacd",
        "ietf:ip": {
          "ipv4" : {
            "address": {
              "ip": "192.0.2.1",
              "prefix-length": 24,
              ...
            }
          }
        },
        ...
      }
    ]
  }
}

The duplicate address can then be immediately discovered and the
configuration rejected, if the data model had a corresponding must
statement on *state data*.

Lada