Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

From: Randy Presuhn <[email-masked]>
Date: Thu, 1 Oct 2015 15:27:35 -0700 (GMT-07:00)

Hi -

>From: Robert Wilton <[email-masked]>
>Sent: Oct 1, 2015 10:01 AM
>To: "[email-masked]" <[email-masked]>
>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."

Randy

---

From: Robert Wilton <[email-masked]>
Date: Fri, 2 Oct 2015 10:24:17 +0100

Hi Randy,

> *only* possibilities?  If not, then the "i.e." needs to be
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-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Fri, 2 Oct 2015 17:44:23 +0000

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-masked]] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; [email-masked]
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:
>> 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
> *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.

So also taking into account Martin's suggestion the updated proposed text for 1.D would be:

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Oct 2015 11:11:20 -0700

Hi,

What about the data models that do not follow 1D?

  - templates: the intended data model and applied data model are disjoint
  - 'auto-duplex' corner-case: the intended and applied leaf are the same,
but they
    will never have the same value
  - 'use-dhcp' corner-case: intended config just enables specific derived
state
     to be used; disjoint data models

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)

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.

Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.

Andy

On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <
[email-masked]> 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
>
>
> 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?
> 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.
>

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Fri, 2 Oct 2015 19:37:16 +0000

Good point that the wording does imply separate objects in the YANG data model.  We should try to adjust the wording so that it could apply to other solutions (e.g. attributes, different datastore, etc).   Perhaps the following ?

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.

Templates:  Perhaps templates (not instances of the template, but the template itself) are always considered as “applied” as soon as they are configured ?

Auto-duplex:  The configured duplex setting and the negotiated resulting operational value are two separate and independent leaves IMO.  The configured duplex setting will have both an intended view and an applied view (which are separate an independent from the negotiated duplex).  E.g. AdminDuplex (intended & applied) and OperDuplex (pure ‘derived’ state).

I’m not familiar with the use-dhcp example.  But maybe as soon as the system is actually “using DHCP” down on the linecards then the applied value would reflect that ?

Re all data models conforming to 1D:  If the solution ends up being in the protocols (instead of the models) then there are no requirements for models.  If the solution ends up being in the models then I don’t think we can mandate that *all* models follow these requirements.  Controllers/clients will have to be able to manage systems that have a mix of “opstate compliant” modules and non compliant modules.  Operators who are keen on these requirements will encourage them to be adopted by as many IETF modules as possible.

Implementation feasibility & impacts is something that we’ll need to consider but for now I’m trying to ignore that and purely clarify what is being requested.

Jason

From: Andy Bierman [mailto:[email-masked]]
Sent: Friday, October 02, 2015 14:11
To: Sterne, Jason (Jason)
Cc: Robert Wilton; Randy Presuhn; [email-masked]
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

Hi,

  - templates: the intended data model and applied data model are disjoint
  - 'auto-duplex' corner-case: the intended and applied leaf are the same, but they
    will never have the same value
  - 'use-dhcp' corner-case: intended config just enables specific derived state
     to be used; disjoint data models

Andy

On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <[email-masked]<mailto:[email-masked]>> 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).

Jason

