Subject: [netmod] Summary of "applied configuration and system-controlled entries" discussions

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Jan 2016 18:21:47 +0000

Hi,

Over the last week or so there has been quite a lot of discussion and 
longs threads regarding applied configuration and system-controlled entries.

To try and bring that thread to an explicit conclusion I have tried to 
summarize (at least from my POV) where I think these discussions have 
reached, hopefully get feedback from others, and make any updates to the 
requirement draft that may be required.

I think that there were broadly three different threads to the discussions:

1) Lada requested that the requirement text in requirement 1D be 
loosened so that the applied configuration schema doesn't have to be a 
subset of the intended configuration schema.  The aim of the loosening 
of this text is to allow system-controlled entities (such as interfaces 
that always exist) to be put in the applied configuration.

Personally, I'm opposed to this change, since the relationship between 
intended and applied was explicitly discussed and it was confirmed that 
the schema for the two was expected to be the same so that they can be 
easily compared.

Is there any other support for loosening the requirement text as per 
Lada's suggestion?

However, there is still a related corner case that hasn't been raised 
yet, but may be useful to consider, which is where a systems default 
setting differs from the one defined in an associated YANG module.

To take an example, a YANG module for LLDP might use a global 
P-container to indicate whether the LLDP protocol is enabled on the 
device.  However, for a particular vendors device, the default behaviour 
for LLDP may be that is enabled globally.

If a operator is configuring the device via YANG and pushes down their 
initial config (using a config replace semantics to replace the entire 
existing configuration of the device), and the config that is pushed 
down doesn't include the P-container to explicitly enable LLDP then I 
think the expectation is that the device should disable LLDP when 
processing the config request (even though it the device's default).  
Further, all the time that the device doesn't match the implicit 
intended p-container node state (of non-existence), it should report an 
applied p-container node to indicate that LLDP is actually enabled on 
the device even though the intended behaviour is that it be disabled.

In essence I'm saying that the intended configuration includes all 
explicit data nodes, any default node values in scope, and also any 
nodes in scope that have an implicit schema default value of 
non-existence (i.e. the feature is not enabled).

Do others agree with my interpretation of intended configuration for 
this scenario?

2) Separately, there has been a suggestion from Lada (also supported by 
Gert?) such that the applied configuration always explicitly reports 
default values (e.g. like the report-all option in RFC 6243).

I generally support this suggestion because I think it solves the 
problem that a server can't indicate a difference between a leaf not 
being configured at all and leaf that is configured with the default 
value.  However, I would see it that the YANG schema for both intended 
and applied configuration is still the same, and hence I don't see any 
direct need to modify the requirements draft.  I think that all three 
proposed solutions are able to support this, and hence this issue can 
probably be deferred until a general solution approach has been agreed.

Is anyone against deferring this discussion until a general solution 
approach has been agreed?

3) Finally, there has been some proposals on the exact semantics of how 
the config handling should work, but this has been agreed to be deferred 
until the basis for a solution has been chosen.

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jan 2016 19:55:43 +0100

On Fri, Jan 15, 2016 at 06:21:47PM +0000, Robert Wilton wrote:
> value.

You may want to read about the 'explicit' mode defined in RFC 6243.

/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: Gert Grammel <[email-masked]>
Date: Fri, 15 Jan 2016 20:36:38 +0000

Rob,

Thank you for the effort, it¹s really useful.

Gert

>Is there any other support for loosening the requirement text as per
Gert> (1) In my response to Lada, I expressed the view the text in 1D
allowed the use case he had in mind. In his case there is no intended
config pushed to the server, hence there is no "corresponding applied
configuration². That said I don¹t see the need to change the wording but
would argue that Lada¹s use case is covered by the current text (see also
(2)).

