Kent // as a contributor
From: Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>>
Date: Saturday, October 3, 2015 at 11:38 AM
To: Robert Wilton <rwil...@cisco.com <mailto:rwil...@cisco.com>>
Cc: Randy Presuhn <randy_pres...@mindspring.com
<mailto:randy_pres...@mindspring.com>>, "netmod@ietf.org
<mailto:netmod@ietf.org>" <netmod@ietf.org <mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully
synchronized" in "Requirement 1.D"
Hi,
So the applied leaf is being used as a complicated boolean?
IMO your draft (using attributes similar to
with-defaults=report-all-tagged,
not containers) is the best compromise because:
- the data models are not touched
- no datastores are required
- the same string is used to identify the data node no matter what
state needs to be checked
- client has to request the metadata somehow so no impact
on clients that do not care about this issue
- a single boolean attribute applied="true" is all that is really
needed
Andy
On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
Hi Andy,
It was clarified by Rob Shakir in the meeting that the applied-cfg
leaf is only used to indicate whether the configuration
represented by the intended-cfg leaf has been applied.
But it appears that my proposed text for 1D may have caused some
confusion. Please see inline ...
On 02/10/2015 19:11, Andy Bierman wrote:
Hi,
What about the data models that do not follow 1D?
- templates: the intended data model and applied data model are
disjoint
This came up towards the end of the interim, and my understanding
is that it acceptable for any templating solution to have to
adhere to that constraint above.
- 'auto-duplex' corner-case: the intended and applied leaf are
the same, but they
will never have the same value
The intention is:
- intended-cfg duplex leaf = "auto" (i.e. operator wants duplex
to be determined by auto-negotiation)
- applied-cfg duplex leaf = "auto" (i.e. device will determine
duplex by auto-negotiation)
- related derived-state duplex-state leaf = "full" or "half" or
"unknown" (always represents the actual duplex setting of the
interface)
- 'use-dhcp' corner-case: intended config just enables specific
derived state
to be used; disjoint data models
Similarly:
- intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP
assigned IP addresses)
- applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP
to assign IP addresses)
- related derived-state IP address leaf = A.B.C.D (Primary IP
address in use for the interface - if any).
Somebody asked an important question at the interim:
Is the intent of this group to limit all YANG data models such that
they conform to 1D? (IMO that is a non-starter)
It is not my intention that my proposed 1D text makes are
constraint on the structure of YANG data models.
IMO requirement 1D presume that the solution involves separate
objects in the YANG data model for intended and applied states,
and therefore it is an invalid requirement.
That is not the intention of my phrasing, perhaps it needs further
refinement?
The intention is that a config node has two notional states in the
data store, intended and applied. The aim is to tightly relate
those two notional states as to when they are allowed to be the
same or different.
Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
I don't think that this requirement excludes any of the three
solutions that have been proposed (or the use of attribute to
return intended vs applied state metadata).
Thanks,
Rob
Andy
On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason)
<jason.ste...@alcatel-lucent.com
<mailto:jason.ste...@alcatel-lucent.com>> wrote:
I agree with "e.g." rather than "i.e.". I'm sure there are
lots of other examples of situations where intended config
and applied config don't match when we consider the variety
of systems out there that may use NETCONF/YANG. We should
include some of these examples in the draft (in some
informational section and have a reference/pointer to them
just after the definition).
Note that this updated definition for 1.D does not preclude
the applied config object from matching the intended *before*
it has been applied. Do we need to clarify that with some
"conversely" clause or is that clear enough when considering
the other requirements ?
We should also cleanly define "applied" (and provide
illustrative examples of when something is and is not
applied). Should that be a separate email thread ?
Jason
-----Original Message-----
From: netmod [mailto:netmod-boun...@ietf.org
<mailto:netmod-boun...@ietf.org>] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; netmod@ietf.org <mailto:netmod@ietf.org>
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify
"fully synchronized" in "Requirement 1.D"
Hi Randy,
On 01/10/2015 23:27, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "netmod@ietf.org <mailto:netmod@ietf.org>"
<netmod@ietf.org <mailto:netmod@ietf.org>>
>> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify
"fully synchronized" in "Requirement 1.D"
>>
>> To clarify what I failed to eloquently express in the
interim meeting.
>>
>> I propose changing the text for requirement 1.D. This also
removes
>> the need to define what fully synchronized means.
>>
>>
>> Old text for 1.D
>> D. For asynchronous systems, when fully
synchronized, the data
>> in the applied configuration is the same as
the data in the
>> intended configuration.
>>
>>
>> Proposed text for 1.D:
>> D. When the configuration change for any intended
>> configuration leaf has been successfully
applied to the
>> system (i.e. not failed, nor deferred due to
absent hardware)
>> then the existence and value of the
corresponding applied
>> configuration leaf must match the intended
configuration
>> leaf.
> Are "not failed" and "deferred due to absent hardware" the
> *only* possibilities? If not, then the "i.e." needs to be
replaced
> with an "e.g."
I'm not sure if it is the only possibility. Two other
possible reason might be:
- Configuration that cannot be applied because some
dependent configuration hasn't been applied. (E.g. if you
have configuration where an interface-ref couldn't be
fulfilled because the referenced interface configuration
hadn't been applied because either it had failed or been
deferred due to absent hardware). But perhaps this would be
classified as being one of the two cases above?
- There is also the case the configuration is currently in
the process of being applied.
If it is agreed that github issue #2 (i.e. "Is there a
requirement to indicate why intended config != applied cfg?")
is a valid requirement, and I think that there might have
been some support for this in the interim meeting yesterday,
then I would hope that the final solution would enumerate the
reasons why the applied configuration may not match the
intended configuration.
As such, changing from i.e. to e.g. seems like a good choice.
So also taking into account Martin's suggestion the updated
proposed text for 1.D would be:
D. When the configuration change for any intended
configuration node has been successfully applied
to the
system (e.g. not failed, nor deferred due to
absent hardware)
then the existence and value of the corresponding
applied
configuration node must match the intended
configuration
node.
Thanks,
Rob
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
> .
>
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