-----Original Message-----
From: netmod [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>>
>> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Rob

> [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Fri, 2 Oct 2015 13:07:37 -0700

On Fri, Oct 2, 2015 at 12:37 PM, Sterne, Jason (Jason) <
[email-masked]> wrote:

> Good point that the wording does imply separate objects in the YANG data
> model.  We should try to adjust the wording so that it could apply to other
> solutions (e.g. attributes, different datastore, etc).   Perhaps the
> following ?
>
>
>
> 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.
>
>
>
> Templates:  Perhaps templates (not instances of the template, but the
> template itself) are always considered as “applied” as soon as they are
> configured ?
>
>
>
> Auto-duplex:  The configured duplex setting and the negotiated resulting
> operational value are two separate and independent leaves IMO.  The
> configured duplex setting will have both an intended view and an applied
> view (which are separate an independent from the negotiated duplex).  E.g.
> AdminDuplex (intended & applied) and OperDuplex (pure ‘derived’ state).
>
>
>
> I’m not familiar with the use-dhcp example.  But maybe as soon as the
> system is actually “using DHCP” down on the linecards then the applied
> value would reflect that ?
>
>
>

This is really a derivative of the template case.
The data models are different for config=true and config=false.

The config=true knob does not match the operational state at all.
E.g., set a boolean leaf to select DHCP instead of the config=true IP
addresses.
Then use a different data model to read the DHCP Lease info and get the
assigned IP address.
This is similar to the admin-state/oper-state use-case.  Only the
description-stmt
in the admin-state object says "go look at oper-state for the real value".

 Andy

Re all data models conforming to 1D:  If the solution ends up being in the
> protocols (instead of the models) then there are no requirements for
> models.  If the solution ends up being in the models then I don’t think we
> can mandate that **all** models follow these requirements.
> Controllers/clients will have to be able to manage systems that have a mix
> of “opstate compliant” modules and non compliant modules.  Operators who
> are keen on these requirements will encourage them to be adopted by as many
> IETF modules as possible.
>
>
>
> Implementation feasibility & impacts is something that we’ll need to
> consider but for now I’m trying to ignore that and purely clarify what is
> being requested.
>
>
>
> Jason
>
>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Friday, October 02, 2015 14:11
> *To:* Sterne, Jason (Jason)
> *Cc:* Robert Wilton; Randy Presuhn; [email-masked]
> *Subject:* Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully
> synchronized" in "Requirement 1.D"
>
>
>
> Hi,
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 2 Oct 2015 21:16:51 +0100

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

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

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

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

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

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

> 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-masked] 
> <mailto:[email-masked]>> 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
>
>
>     From: netmod [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Robert Wilton
>     To: Randy Presuhn; [email-masked] <mailto:[email-masked]>
>     Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify
>     "fully synchronized" in "Requirement 1.D"
>
>     Hi Randy,
>
>     >> From: Robert Wilton <[email-masked] <mailto:[email-masked]>>
>     >> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     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?
>     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.
>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 3 Oct 2015 08:38:50 -0700

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-masked]> 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
> 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.
>
>
>   - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by
> auto-negotiation)
>   - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned
> IP addresses)
>   - related derived-state IP address leaf = A.B.C.D (Primary IP address in
> use for the interface - if any).
>
>
>
> <[email-masked]>[email-masked]> wrote:
>
>> examples of when something is and is not applied).  Should that be a
>> separate email thread ?
>>
>> Jason
>>
>>
>> >> From: Robert Wilton < <[email-masked]>[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 6 Oct 2015 00:40:05 +0000

This issue appears to have become more like issue #5 – should we mark this one a duplicate of the other?

As for this, what does it mean?

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

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?

Kent   // as a contributor

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Saturday, October 3, 2015 at 11:38 AM
To: Robert Wilton <[email-masked]<mailto:[email-masked]>>
Cc: Randy Presuhn <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

Hi,

Andy

On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton <[email-masked]<mailto:[email-masked]>> 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 ...

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.

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) <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> 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).

Jason

-----Original Message-----
From: netmod [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; [email-masked]<mailto:[email-masked]>
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 <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 6 Oct 2015 10:38:11 +0100

Hi Kent,

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

> that it
> 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-masked] <mailto:[email-masked]>>
> To: Robert Wilton <[email-masked] <mailto:[email-masked]>>
> Cc: Randy Presuhn <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     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.
>
>     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.
>
>
>       - related derived-state IP address leaf = A.B.C.D (Primary IP
>     address in use for the interface - if any).
>
>
>>
>     It is not my intention that my proposed 1D text makes are
>     constraint on the structure of YANG data models.
>
>>
>     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.
>
>>
>     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
>>
>>         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
>>
>>
>>         >> To: "[email-masked] <mailto:[email-masked]>"
>>         <[email-masked] <mailto:[email-masked]>>
>>         >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify
>>         replaced
>>           - 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
>>         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.
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Oct 2015 18:01:38 +0200

> match the intended configuration node.

