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

[Gert Grammel]

+1
Gert 

Sent from my Apple ][

> On 19 Oct 2015, at 18:10, Kent Watsen  wrote:
> 
> 
> 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
> 
> 
> 
>> On 10/14/15, 2:08 PM, "Kent Watsen"  wrote:
>> 
>> 
>> 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"  wrote:
>>> 
>>> 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)
>>> 
>>>   D.  For asynchronous systems, when fully synchronized, the data
>>>   in the applied configuration is the same as the data in the
>>>   intended configuration.
>>> 
>>> 
>>> 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
>>> 
>>> 
 On 06/10/2015 21:54, Juergen Schoenwaelder wrote:
> On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
>> On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
>>> On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
>>> 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.
>> 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"?
>> 
>>> 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.
>> 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 

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

[Kent Watsen]

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"  wrote:

>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)
>
>D.  For asynchronous systems, when fully synchronized, the data
>in the applied configuration is the same as the data in the
>intended configuration.
>
>
>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
>
>
>On 06/10/2015 21:54, Juergen Schoenwaelder wrote:
>> On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:
>>> Hi Juergen,
>>>
>>> On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
 On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
> 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.
 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"?

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

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

[Robert Wilton]

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)

   D.  For asynchronous systems, when fully synchronized, the data
   in the applied configuration is the same as the data in the
   intended configuration.


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


On 06/10/2015 21:54, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:

Hi Juergen,

On 06/10/2015 17:01, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:

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.

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


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.

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.

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 

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

[Robert Wilton]

Hi Juergen,

On 06/10/2015 17:01, Juergen Schoenwaelder wrote:

On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:

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.

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


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.

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



/js



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

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

[Juergen Schoenwaelder]

On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
> On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
> >On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
> >>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.
> >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"?
> >
> >>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.
> >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.

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

-- 
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] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

[Robert Wilton]

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

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

[Kent Watsen]

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?

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

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

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

[Robert Wilton]

On 01/10/2015 20:14, Martin Bjorklund wrote:

Robert Wilton  wrote:

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.

I think this text is better.  I suggest s/leaf/node/ in order to cover
also lists, leaf-lists, and p-containers.
Agreed.  I had originally written it using node but changed it to leaf 
to because of the the text for 1.C:


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


Thanks,
Rob







/martin
.



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

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

[Andy Bierman]

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) <
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] On Behalf Of Robert Wilton
> Sent: Friday, October 02, 2015 5:24
> To: Randy Presuhn; 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>
> >> Sent: Oct 1, 2015 10:01 AM
> >> To: "netmod@ietf.org" <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, chan

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

[Sterne, Jason (Jason)]

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] On Behalf Of Robert Wilton
Sent: Friday, October 02, 2015 5:24
To: Randy Presuhn; 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>
>> Sent: Oct 1, 2015 10:01 AM
>> To: "netmod@ietf.org" <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
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

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

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

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

[Sterne, Jason (Jason)]

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:a...@yumaworks.com]
Sent: Friday, October 02, 2015 14:11
To: Sterne, Jason (Jason)
Cc: Robert Wilton; Randy Presuhn; netmod@ietf.org
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully 
synchronized" in "Requirement 1.D"

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

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

[Randy Presuhn]

Hi -

>From: Robert Wilton <rwil...@cisco.com>
>Sent: Oct 1, 2015 10:01 AM
>To: "netmod@ietf.org" <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."

Randy

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