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

[Robert Wilton]

On 16/01/2016 08:53, Ladislav Lhotka wrote:

Kent Watsen  writes:

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?

Gert> too many negations in this phrase to answer with a simple yes or no
:-). I am in favour of deferring

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).

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

Hi Rob,

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

Robert Wilton  writes:

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

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.

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

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

>
>
>
> 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
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

Kent Watsen  writes:
>
>>>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?
>>Gert> too many negations in this phrase to answer with a simple yes or no
>>:-). I am in favour of deferring
>
> 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

>
>
>
>>>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.
>>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
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Fri, Jan 15, 2016 at 06:21:47PM +, Robert Wilton wrote:
> 
> 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.

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Gert Grammel]

Rob,

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

Gert

On 2016-15-01 19:21, "netmod on behalf of Robert Wilton"
 wrote:

>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?
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)).
 

>
>
>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.
Gert> indeed a valid scenario
>
>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?
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)). 
>
>
>
>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?
Gert> too many negations in this phrase to answer with a simple yes or no
:-). I am in favour of deferring
>
>
>
>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.
Gert> also here I am in favour of deferring
>

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

[Kent Watsen]

Please see inline below.

Kent // as a contributor







On 1/15/16, 3:36 PM, "netmod on behalf of Gert Grammel" 
 wrote:

>Rob,
>
>Thank you for the effort, it¹s really useful.
>
>Gert
>
>On 2016-15-01 19:21, "netmod on behalf of Robert Wilton"
> wrote:
>
>>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?
>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)).

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



>>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.
>Gert> indeed a valid scenario

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


>>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?
>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)).

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



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