I have no clue what "an attribute associated with the intended config
node" or "the configuration node read from a different datastore or
context" or "etc". means. What exactly is an "applied equivalent of
the node"?

>             notional, applied configuration node must match the intended

What is the purpose of the phrase "possibly notional"?

/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: Robert Wilton <[email-masked]>
Date: Tue, 6 Oct 2015 21:00:30 +0100

Hi Juergen,

> What is the purpose of the phrase "possibly notional"?
There was a concern that my previous text, i.e. as above but without 
"possibly notional", implied that applied configuration had to be 
actually represented as real data nodes in a YANG schema, which would 
disallow the solutions presented in draft-kwatsen-netmod-opstate-00 and 
draft-wilton-netmod-intf-ext-yang-00.

On balance, my preference is to exclude the "possibly notional" phrase 
if the text is sufficiently clear without it.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Oct 2015 22:54:07 +0200

> if the text is sufficiently clear without it.

My understanding is that draft-kwatsen-netmod-opstate-00 proposes to
represent applied config as nodes in a different datastore, so there
is no need for 'possibly notational'. I do not understand why
draft-wilton-netmod-intf-ext-yang-00 is relevant here. Do you mean
draft-wilton-netmod-opstate-yang-00? I do have major concerns about
this particular proposal since it changes the YANG data encoding
fundamentally. There was another proposal to use attributes, which is
also not without problems but it is likely a bit less painful. But
again, it all depends on the final definition of what applied config
really is. So where is the latest version and how far are we with
agreeing on it?

Yet another way to look at this is to expose not the applied config in
addition to the intended config (I have been told configs can be
really large) but instead expose lets say a yang patch that says how
the applied config differs form the running config. Having to retrieve
two large configs just to diff them locally seems to a potentially
expensive exercise, in particular if the difference is often small.  I
think Randy mentioned something like this before and no there is no
I-D. But even with this approach, the definition without "possibly
notational' would hold; you would just not expose the applied config
entirely but instead a patch that allows to calculate it.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 13 Oct 2015 14:14:59 +0100

In an attempt to try and close on some of the proposed requirement text 
before Thursday's interim meeting.

Does anyone have any outstanding objections on using this proposed text 
for Requirement 1.D, or is it sufficiently clear to update the draft, 
and resolve issue 1?

OLD text for Requirement 1:

    1.  Ability to interact with both intended and applied configuration

        A.  The ability to ask the operational components of a system
            (e.g., line cards) for the configuration that they are
            currently using.  This is the "applied configuration".

        B.  Applied configuration is read-only

        C.  The data model for the applied configuration is the same as
            the data model for the intended configuration (same leaves)

NEW text (as above, changing 1.D only):

    1.  Ability to interact with both intended and applied configuration

        A.  The ability to ask the operational components of a system
            (e.g., line cards) for the configuration that they are
            currently using.  This is the "applied configuration".

        B.  Applied configuration is read-only

        C.  The data model for the applied configuration is the same as
            the data model for the intended configuration (same leaves)

        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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Oct 2015 18:08:48 +0000

The new 1-D works for me.  It is similar in spirit to the proposal I just
sent in the issue #4 thread.

Thanks,
Kent

On 10/13/15, 9:14 AM, "Robert Wilton" <[email-masked]> wrote:

>>>>>> This issue appears to have become more like issue #5  should we
>>>>>>mark
>>>>>> this one a duplicate of the other?

---

From: Kent Watsen <[email-masked]>
Date: Mon, 19 Oct 2015 16:10:43 +0000

All,

This issue somewhat dropped from our radar - we didn't discuss it during
the interim or since.  Nonetheless, my interpretation of the below thread
is that Robert's proposal was accepted.  So I'm going to replace 1.D with
the text below (albeit s/system/server/) and move this issue to the REVIEW
state.

Thanks,
Kent

---

From: Gert Grammel <[email-masked]>
Date: Mon, 19 Oct 2015 16:18:10 +0000

+1
Gert 

Sent from my Apple ][

> On 19 Oct 2015, at 18:10, Kent Watsen <[email-masked]> wrote:
> 
> 
> All,
>