Hi Kent,
On 06/10/2015 01:40, Kent Watsen wrote:
This issue appears to have become more like issue #5 – should we mark
this one a duplicate of the other?
I suggest that we can just finalize on the text being discussed to
replace 1.D and then resolve issue #1.
Jason had proposed this text:
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 applied
equivalent of the node (whether that be a corresponding node in the data
model, an attribute associated with the intended config node, the
configuration node read from a different datastore or context, etc) must
match the intended configuration node.
Or perhaps this slightly briefer alternative is better?:
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, possibly
notional, applied configuration node must match the intended
configuration node.
As for this, what does it mean?
> > - 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.
Specifically, would this imply that the flattening of the template
would have to now take place at each operational component in the
system – as opposed to being flattened by a centralized component
(e.g., in the control plane). If so, then I think it might add
significant costs to the servers, as then *all* downstream components
would have to know how to flatten templates.
Not necessarily. I see this as meaning that YANG templates should be
solved as a separate YANG extension/draft.
draft-ietf-l3sm-l3vpn-service-model uses a concept of adhoc templating.
It would be good if templating could be handled in a consistent, and
ideally generic way.
In terms of the opstate requirements I think that it would probably
require that for any solution:
- if the template itself was expressed as configuration then the
template itself would have both intended and corresponding applied
configuration nodes.
- any expanded template written to the configuration space would have
both intended configuration and applied configuration nodes.
I think that there are possible solutions to how templating could work
with a centralized configuration component if the configuration
component is able to send the expanded template to the downstream
components without writing the expanded template to the configuration
datastore. Such an solution (possibly modelled on the with-defaults
extension) would also potentially be able to provide separate views of
the configuration data that shows both the compressed and expanded views
of the configuration data.
Related to this, how do we handle the case where the downstream
component's native data model is different. For instance, imagine a
mixed IP/optical router that has subtended ROADM and optical
amplifiers attached. So, when the control plane sends the config to
the ROADM, it first converts it to the ROADM's native data model. For
this case, in order to present the applied config with the same data
model, would the control plane have to perform the reverse mapping?
Yes, I think so.
Or, if the server knows what is in the config update that is being sent
to the ROADM, then it could track the status of config update, and then
mark the associated configuration nodes as being applied when the ROADM
has indicated that it has fully completed the config request.
Rob
Kent // as a contributor
From: Andy Bierman <[email protected] <mailto:[email protected]>>
Date: Saturday, October 3, 2015 at 11:38 AM
To: Robert Wilton <[email protected] <mailto:[email protected]>>
Cc: Randy Presuhn <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected] <mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>> 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)
<[email protected]
<mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; [email protected] <mailto:[email protected]>
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 <[email protected]
<mailto:[email protected]>>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>
>> 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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
> .
>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