>for LLDP may be that is enabled globally.
Gert> indeed a valid scenario
>Do others agree with my interpretation of intended configuration for
Gert> (2) Perhaps we should to distinguish the modelling aspect from the
usage aspect:
-modeling: Whatever the model contains as applied state should also
modelled as intended state and should also include default values (guess
this is in line with your understanding)
-usage: A client may not make full use of intended configuration for a
given server and could rely upon default values in the applied config. In
that case the intended config (in use) covers a subset of the applied
config (see (1)). 
>approach has been agreed?
Gert> too many negations in this phrase to answer with a simple yes or no
:-). I am in favour of deferring
>until the basis for a solution has been chosen.
Gert> also here I am in favour of deferring
>
>Rob
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Kent Watsen <[email-masked]>
Date: Fri, 15 Jan 2016 22:56:57 +0000

Please see inline below.

Kent // as a contributor

>would argue that Lada¹s use case is covered by the current text (see also

Kent> Agreed, so let’s conclude this issue as DEAD.

>Gert> indeed a valid scenario

Kent> Seems like a bug either in the module or the vendor’s implementation of the module.

>that case the intended config (in use) covers a subset of the applied

I’m not convince this needs to solved (see above)

>:-). I am in favour of deferring

As Juergen points out, the with-defaults covers this.

>Gert> also here I am in favour of deferring

Agreed.

The net-net as I (editor) see it, is that no change to the requirements draft is expected to reflect any of the above.

Thanks again,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 16 Jan 2016 09:28:33 +0100

Hi Rob,

thanks for the summary, I think it is really useful. Comments inline.

> Is there any other support for loosening the requirement text as per 

As Gert writes in his reply, 1D seems to cover the case where applied
config contains stuff that's not present in intended. That's why I
didn't propose any change.

> Do others agree with my interpretation of intended configuration for 

Yes, I think this is a relevant scenario. Yet another variation is that
the vendor might want to turn LLDP via that P-container right away after
an interface card has been plugged in. Then applied config is IMO the
right place where the P-container should appear, but then the
system-controlled interface has to be there in the first place.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 16 Jan 2016 09:53:48 +0100

> As Juergen points out, the with-defaults covers this.

The with-defaults capability is quite complex, mainly because devices
deal with defaults in different ways. I think the intended-applied combo
could remove most of this complexity and provide a nice model for the
semantics of defaults: essentially, applied would work in report-all
mode, and intended in explicit mode. So the convenience of suppressed
defaults would be retained in intended configuration, but at the same
time the operator would be able to get all parameter values the device
is using from applied configuration.

Moreover, this could also cover vendor- or device-specific defaults that
are not specified in the data model (and currently can be learnt only
from documentation).

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 16 Jan 2016 10:15:47 +0100

> is using from applied configuration.

Some implementations do not remember whether a default value was
explicitely set not and this makes it hard to implement explicit mode
everywhere. I do not think this implementation constraint changes by
introducing applied.

With RFC 6243, the client has control, why is hardcoding the behaviour
instead an improvement? For example, if I want to diff intended and
applied, I prefer to have control over the defaults.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 16 Jan 2016 10:34:41 +0100

> On 16 Jan 2016, at 10:15, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Right. I still think that some devices will not implement applied configuration, so this wouldn't send with-defaults into oblivion.

> applied, I prefer to have control over the defaults.

An application producing such a diff could easily filter out the defaults. Control over defaults is IMO important if the operator has to choose between readability of the configuration and ability to learn the values in use. Here we would have both, so why the extra complexity?

Lada

---

From: Robert Wilton <[email-masked]>
Date: Sun, 17 Jan 2016 22:04:43 +0000

> are not specified in the data model (and currently can be learnt only
Yes, I like what is being proposed by Lada.

It would be interesting to get an operators view on this.

I.e. given a choice of the applied data would they prefer:
(i) for it to be concise but have ambiguous values (default netconf 
semantics),
(ii) explicitly correct but a bit more verbose (but surely the data node 
set would be much smaller than derived state) (as proposed above).
(iii) flexible (e.g. by using something like the with-defaults extension)

Rob