Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Juergen Schoenwaelder]

Comments inline... I generally like the approach of explaining the
situation so that module writers can take an informed decision. I am
struggling a bit with the strong recommendation given and I am not
sure whether using two separate modules for /foo and /foo-state makes
things really simpler.

/js

On Tue, Aug 02, 2016 at 01:10:05AM +, Kent Watsen wrote:
> 
> 
> Following Lou’s recommendation, my proposed changes for rfc6087bis Section 
> 5.23 follow:
> 
> 
> 5.23.  Operational Data
> 
>In YANG, any data that has a "config" statement value of "false"
>could be considered operational data.  The relationship between
>configuration (i.e., "config" statement has a value of "true") and
>operational data can be complex.
> 
> -   One challenge for client developers is determining if the configured
> -   value is being used, which requires the developer to know which
> -   operational data parameters are associated with the particular
> +  One challenge for client applications is determining if a configured
> +  value is being used, which requires the application to know which
> +  operational data parameters are associated with a particular
>configuration object (or group of objects).
> 
>In the simplest use-cases, there is no interaction between
>configuration and operational data.  For example, the arbitrary
>administrative name or sequence number assigned to an access control
>rule.  The configured value is always the value that is being used by
>the system.
> 
>However, some configuration parameters interact with routing and
> -   other signalling protocols, such that the operational value in use by
> +  other signaling protocols, such that the operational value in use by
>the system may not be the same as the configured value.  Other
>parameters specify the desired state, but environmental and other
>factors can cause the actual state to be different.
> 
> -   For example a "temperature" configuration setting only represents the
> +   For example, a "temperature" configuration setting only represents the
>desired temperature.  An operational data parameter is needed that
>reports the actual temperature in order to determine if the cooling
>system is operating correctly.  YANG has no mechanism other than the
>"description" statement to associate the desired temperature and the
>actual temperature.
> 
>   [Editor’s Note: we should define a ‘related-config’ statement ASAP!]
> 
>Careful consideration needs to be given to the location of
>operational data.  It can either be located within the configuration
>subtree for which it applies, or it can be located outside the
>particular configuration subtree.  Placing operational data within
> -   the configuration subtree is appropriate if the operational values
> -   can only exist if the configuration exists.
> +   the configuration subtree is ideal, as the association between the
> +   configuration and operational state is clear.  However, doing so must
> +   be done with the knowledge that NETCONF and RESTCONF can 
> +   currently only return the operational state for configured values,
> +   not system generated values such as system created interfaces or
> +   routing table entries.   This is because the config false nodes are 
> +   descendants of config true nodes and hence cannot be returned
> +   for nodes that haven’t been configured.   At least, this is the case
> +   for how NETCONF and RESTCONF currently support returning
> +   mixed config true and config false content.
> 
> 
> -   The "interfaces" and "interfaces-state" subtrees defined in [RFC7223]
> -   are an example of a complex relationship between configuration and
> -   operational data.  The operational values can include interface
> -   entries that have been discovered or initialized by the system.  An
> -   interface may be in use that has not been configured at all.
> -   Therefore, the operational data for an interface cannot be located
> -   within the configuration for that same interface.
> +   In order to support returning operational state for system generated
> +   values, some YANG module designers have created a parallel top-level
> +   config false hierarchy that mirrors the structure of the config true 
> +   hierarchy.  For instance, this is seen in the ‘interfaces-state’ node in 
> +   [RFC7223].  By doing this, it enables the operational state for system
> +   generated values to be returned, since then all the ancestor nodes are
> +   config false as well.  However, this approach is not ideal as it leads to 
> +   needing to maintain duplicate structures and also requires the use of
> +   description statements to describe the association between the two
> +   structures.
> 
> +   To address this situation, the NETMOD and NETCONF working groups
> +   are at this time in the process of defining a holistic operational state
> +   solution that entails both a revised conceptual 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Rob Shakir]

Balazs,

> On 2 Aug, 2016, at 10:29 AM, Balazs Lengyel  
> wrote:
> I prefer a tight definition so even if we allow both 1) and 2)  we should 
> state that other combinations e.g. trees spliting close to the leaves or a 
> mix of 1) and 2) in the same module are not allowed (VER STRONGLY 
> discouraged). 

What is the motivation for this very strongly discouraged statement? The 
problem I take with this is that you are not only getting zero consistency that 
will let a user determine how a model might look  (painful for those actually 
*using the models* rather than writing them - who are hugely under-represented 
in this discussion), but you’re also throwing out a bunch of models (both 
inside and outside of the IETF) at the same time.

Apologies to pick specifically on this email, but I have still yet to see any 
justification why anything other than a solution that is already being 
implemented is preferable to this WG other than it seeming like the WG doesn’t 
like the aesthetics of the modules in this case.

I am soon going to shut up on this topic, but it’s quite frankly lamentable 
that such a division is being created with no reasonable justification.

Note that the statement that Benoit/Lou/Kent made in Berlin related to applied 
config - the structure that is being objected to can be trivially implemented 
without those leaves if one wanted to.

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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Balazs Lengyel]

  
  
I don't know if we can make them a rule, but IMHO single-rooted
  modules are definitely easier to use. E.g. just as a single
  example: we only need one set of access control rules. Similar
  double handling is needed often.  I don't like foo-state trees.

Balazs


On 2016-07-28 17:00, Robert Wilton
  wrote:


  
  
  
  
  On 27/07/2016 20:44, Acee Lindem
(acee) wrote:
  
  





   From: netmod <netmod-boun...@ietf.org>
on behalf of Mahesh Jethanandani <mjethanand...@gmail.com>
Date: Wednesday, July
27, 2016 at 9:07 PM
To: Xufeng Liu <xufeng.liu.i...@gmail.com>
Cc: netmod WG <netmod@ietf.org>
    Subject: Re: [netmod]
    OpsState Direction Impact on Recommended IETF YANG Model
Structure
  
  
  
  

  
Robert mentions IS-IS, and if I look at OSPF, I see a
clear separation of rw and ro nodes. 

  



Right - and this separation is based on the routing and
  routing-state split in the ietf-routing-cfg model. In general,
  ietf-routing-cfg specifies that all control plane protocol
  YANG models should adapt this structure. Anyone who thinks
  collapsing all the models one config/state tree is simply a
  matter of moving a few counters should taking a better look at
  the existing drafts. I outlined the options in the E-mail
  thread prior to IETF 96.  Now, with the context of IETF 96
  behind us, I believe more NETMOD participants will understand
  the options. To review the options specified in the previous
  E-mail thread. 



  
   1. Do nothing - allow them proceed as they are with
  multiple ways of
       representing the applied configuration. This
  would provide visibility to
       the data independent of whether or not the
  device supported the revised 
       data-stores supporting implicit retrieval of the
  applied configuration.
   2. Prune out the redundant data nodes except those
  required as list
        keys, etc, since they can be obtained from the
  applied state data store.
  3. #2 plus collapse the config (read-write) and
   system-state
       (read-only) into common containers. No more
  branching of
       -config and
  -state at the top level of the model.
  



Prior to IETF 96, I don’t believe we had selected a
  direction. However, I believe we agreed on option #1 in order
  to allow the publication of these models within the next year.
  We’d still be able to avail the benefits of applied vs
  intended configuration on network devices supporting these
  data stores. 

  
  My take is that I think that the leaning at IETF was towards 2.
  
  I.e. I think that we ruled out 1.  I.e. the models must not have
  separate nodes to represent applied configuration because that
  will be solved by the datastore solution.
  
  But it feels a bit inconsistent that the models don't need to have
  explicit leaves for foo vs foo-applied (because it will be solved
  by datastores), but the models do still need explicit leaves for
  foo vs foo-state (even though this could/should also be solved by
  an operational state datastore - noting that both draft-schoenw
  and draft-wilton propose a solution to this problem).
  
  My preference, if we can get quick consensus would be to do 3, or
  if consensus is not possible for 3, then we should fallback to
  doing 2, as the next best option.  But whatever the decision, I
  favour agreeing a direction quickly so that the other WGs know
  what to put in the RFCs.
  
  Thanks,
  Rob
  
  


Thanks,
Acee 







  

  


  

  On Jul 27, 2016, at 11:22 AM, Xufeng
Liu <xufeng.liu.i...@gmail.com>
wrote:
  
  

   The assumption of “I
suspect that all the routing models will be
structured similarly” is not correct. Very
few mo

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Balazs Lengyel]

  
  
Hello,
Later I will try to provide a text proposal as well, but some
  points:

  I prefer a tight definition so even if we allow both 1) and
2)  we should state that other combinations e.g. trees spliting
close to the leaves or a mix of 1) and 2) in the same module are
not allowed (VER STRONGLY discouraged). 
  
  In one of the earlier mails there was a a statement: if we
have foo and foo-state trees, the containers/list/key-leafs
SHOULD be the same in the two. The structures of the two trees
SHOULD not just be si,i;ar, they should be the same.

This way you could look at the root objects of the module and
  immediately know what is the situation.
regards Balazs




On 2016-07-29 18:32, Juergen
  Schoenwaelder wrote:


  On Fri, Jul 29, 2016 at 04:35:05PM +0100, Robert Wilton wrote:
 

  
I would like to know what should the common approach for IETF standard
models be?  E.g. is it one of the following:

1) All config false leaves for foo must go under /foo-state.

  
  
I think if you have /foo-state, then this is a logical consequence. Do
we have any data models that have a /foo-state tree and config false
nodes under the /foo tree?


  
2) All config false leaves for foo must go under /foo

  
  
This apparently does not make sense in certain circumstances until we
have a revised datastore solution defined and implemented that may
allow this to work in all situations.


  
3) All config false leaves go under /foo where possible, or /foo-state
otherwise (e.g. for restconf-monitoring).

  
  
I think it should be fairly easy for a tool to figure out whether a
/foo tree is a pure config true tree or whether there are any config
false leafs as well and /foo is a mixed tree. Things are fairly easy
as long as people split at the root if they split.


  
4) Config false leaves go wherever the model writer decides is appropriate.

  
  
I think we will have to live for a while with both the (i) /foo (pure
config true tree) and /foo-state (pure config false tree) split at the
root approach and the (ii) /foo (mixed config true and false tree)
approach. We need to document the trade-offs between the two so that
module writers can make an informed decision. Whether a module uses
(i) or (ii) should be possible to determine by inspecting the
properties of the schema tree, in particular if module writers follow
the guideline to use consistent names and structure in the /foo and
/foo-state approach wherever possible.

I think we also wanted to strongly discourage models where (iii) the
trees split at the leaves or very close to the leaves.

/js




-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Kent Watsen]

Following Lou’s recommendation, my proposed changes for rfc6087bis Section 5.23 
follow:


5.23.  Operational Data

   In YANG, any data that has a "config" statement value of "false"
   could be considered operational data.  The relationship between
   configuration (i.e., "config" statement has a value of "true") and
   operational data can be complex.

-   One challenge for client developers is determining if the configured
-   value is being used, which requires the developer to know which
-   operational data parameters are associated with the particular
+  One challenge for client applications is determining if a configured
+  value is being used, which requires the application to know which
+  operational data parameters are associated with a particular
   configuration object (or group of objects).

   In the simplest use-cases, there is no interaction between
   configuration and operational data.  For example, the arbitrary
   administrative name or sequence number assigned to an access control
   rule.  The configured value is always the value that is being used by
   the system.

   However, some configuration parameters interact with routing and
-   other signalling protocols, such that the operational value in use by
+  other signaling protocols, such that the operational value in use by
   the system may not be the same as the configured value.  Other
   parameters specify the desired state, but environmental and other
   factors can cause the actual state to be different.

-   For example a "temperature" configuration setting only represents the
+   For example, a "temperature" configuration setting only represents the
   desired temperature.  An operational data parameter is needed that
   reports the actual temperature in order to determine if the cooling
   system is operating correctly.  YANG has no mechanism other than the
   "description" statement to associate the desired temperature and the
   actual temperature.

  [Editor’s Note: we should define a ‘related-config’ statement ASAP!]

   Careful consideration needs to be given to the location of
   operational data.  It can either be located within the configuration
   subtree for which it applies, or it can be located outside the
   particular configuration subtree.  Placing operational data within
-   the configuration subtree is appropriate if the operational values
-   can only exist if the configuration exists.
+   the configuration subtree is ideal, as the association between the
+   configuration and operational state is clear.  However, doing so must
+   be done with the knowledge that NETCONF and RESTCONF can 
+   currently only return the operational state for configured values,
+   not system generated values such as system created interfaces or
+   routing table entries.   This is because the config false nodes are 
+   descendants of config true nodes and hence cannot be returned
+   for nodes that haven’t been configured.   At least, this is the case
+   for how NETCONF and RESTCONF currently support returning
+   mixed config true and config false content.


-   The "interfaces" and "interfaces-state" subtrees defined in [RFC7223]
-   are an example of a complex relationship between configuration and
-   operational data.  The operational values can include interface
-   entries that have been discovered or initialized by the system.  An
-   interface may be in use that has not been configured at all.
-   Therefore, the operational data for an interface cannot be located
-   within the configuration for that same interface.
+   In order to support returning operational state for system generated
+   values, some YANG module designers have created a parallel top-level
+   config false hierarchy that mirrors the structure of the config true 
+   hierarchy.  For instance, this is seen in the ‘interfaces-state’ node in 
+   [RFC7223].  By doing this, it enables the operational state for system
+   generated values to be returned, since then all the ancestor nodes are
+   config false as well.  However, this approach is not ideal as it leads to 
+   needing to maintain duplicate structures and also requires the use of
+   description statements to describe the association between the two
+   structures.

+   To address this situation, the NETMOD and NETCONF working groups
+   are at this time in the process of defining a holistic operational state
+   solution that entails both a revised conceptual datastore model and
+   the necessary protocol extensions to enable, in part, both NETCONF
+   and RESTCONF to be able to return operational state for system
+   generated values using the same config true hierarchy used to return
+   the operational state for configured values.

+   This being the case, it is RECOMMENDED that YANG module designers
+   always mix config true and config false nodes into a single hierarchy.
+   This is so the YANG modules will be in proper form for when the
+   holistic operational state 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Juergen Schoenwaelder]

On Fri, Jul 29, 2016 at 04:35:05PM +0100, Robert Wilton wrote:
 
> I would like to know what should the common approach for IETF standard
> models be?  E.g. is it one of the following:
> 
> 1) All config false leaves for foo must go under /foo-state.

I think if you have /foo-state, then this is a logical consequence. Do
we have any data models that have a /foo-state tree and config false
nodes under the /foo tree?

> 2) All config false leaves for foo must go under /foo

This apparently does not make sense in certain circumstances until we
have a revised datastore solution defined and implemented that may
allow this to work in all situations.

> 3) All config false leaves go under /foo where possible, or /foo-state
> otherwise (e.g. for restconf-monitoring).

I think it should be fairly easy for a tool to figure out whether a
/foo tree is a pure config true tree or whether there are any config
false leafs as well and /foo is a mixed tree. Things are fairly easy
as long as people split at the root if they split.

> 4) Config false leaves go wherever the model writer decides is appropriate.

I think we will have to live for a while with both the (i) /foo (pure
config true tree) and /foo-state (pure config false tree) split at the
root approach and the (ii) /foo (mixed config true and false tree)
approach. We need to document the trade-offs between the two so that
module writers can make an informed decision. Whether a module uses
(i) or (ii) should be possible to determine by inspecting the
properties of the schema tree, in particular if module writers follow
the guideline to use consistent names and structure in the /foo and
/foo-state approach wherever possible.

I think we also wanted to strongly discourage models where (iii) the
trees split at the leaves or very close to the leaves.

/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] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

Hi,

You said "automated code".
Write some YANG extensions for your tools to manually assign
the mapping.  This has already been suggested several times.
This approach can also address N:M mappings.  Supporting 1:1
mappings and ignoring everything else doesn't really help.


Andy


On Fri, Jul 29, 2016 at 8:35 AM, Robert Wilton  wrote:

> Hi Andy,
>
> The main problem that I'm currently trying to solve, and get agreement on,
> is "where does the operator's automated code look to find the state nodes
> associated with a particular config node".
>
> E.g. for feature /foo, do they look for the config false nodes under /foo,
> or do the look somewhere in /foo-state.  The current answer appears to be,
> that the config false nodes could appear in either place in the IETF
> modules without any requirement for a consistent approach.  Is that right?
>
> Separately, the OpenConfig folks have said that it would be better if they
> could get (or register for notification of) all of the data associated with
> "foo" with a single request rather than having to make multiple requests in
> different trees.  Personally, I prefer their model where they have merged
> interface-state into interfaces.  Mainly because I think that it should
> make the YANG modules easier to read with less duplication of structure,
> and I think that it is a better long term direction to go in.  However, I
> appreciate Acee's comments that we may just be too late to change this now,
> and we must just accept the status quo (whatever that is).
>
> I would like to know what should the common approach for IETF standard
> models be?  E.g. is it one of the following:
>
> 1) All config false leaves for foo must go under /foo-state.
> 2) All config false leaves for foo must go under /foo
> 3) All config false leaves go under /foo where possible, or /foo-state
> otherwise (e.g. for restconf-monitoring).
> 4) Config false leaves go wherever the model writer decides is appropriate.
>
> I've put further comments inline below ...
>
>
> On 29/07/2016 15:39, Andy Bierman wrote:
>
> Hi,
>
> I am somewhat confused about this discussion.
> Apparently it is a hyge problem to put foo-counters under
> foo-state?
>
> RW:
> This isn't just about counters, it is all config false nodes that are not
> present solely to represent "applied configuration".
>
>   Configuration must be used (and setup by the operator?)
> in order for foo-counters to exist?
>
> RW:
> No, this is not being proposed.
>
> draft-schoenw and draft-wilton propose that the config true nodes are
> allowed to exist in an "operational state datastore" to parent child config
> false nodes, even though they haven't been configured.  I also proposed
> that metadata annotations could be used to indicate that the containing
> config=true nodes in the operational state datastore exist only in the
> system (and not in the configuration).
>
> Further I would propose that NETCONF/RESTCONF servers could support an
> "operational state datastore" without any requirement to distinguish
> applied configuration separately from intended configuration.
>
>
> So what problem does this solve?
>
> RW:
> I see that it potentially allows modules to avoid an arbitrary foo vs
> foo-state split.
>
>
> The opstate solution proposal requires a config path-expr to be altered
> to generate the corresponding path-expr under the 'state' container.
>
> RW:
> Are you referring to the OpenConfig model solution here or draft-schoenw,
> or draft-wilton?
>
> It does not seem to be a problem that a new path-expr needs to be
> constructed.
> Is that what you are trying to solve? Even though counters never have
> a corresponding configuration node with the same name?
>
>
> So what happens to modules like ietf-restconf-monitoring?
>
> RW:
> Either it stays exactly as it is now, or alternatively it could just be
> named "restconf" rather than "restconf-state", even if it just contains
> config false nodes.
>
> It is no longer allowed to write monitoring modules?
>
> RW:
> It is still allowed to write monitoring modules, no change here.
>
> They all have to contained within some configuration nodes?
>
> RW:
> No, not necessarily:
>  - it they are just state then either call them "foo" or "foo-state" as
> per above.
>  - if they are mix of config and state then they would go under "foo",
> which would be a config true node (but not necessarily configured, as per
> my comments on the operational state datastore above).
>
> Again, what problem is this trying to solve?
>
> RW:
> Hopefully this one has already been answered above.
>
> Thanks,
> Rob
>
>
>
>
> Andy
>
>
> On Fri, Jul 29, 2016 at 7:15 AM, Ladislav Lhotka  wrote:
>
>> Robert Wilton  writes:
>>
>> > On 28/07/2016 15:20, Ladislav Lhotka wrote:
>> >>> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
>> >>>
>> >>> Hi Lada,
>> >>>
>> >>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>> >>> 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Lou Berger]

Picking this message as it is the most recent on this thread - I'd like
to "up level "the discussion.

My read (as chair) on this topic is that in our Berlin meeting, see
discussions related to slide on Section 5.23 of rfc6087bis, we were left
with opinion in the room supporting the current text -- basically saying
that there are different options and that a model writer should make an
informed choice (between a cf-only -state branch and commingling cf and
ct nodes -- basically Rob's #4 below.) 

>From the process standpoint, this was an easy result as it left
unmodified text in a WG document that we hope to LC soon.

>From this thread, and the number of comments being made, it seems that
some would like to change 5.23 and provide more specific/stronger
guidance. 

I'd like to request that those who wish to provide different guidance
than what is currently written (in 
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-07#section-5.23
) please propose text on the list for consideration and discussion.  My
rationale for this request is that having specific proposed language
will help focus the discussion and determining consensus.

Thank you,
Lou (as co-chair)

On 7/29/2016 11:35 AM, Robert Wilton wrote:
>
> Hi Andy,
>
> The main problem that I'm currently trying to solve, and get agreement
> on, is "where does the operator's automated code look to find the
> state nodes associated with a particular config node".
>
> E.g. for feature /foo, do they look for the config false nodes under
> /foo, or do the look somewhere in /foo-state.  The current answer
> appears to be, that the config false nodes could appear in either
> place in the IETF modules without any requirement for a consistent
> approach.  Is that right?
>
> Separately, the OpenConfig folks have said that it would be better if
> they could get (or register for notification of) all of the data
> associated with "foo" with a single request rather than having to make
> multiple requests in different trees.  Personally, I prefer their
> model where they have merged interface-state into interfaces.  Mainly
> because I think that it should make the YANG modules easier to read
> with less duplication of structure, and I think that it is a better
> long term direction to go in.  However, I appreciate Acee's comments
> that we may just be too late to change this now, and we must just
> accept the status quo (whatever that is).
>
> I would like to know what should the common approach for IETF standard
> models be?  E.g. is it one of the following:
>
> 1) All config false leaves for foo must go under /foo-state.
> 2) All config false leaves for foo must go under /foo
> 3) All config false leaves go under /foo where possible, or /foo-state
> otherwise (e.g. for restconf-monitoring).
> 4) Config false leaves go wherever the model writer decides is
> appropriate.
>
> I've put further comments inline below ...
>
>
> On 29/07/2016 15:39, Andy Bierman wrote:
>> Hi,
>>
>> I am somewhat confused about this discussion.
>> Apparently it is a hyge problem to put foo-counters under
>> foo-state?
> RW:
> This isn't just about counters, it is all config false nodes that are
> not present solely to represent "applied configuration".
>
>>   Configuration must be used (and setup by the operator?)
>> in order for foo-counters to exist?
> RW:
> No, this is not being proposed.
>
> draft-schoenw and draft-wilton propose that the config true nodes are
> allowed to exist in an "operational state datastore" to parent child
> config false nodes, even though they haven't been configured.  I also
> proposed that metadata annotations could be used to indicate that the
> containing config=true nodes in the operational state datastore exist
> only in the system (and not in the configuration).
>
> Further I would propose that NETCONF/RESTCONF servers could support an
> "operational state datastore" without any requirement to distinguish
> applied configuration separately from intended configuration.
>
>>
>> So what problem does this solve?
> RW:
> I see that it potentially allows modules to avoid an arbitrary foo vs
> foo-state split.
>
>>
>> The opstate solution proposal requires a config path-expr to be altered
>> to generate the corresponding path-expr under the 'state' container.
> RW:
> Are you referring to the OpenConfig model solution here or
> draft-schoenw, or draft-wilton?
>
>> It does not seem to be a problem that a new path-expr needs to be
>> constructed.
>> Is that what you are trying to solve? Even though counters never have
>> a corresponding configuration node with the same name?
>>
>>
>> So what happens to modules like ietf-restconf-monitoring?
> RW:
> Either it stays exactly as it is now, or alternatively it could just
> be named "restconf" rather than "restconf-state", even if it just
> contains config false nodes.
>
>> It is no longer allowed to write monitoring modules?
> RW:
> It is still allowed to write monitoring modules, no change here.
>
>> They all have 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

Hi Andy,

The main problem that I'm currently trying to solve, and get agreement 
on, is "where does the operator's automated code look to find the state 
nodes associated with a particular config node".


E.g. for feature /foo, do they look for the config false nodes under 
/foo, or do the look somewhere in /foo-state.  The current answer 
appears to be, that the config false nodes could appear in either place 
in the IETF modules without any requirement for a consistent approach.  
Is that right?


Separately, the OpenConfig folks have said that it would be better if 
they could get (or register for notification of) all of the data 
associated with "foo" with a single request rather than having to make 
multiple requests in different trees.  Personally, I prefer their model 
where they have merged interface-state into interfaces.  Mainly because 
I think that it should make the YANG modules easier to read with less 
duplication of structure, and I think that it is a better long term 
direction to go in.  However, I appreciate Acee's comments that we may 
just be too late to change this now, and we must just accept the status 
quo (whatever that is).


I would like to know what should the common approach for IETF standard 
models be?  E.g. is it one of the following:


1) All config false leaves for foo must go under /foo-state.
2) All config false leaves for foo must go under /foo
3) All config false leaves go under /foo where possible, or /foo-state 
otherwise (e.g. for restconf-monitoring).

4) Config false leaves go wherever the model writer decides is appropriate.

I've put further comments inline below ...


On 29/07/2016 15:39, Andy Bierman wrote:

Hi,

I am somewhat confused about this discussion.
Apparently it is a hyge problem to put foo-counters under
foo-state?

RW:
This isn't just about counters, it is all config false nodes that are 
not present solely to represent "applied configuration".



  Configuration must be used (and setup by the operator?)
in order for foo-counters to exist?

RW:
No, this is not being proposed.

draft-schoenw and draft-wilton propose that the config true nodes are 
allowed to exist in an "operational state datastore" to parent child 
config false nodes, even though they haven't been configured. I also 
proposed that metadata annotations could be used to indicate that the 
containing config=true nodes in the operational state datastore exist 
only in the system (and not in the configuration).


Further I would propose that NETCONF/RESTCONF servers could support an 
"operational state datastore" without any requirement to distinguish 
applied configuration separately from intended configuration.




So what problem does this solve?

RW:
I see that it potentially allows modules to avoid an arbitrary foo vs 
foo-state split.




The opstate solution proposal requires a config path-expr to be altered
to generate the corresponding path-expr under the 'state' container.

RW:
Are you referring to the OpenConfig model solution here or 
draft-schoenw, or draft-wilton?


It does not seem to be a problem that a new path-expr needs to be 
constructed.

Is that what you are trying to solve? Even though counters never have
a corresponding configuration node with the same name?


So what happens to modules like ietf-restconf-monitoring?

RW:
Either it stays exactly as it is now, or alternatively it could just be 
named "restconf" rather than "restconf-state", even if it just contains 
config false nodes.



It is no longer allowed to write monitoring modules?

RW:
It is still allowed to write monitoring modules, no change here.


They all have to contained within some configuration nodes?

RW:
No, not necessarily:
 - it they are just state then either call them "foo" or "foo-state" as 
per above.
 - if they are mix of config and state then they would go under "foo", 
which would be a config true node (but not necessarily configured, as 
per my comments on the operational state datastore above).



Again, what problem is this trying to solve?

RW:
Hopefully this one has already been answered above.

Thanks,
Rob





Andy


On Fri, Jul 29, 2016 at 7:15 AM, Ladislav Lhotka > wrote:


Robert Wilton > writes:

> On 28/07/2016 15:20, Ladislav Lhotka wrote:
>>> On 28 Jul 2016, at 15:57, Acee Lindem (acee) > wrote:
>>>
>>> Hi Lada,
>>>
>>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>>>  on
behalf of lho...@nic.cz > wrote:
>>>
 Robert Wilton >
writes:

> On 26/07/2016 21:36, Kent Watsen wrote:
>> 
>>
>>
>> So my thinking is that if we can't merge "foo-state" into
"foo" then
>> instead we should have consistent rules 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

Hi,

I am somewhat confused about this discussion.
Apparently it is a hyge problem to put foo-counters under
foo-state?  Configuration must be used (and setup by the operator?)
in order for foo-counters to exist?

So what problem does this solve?

The opstate solution proposal requires a config path-expr to be altered
to generate the corresponding path-expr under the 'state' container.
It does not seem to be a problem that a new path-expr needs to be
constructed.
Is that what you are trying to solve? Even though counters never have
a corresponding configuration node with the same name?


So what happens to modules like ietf-restconf-monitoring?
It is no longer allowed to write monitoring modules?
They all have to contained within some configuration nodes?
Again, what problem is this trying to solve?


Andy


On Fri, Jul 29, 2016 at 7:15 AM, Ladislav Lhotka  wrote:

> Robert Wilton  writes:
>
> > On 28/07/2016 15:20, Ladislav Lhotka wrote:
> >>> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
> >>>
> >>> Hi Lada,
> >>>
> >>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
> >>>  wrote:
> >>>
>  Robert Wilton  writes:
> 
> > On 26/07/2016 21:36, Kent Watsen wrote:
> >> 
> >>
> >>
> >> So my thinking is that if we can't merge "foo-state" into "foo" then
> >> instead we should have consistent rules that explicitly state that
> for
> >> all IETF models "foo" and "foo-state" are separate trees with a
> >> consistent naming convention and structure.  That should hopefully
> >> allow tooling to programmatically relate the two separate trees
> >> together.  It may give a path to allow "foo-state" to be merged into
> >> "foo" in future, but once IETF has standardized 600+ models with
> >> separate sub-trees, I cannot see that they would get merged back
> >> together again.
> >>
> >> What other alternatives are available?  As a WG we need to tell the
> >> other WGs how the IETF YANG models should be structured.
> >>
> >> In short, unfortunately I think that we have probably already missed
> >> the opportunity to merge "foo" and "foo-state" subtrees together ...
> >>
> >> 
> >>
> >> Firstly, I’m trying to get a sense of how big a problem this
> >> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
> >> counters, not opstate].
> >>
> > RW:
> > By counters, I think that we also mean any config false nodes that
> > don't
> > directly represent "applied configuration", right?  E.g. is an
> > interface
> > operationally up or down.
> >
> >>I know about RFC 7223, which was done out of consideration for
> >> system-generated interfaces, but how many other such models are
> there
> >> envisioned to be?
> >>
> > RW:
> > - Any models that augment RFC 7223 and have config false nodes will
> be
> > impacted.
> > - I thought that quite a lot of other IETF models that are in the
> > process of being standardized have a top level split between "foo"
> and
> > "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
> has
> > this split.  I suspect that all the routing models will be structured
> > similarly.
>  Correct. One reason is that the core routing model envisions
>  system-controlled RIBs.
> 
> > - Although it is perhaps worth pointing out that I think that the
> > OpenConfig modules effectively have exactly this same issue (e.g.
> they
> > have a combined interfaces tree keyed by config true leaves), and
> they
> > pragmatically just ignore the issue of system created interface
> > entries.
>  The NETMOD WG considered this issue quite important in the past.
> 
>  My impression from the OpState discussion is that we are on the quest
> of
>  the philosopher's stone, trying to find a shortcut where none is
>  possible in general. The long session in Berlin concentrated on the
>  life-cycle of a single parameter that's somehow configured, then
>  manipulated, and eventually ends up as operational state. IMO this
>  is too simplistic, the relationship between configuration and state
> can
>  be much more complex. RIB is one example - it combines contributions
>  from configuration (static routes) and derived state (routing
>  protocols).
> >>> If one were to support the Applied-Config data store, it be comprised
> of
> >>> only the current state of the configured static routes.  The complete
> RIB
> >>> would still need to be accessible in separate data nodes.
> >> Yes, but I didn't talk about intended-applied. I understand that
> another goal of OpState is to unify config and (true) state and get rid of
> the foo and foo-state dichotomy in the data model. I am sceptical about it.
> > The goal is/was to 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

Hi Andy,

I think that it would be fair to say that the authors of 
draft-openconfig-netmod-opstate-01 think that it broken (e.g. sections 
6.1, 8.1.2), particularly given that they have decided that it is better 
to have their own OpenConfig version of interfaces rather than augment 
RFC 7223.  I might be mistaken, but my understanding is that the reason 
that they have done this is to avoid the interfaces vs interfaces-state 
split.


My impression from conversations in Berlin is that other individuals at 
IETF also don't particularly like the foo vs foo-state split, 
particularly for interfaces.


Regarding not breaking existing users, yes, I agree with you.  But this 
could still allow a new version of RFC 7223 to be published that marks 
the existing interfaces-state tree nodes as deprecated and adds new 
config false leaves to be under /interfaces.


Thanks,
Rob


On 27/07/2016 21:29, Andy Bierman wrote:

Hi,

*Re: - Any models that augment RFC 7223 and have config false nodes 
will be impacted.*


There are many such vendor modules already.
They augment the /interfaces container with config
and the /interfaces-state container with non-config.
Nobody is complaining this is broken, AFAIK.
If you tell them to throw it out and start over, the request
is likely to be ignored.


Andy


On Wed, Jul 27, 2016 at 1:09 PM, Kent Watsen > wrote:


>> Firstly, I’m trying to get a sense of how big a problem this

>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring

>> to counters, not opstate].

RW:
By counters, I think that we also mean any config false nodes that
don't directly represent "applied configuration", right? E.g. is
an interface operationally up or down.

KW:  Yes, the term “counters” is a misnomer.  We are indeed
talking about regular old config false nodes, whether they be used
for counters, gauges, or whatever.   It is what the opstate-reqs
draft refers to as derived state.

>> I know about RFC 7223, which was done out of consideration

>> for system-generated interfaces, but how many other such models

>> are there envisioned to be?

RW:
- Any models that augment RFC 7223 and have config false nodes
will be impacted.
- I thought that quite a lot of other IETF models that are in the
process of being standardized have a top level split between "foo"
and "foo-state".  E.g the ISIS model
(draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect that
all the routing models will be structured similarly.

KW: I also notice that draft-ietf-netmod-routing-cfg does this
and, to your point, you know the ietf-routing module is intended
to be augmented by many other modules.  This issue is not easily
isolated.

RW:
The current guidance for "intended vs applied" is clear.  I.e.
there must not be "config false" leaves in the IETF YANG data
models to represent "applied config".  But there is no clear
guidance for the rest of operational state that isn't applied
config.  The other WGs need clear guidance (effectively now) to
ensure that they can start publishing models as RFCs.

KW: indeed.

RW:
Personally, I would like one common convention that applies to all
IETF YANG models.

Idealistically I would like foo and foo-state to be merged because
I think that will make the models easier to use and maintain in
the long term, but I don't know if we are just too late to go in
that direction.  It seems to me that the NETMOD WG really should
try to come to a decision quite quickly on this, but I don't know
how to encourage that.  A virtual interim on just this topic perhaps?

KW: I was going to suggest the same - will discuss with Lou.

>> Next, regarding paths forward (assuming 7223 is not an
outlier), I’m

>> thinking the opposite.  I’m quite sure that we would never
merge the

>> 600+ models with separate subtrees back together again.  So I’m

>> thinking we immediately merge foo and foo-state in all active YANG

>> models (so that the YANG “conceptual” models are stable and good)

>> *and* then we use your idea to programmatically generate the

>> “foo-state” tree, presumably only when needed.  This foo-state tree

>> could be generated offline by tools and provided as a second YANG

>> module in drafts. In this way, servers (opstate aware or not) can

>> advertise if clients can access the foo-state tree (an
opstate-aware

>> server may still advertise it for business reasons, and it can
‘deprecate’

>> the tree when no longer needed).   We could do the same without
tools

>> today by just using a feature statement on, for instance, the
interfaces-

>> state container, but I like pushing for tooling upfront so that
we’re

>> guaranteed mergeability later.  Thoughts?

RW:
So the 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

Agreed. I’m not saying it isn’t possible to have a combined config/state
tree. My previous point is that it represents a major shift and would be
hard to reach consensus in the desired time frame.

Thanks,
Acee 

On 7/28/16, 10:57 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)"  wrote:

>
>
>On 28/07/2016 15:48, Acee Lindem (acee) wrote:
>>
>> On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
>> Cisco)"  wrote:
>>
>>>
>>> On 28/07/2016 15:20, Ladislav Lhotka wrote:
> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
>
> Hi Lada,
>
> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
>
>> Robert Wilton  writes:
>>
>>> On 26/07/2016 21:36, Kent Watsen wrote:
 


 So my thinking is that if we can't merge "foo-state" into "foo"
then
 instead we should have consistent rules that explicitly state that
 for
 all IETF models "foo" and "foo-state" are separate trees with a
 consistent naming convention and structure.  That should hopefully
 allow tooling to programmatically relate the two separate trees
 together.  It may give a path to allow "foo-state" to be merged
into
 "foo" in future, but once IETF has standardized 600+ models with
 separate sub-trees, I cannot see that they would get merged back
 together again.

 What other alternatives are available?  As a WG we need to tell
the
 other WGs how the IETF YANG models should be structured.

 In short, unfortunately I think that we have probably already
missed
 the opportunity to merge "foo" and "foo-state" subtrees together
...

 

 Firstly, I’m trying to get a sense of how big a problem this
 foo/foo-state thing is.  [Note: by foo-state, I’m only referring
to
 counters, not opstate].

>>> RW:
>>> By counters, I think that we also mean any config false nodes that
>>> don't
>>> directly represent "applied configuration", right?  E.g. is an
>>> interface
>>> operationally up or down.
>>>
 I know about RFC 7223, which was done out of consideration for
 system-generated interfaces, but how many other such models are
 there
 envisioned to be?

>>> RW:
>>> - Any models that augment RFC 7223 and have config false nodes will
>>> be
>>> impacted.
>>> - I thought that quite a lot of other IETF models that are in the
>>> process of being standardized have a top level split between "foo"
>>> and
>>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
>>> has
>>> this split.  I suspect that all the routing models will be
>>>structured
>>> similarly.
>> Correct. One reason is that the core routing model envisions
>> system-controlled RIBs.
>>
>>> - Although it is perhaps worth pointing out that I think that the
>>> OpenConfig modules effectively have exactly this same issue (e.g.
>>> they
>>> have a combined interfaces tree keyed by config true leaves), and
>>> they
>>> pragmatically just ignore the issue of system created interface
>>> entries.
>> The NETMOD WG considered this issue quite important in the past.
>>
>> My impression from the OpState discussion is that we are on the
>>quest
>> of
>> the philosopher's stone, trying to find a shortcut where none is
>> possible in general. The long session in Berlin concentrated on the
>> life-cycle of a single parameter that's somehow configured, then
>> manipulated, and eventually ends up as operational state. IMO this
>> is too simplistic, the relationship between configuration and state
>> can
>> be much more complex. RIB is one example - it combines contributions
>> from configuration (static routes) and derived state (routing
>> protocols).
> If one were to support the Applied-Config data store, it be comprised
> of
> only the current state of the configured static routes.  The complete
> RIB
> would still need to be accessible in separate data nodes.
 Yes, but I didn't talk about intended-applied. I understand that
 another goal of OpState is to unify config and (true) state and get
rid
 of the foo and foo-state dichotomy in the data model. I am sceptical
 about it.
>>> The goal is/was to unify where the only reason that they were split was
>>> because the lifetime of the configured containing datanode may differ
>> >from the operational containing datanode.  E.g. interfaces vs
>>> interfaces-state was split to allow for system created interfaces that
>>> were not configured, but other than 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

On 7/28/16, 10:20 AM, "Ladislav Lhotka"  wrote:

>
>> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
>> 
>> Hi Lada, 
>> 
>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>> 
>>> Robert Wilton  writes:
>>> 
 On 26/07/2016 21:36, Kent Watsen wrote:
> 
> 
> 
> 
> So my thinking is that if we can't merge "foo-state" into "foo" then
> instead we should have consistent rules that explicitly state that
>for
> all IETF models "foo" and "foo-state" are separate trees with a
> consistent naming convention and structure.  That should hopefully
> allow tooling to programmatically relate the two separate trees
> together.  It may give a path to allow "foo-state" to be merged into
> "foo" in future, but once IETF has standardized 600+ models with
> separate sub-trees, I cannot see that they would get merged back
> together again.
> 
> What other alternatives are available?  As a WG we need to tell the
> other WGs how the IETF YANG models should be structured.
> 
> In short, unfortunately I think that we have probably already missed
> the opportunity to merge "foo" and "foo-state" subtrees together ...
> 
> 
> 
> Firstly, I’m trying to get a sense of how big a problem this
> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
> counters, not opstate].
> 
 RW:
 By counters, I think that we also mean any config false nodes that
 don't 
 directly represent "applied configuration", right?  E.g. is an
 interface 
 operationally up or down.
 
>   I know about RFC 7223, which was done out of consideration for
> system-generated interfaces, but how many other such models are there
> envisioned to be?
> 
 RW:
 - Any models that augment RFC 7223 and have config false nodes will be
 impacted.
 - I thought that quite a lot of other IETF models that are in the
 process of being standardized have a top level split between "foo" and
 "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
has
 this split.  I suspect that all the routing models will be structured
 similarly.
>>> 
>>> Correct. One reason is that the core routing model envisions
>>> system-controlled RIBs.
>>> 
 - Although it is perhaps worth pointing out that I think that the
 OpenConfig modules effectively have exactly this same issue (e.g. they
 have a combined interfaces tree keyed by config true leaves), and they
 pragmatically just ignore the issue of system created interface
 entries.
>>> 
>>> The NETMOD WG considered this issue quite important in the past.
>>> 
>>> My impression from the OpState discussion is that we are on the quest
>>>of
>>> the philosopher's stone, trying to find a shortcut where none is
>>> possible in general. The long session in Berlin concentrated on the
>>> life-cycle of a single parameter that's somehow configured, then
>>> manipulated, and eventually ends up as operational state. IMO this
>>> is too simplistic, the relationship between configuration and state can
>>> be much more complex. RIB is one example - it combines contributions
>>> from configuration (static routes) and derived state (routing
>>> protocols).
>> 
>> If one were to support the Applied-Config data store, it be comprised of
>> only the current state of the configured static routes.  The complete
>>RIB
>> would still need to be accessible in separate data nodes.
>
>Yes, but I didn't talk about intended-applied. I understand that another
>goal of OpState is to unify config and (true) state and get rid of the
>foo and foo-state dichotomy in the data model. I am sceptical about it.

Suffice it to day that in a combined tree there will be state that has not
corresponding config. For example, the populated global RIB instances
would fall into this category.

Thanks,
Acee 



>
>Lada
>
>> 
>> Thanks,
>> Acee 
>> 
>> 
>> 
>>> 
>>> After all, most real devices have some configuration mode and "show"
>>> commands. They are separate even though there is certainly some
>>> relationship between their data.
>>> 
>>> Lada
>>> 
 
> Is this issue currently blocking models from progressing, or are we
> getting ourselves wrapped around a hypothetical?
> 
 RW:
 I think that it is blocking models from progressing.
 
 The current guidance for "intended vs applied" is clear.  I.e. there
 must not be "config false" leaves in the IETF YANG data models to
 represent "applied config".
 
 But there is no clear guidance for the rest of operational state that
 isn't applied config.  The other WGs need clear guidance (effectively
 now) to ensure that they can start publishing models as RFCs.
 
 
>  If RFC 7223 is an outlier, then we can address it as a special 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 27/07/2016 20:44, Acee Lindem (acee) wrote:



From: netmod <netmod-boun...@ietf.org 
<mailto:netmod-boun...@ietf.org>> on behalf of Mahesh Jethanandani 
<mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>>

Date: Wednesday, July 27, 2016 at 9:07 PM
To: Xufeng Liu <xufeng.liu.i...@gmail.com 
<mailto:xufeng.liu.i...@gmail.com>>

Cc: netmod WG <netmod@ietf.org <mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF 
YANG Model Structure


Robert mentions IS-IS, and if I look at OSPF, I see a clear
separation of rw and ro nodes.


Right - and this separation is based on the routing and routing-state 
split in the ietf-routing-cfg model. In general, ietf-routing-cfg 
specifies that all control plane protocol YANG models should adapt 
this structure. Anyone who thinks collapsing all the models one 
config/state tree is simply a matter of moving a few counters should 
taking a better look at the existing drafts. I outlined the options in 
the E-mail thread prior to IETF 96.  Now, with the context of IETF 96 
behind us, I believe more NETMOD participants will understand the 
options. To review the options specified in the previous E-mail thread.


   1. Do nothing - allow them proceed as they are with multiple ways of
   representing the applied configuration. This would provide 
visibility to
   the data independent of whether or not the device supported the 
revised
   data-stores supporting implicit retrieval of the applied 
configuration.

   2. Prune out the redundant data nodes except those required as list
keys, etc, since they can be obtained from the applied state 
data store.

  3. #2 plus collapse the config (read-write) and  system-state
   (read-only) into common containers. No more branching of
   -config and -state at the top level of 
the model.


Prior to IETF 96, I don’t believe we had selected a direction. 
However, I believe we agreed on option #1 in order to allow the 
publication of these models within the next year. We’d still be able 
to avail the benefits of applied vs intended configuration on network 
devices supporting these data stores.

My take is that I think that the leaning at IETF was towards 2.

I.e. I think that we ruled out 1.  I.e. the models must not have 
separate nodes to represent applied configuration because that will be 
solved by the datastore solution.


But it feels a bit inconsistent that the models don't need to have 
explicit leaves for foo vs foo-applied (because it will be solved by 
datastores), but the models do still need explicit leaves for foo vs 
foo-state (even though this could/should also be solved by an 
operational state datastore - noting that both draft-schoenw and 
draft-wilton propose a solution to this problem).


My preference, if we can get quick consensus would be to do 3, or if 
consensus is not possible for 3, then we should fallback to doing 2, as 
the next best option.  But whatever the decision, I favour agreeing a 
direction quickly so that the other WGs know what to put in the RFCs.


Thanks,
Rob



Thanks,
Acee






On Jul 27, 2016, at 11:22 AM, Xufeng Liu
<xufeng.liu.i...@gmail.com <mailto:xufeng.liu.i...@gmail.com>> wrote:

The assumption of “I suspect that all the routing models will be
structured similarly” is not correct. Very few models in routing
area structure this way.
Regards,
- Xufeng
*From:*netmod [mailto:netmod-boun...@ietf.org]*On Behalf
Of*Robert Wilton
*Sent:*Wednesday, July 27, 2016 1:05 PM
*To:*Kent Watsen <kwat...@juniper.net
<mailto:kwat...@juniper.net>>; netmod WG <netmod@ietf.org
    <mailto:netmod@ietf.org>>
    *Subject:*Re: [netmod] OpsState Direction Impact on Recommended
IETF YANG Model Structure

On 26/07/2016 21:36, Kent Watsen wrote:



So my thinking is that if we can't merge "foo-state" into "foo"
then instead we should have consistent rules that explicitly
state that for all IETF models "foo" and "foo-state" are
separate trees with a consistent naming convention and
structure.  That should hopefully allow tooling to
programmatically relate the two separate trees together.  It may
give a path to allow "foo-state" to be merged into "foo" in
future, but once IETF has standardized 600+ models with separate
sub-trees, I cannot see that they would get merged back together
again.

What other alternatives are available?  As a WG we need to tell
the other WGs how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already
missed the opportunity to merge "foo" and "foo-state" subtrees
together ...



Firstly, I’m trying to get a sense of how big a problem this
foo/foo-state thing is.  [Note

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Ladislav Lhotka]

> On 28 Jul 2016, at 16:48, Acee Lindem (acee)  wrote:
> 
> 
> 
> On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
> Cisco)"  wrote:
> 
>> 
>> 
>> On 28/07/2016 15:20, Ladislav Lhotka wrote:
 On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
 
 Hi Lada,
 
 On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
  wrote:
 
> Robert Wilton  writes:
> 
>> On 26/07/2016 21:36, Kent Watsen wrote:
>>> 
>>> 
>>> 
>>> So my thinking is that if we can't merge "foo-state" into "foo" then
>>> instead we should have consistent rules that explicitly state that
>>> for
>>> all IETF models "foo" and "foo-state" are separate trees with a
>>> consistent naming convention and structure.  That should hopefully
>>> allow tooling to programmatically relate the two separate trees
>>> together.  It may give a path to allow "foo-state" to be merged into
>>> "foo" in future, but once IETF has standardized 600+ models with
>>> separate sub-trees, I cannot see that they would get merged back
>>> together again.
>>> 
>>> What other alternatives are available?  As a WG we need to tell the
>>> other WGs how the IETF YANG models should be structured.
>>> 
>>> In short, unfortunately I think that we have probably already missed
>>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>> 
>>> 
>>> 
>>> Firstly, I’m trying to get a sense of how big a problem this
>>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
>>> counters, not opstate].
>>> 
>> RW:
>> By counters, I think that we also mean any config false nodes that
>> don't
>> directly represent "applied configuration", right?  E.g. is an
>> interface
>> operationally up or down.
>> 
>>>   I know about RFC 7223, which was done out of consideration for
>>> system-generated interfaces, but how many other such models are
>>> there
>>> envisioned to be?
>>> 
>> RW:
>> - Any models that augment RFC 7223 and have config false nodes will
>> be
>> impacted.
>> - I thought that quite a lot of other IETF models that are in the
>> process of being standardized have a top level split between "foo"
>> and
>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
>> has
>> this split.  I suspect that all the routing models will be structured
>> similarly.
> Correct. One reason is that the core routing model envisions
> system-controlled RIBs.
> 
>> - Although it is perhaps worth pointing out that I think that the
>> OpenConfig modules effectively have exactly this same issue (e.g.
>> they
>> have a combined interfaces tree keyed by config true leaves), and
>> they
>> pragmatically just ignore the issue of system created interface
>> entries.
> The NETMOD WG considered this issue quite important in the past.
> 
> My impression from the OpState discussion is that we are on the quest
> of
> the philosopher's stone, trying to find a shortcut where none is
> possible in general. The long session in Berlin concentrated on the
> life-cycle of a single parameter that's somehow configured, then
> manipulated, and eventually ends up as operational state. IMO this
> is too simplistic, the relationship between configuration and state
> can
> be much more complex. RIB is one example - it combines contributions
> from configuration (static routes) and derived state (routing
> protocols).
 If one were to support the Applied-Config data store, it be comprised
 of
 only the current state of the configured static routes.  The complete
 RIB
 would still need to be accessible in separate data nodes.
>>> Yes, but I didn't talk about intended-applied. I understand that
>>> another goal of OpState is to unify config and (true) state and get rid
>>> of the foo and foo-state dichotomy in the data model. I am sceptical
>>> about it.
>> The goal is/was to unify where the only reason that they were split was
>> because the lifetime of the configured containing datanode may differ
>> from the operational containing datanode.  E.g. interfaces vs
>> interfaces-state was split to allow for system created interfaces that
>> were not configured, but other than this reason the split seems quite
>> artificial and not particularly helpful.
>> 
>> OpenConfig is modelling interfaces and interfaces-state as a single
>> list.  It would be kind of helpful if IETF models and OpenConfig models
>> could be consistent in this regard, and I prefer the combined list
>> approach used by OpenConfig interfaces (on the assumption that we can
>> solve the technical problems associated with this approach - which 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 28/07/2016 15:48, Acee Lindem (acee) wrote:


On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)"  wrote:



On 28/07/2016 15:20, Ladislav Lhotka wrote:

On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:

Hi Lada,

On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:


Robert Wilton  writes:


On 26/07/2016 21:36, Kent Watsen wrote:




So my thinking is that if we can't merge "foo-state" into "foo" then
instead we should have consistent rules that explicitly state that
for
all IETF models "foo" and "foo-state" are separate trees with a
consistent naming convention and structure.  That should hopefully
allow tooling to programmatically relate the two separate trees
together.  It may give a path to allow "foo-state" to be merged into
"foo" in future, but once IETF has standardized 600+ models with
separate sub-trees, I cannot see that they would get merged back
together again.

What other alternatives are available?  As a WG we need to tell the
other WGs how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed
the opportunity to merge "foo" and "foo-state" subtrees together ...



Firstly, I’m trying to get a sense of how big a problem this
foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
counters, not opstate].


RW:
By counters, I think that we also mean any config false nodes that
don't
directly represent "applied configuration", right?  E.g. is an
interface
operationally up or down.


I know about RFC 7223, which was done out of consideration for
system-generated interfaces, but how many other such models are
there
envisioned to be?


RW:
- Any models that augment RFC 7223 and have config false nodes will
be
impacted.
- I thought that quite a lot of other IETF models that are in the
process of being standardized have a top level split between "foo"
and
"foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
has
this split.  I suspect that all the routing models will be structured
similarly.

Correct. One reason is that the core routing model envisions
system-controlled RIBs.


- Although it is perhaps worth pointing out that I think that the
OpenConfig modules effectively have exactly this same issue (e.g.
they
have a combined interfaces tree keyed by config true leaves), and
they
pragmatically just ignore the issue of system created interface
entries.

The NETMOD WG considered this issue quite important in the past.

My impression from the OpState discussion is that we are on the quest
of
the philosopher's stone, trying to find a shortcut where none is
possible in general. The long session in Berlin concentrated on the
life-cycle of a single parameter that's somehow configured, then
manipulated, and eventually ends up as operational state. IMO this
is too simplistic, the relationship between configuration and state
can
be much more complex. RIB is one example - it combines contributions
from configuration (static routes) and derived state (routing
protocols).

If one were to support the Applied-Config data store, it be comprised
of
only the current state of the configured static routes.  The complete
RIB
would still need to be accessible in separate data nodes.

Yes, but I didn't talk about intended-applied. I understand that
another goal of OpState is to unify config and (true) state and get rid
of the foo and foo-state dichotomy in the data model. I am sceptical
about it.

The goal is/was to unify where the only reason that they were split was
because the lifetime of the configured containing datanode may differ

>from the operational containing datanode.  E.g. interfaces vs

interfaces-state was split to allow for system created interfaces that
were not configured, but other than this reason the split seems quite
artificial and not particularly helpful.

OpenConfig is modelling interfaces and interfaces-state as a single
list.  It would be kind of helpful if IETF models and OpenConfig models
could be consistent in this regard, and I prefer the combined list
approach used by OpenConfig interfaces (on the assumption that we can
solve the technical problems associated with this approach - which I
think that we can).

I've no particular issue with a RIB existing under routing-state. But
personally, if it was the ISIS specific routing table, I would prefer it
to be under a single top level ISIS container on the assumption that you
cannot really have an ISIS routing table if ISIS isn't actually running
on the device.

Don’t confuse a global RIB instance with an IS-IS local RIB instance.
These are separate tables (although the former may contain active entries
from the latter) and both would be interesting from an operational
perspective.
Sorry, I wasn't trying to -  I should have written "a global RIB" 
instead of "a RIB" ;-)


I am suggesting that a global 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)"  wrote:

>
>
>On 28/07/2016 15:20, Ladislav Lhotka wrote:
>>> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
>>>
>>> Hi Lada,
>>>
>>> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>>
 Robert Wilton  writes:

> On 26/07/2016 21:36, Kent Watsen wrote:
>> 
>>
>>
>> So my thinking is that if we can't merge "foo-state" into "foo" then
>> instead we should have consistent rules that explicitly state that
>>for
>> all IETF models "foo" and "foo-state" are separate trees with a
>> consistent naming convention and structure.  That should hopefully
>> allow tooling to programmatically relate the two separate trees
>> together.  It may give a path to allow "foo-state" to be merged into
>> "foo" in future, but once IETF has standardized 600+ models with
>> separate sub-trees, I cannot see that they would get merged back
>> together again.
>>
>> What other alternatives are available?  As a WG we need to tell the
>> other WGs how the IETF YANG models should be structured.
>>
>> In short, unfortunately I think that we have probably already missed
>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>
>> 
>>
>> Firstly, I’m trying to get a sense of how big a problem this
>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
>> counters, not opstate].
>>
> RW:
> By counters, I think that we also mean any config false nodes that
> don't
> directly represent "applied configuration", right?  E.g. is an
> interface
> operationally up or down.
>
>>I know about RFC 7223, which was done out of consideration for
>> system-generated interfaces, but how many other such models are
>>there
>> envisioned to be?
>>
> RW:
> - Any models that augment RFC 7223 and have config false nodes will
>be
> impacted.
> - I thought that quite a lot of other IETF models that are in the
> process of being standardized have a top level split between "foo"
>and
> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08)
>has
> this split.  I suspect that all the routing models will be structured
> similarly.
 Correct. One reason is that the core routing model envisions
 system-controlled RIBs.

> - Although it is perhaps worth pointing out that I think that the
> OpenConfig modules effectively have exactly this same issue (e.g.
>they
> have a combined interfaces tree keyed by config true leaves), and
>they
> pragmatically just ignore the issue of system created interface
> entries.
 The NETMOD WG considered this issue quite important in the past.

 My impression from the OpState discussion is that we are on the quest
of
 the philosopher's stone, trying to find a shortcut where none is
 possible in general. The long session in Berlin concentrated on the
 life-cycle of a single parameter that's somehow configured, then
 manipulated, and eventually ends up as operational state. IMO this
 is too simplistic, the relationship between configuration and state
can
 be much more complex. RIB is one example - it combines contributions
 from configuration (static routes) and derived state (routing
 protocols).
>>> If one were to support the Applied-Config data store, it be comprised
>>>of
>>> only the current state of the configured static routes.  The complete
>>>RIB
>>> would still need to be accessible in separate data nodes.
>> Yes, but I didn't talk about intended-applied. I understand that
>>another goal of OpState is to unify config and (true) state and get rid
>>of the foo and foo-state dichotomy in the data model. I am sceptical
>>about it.
>The goal is/was to unify where the only reason that they were split was
>because the lifetime of the configured containing datanode may differ
>from the operational containing datanode.  E.g. interfaces vs
>interfaces-state was split to allow for system created interfaces that
>were not configured, but other than this reason the split seems quite
>artificial and not particularly helpful.
>
>OpenConfig is modelling interfaces and interfaces-state as a single
>list.  It would be kind of helpful if IETF models and OpenConfig models
>could be consistent in this regard, and I prefer the combined list
>approach used by OpenConfig interfaces (on the assumption that we can
>solve the technical problems associated with this approach - which I
>think that we can).
>
>I've no particular issue with a RIB existing under routing-state. But
>personally, if it was the ISIS specific routing table, I would prefer it
>to be under a single top level ISIS container on the 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 28/07/2016 15:20, Ladislav Lhotka wrote:

On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:

Hi Lada,

On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:


Robert Wilton  writes:


On 26/07/2016 21:36, Kent Watsen wrote:




So my thinking is that if we can't merge "foo-state" into "foo" then
instead we should have consistent rules that explicitly state that for
all IETF models "foo" and "foo-state" are separate trees with a
consistent naming convention and structure.  That should hopefully
allow tooling to programmatically relate the two separate trees
together.  It may give a path to allow "foo-state" to be merged into
"foo" in future, but once IETF has standardized 600+ models with
separate sub-trees, I cannot see that they would get merged back
together again.

What other alternatives are available?  As a WG we need to tell the
other WGs how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed
the opportunity to merge "foo" and "foo-state" subtrees together ...



Firstly, I’m trying to get a sense of how big a problem this
foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
counters, not opstate].


RW:
By counters, I think that we also mean any config false nodes that
don't
directly represent "applied configuration", right?  E.g. is an
interface
operationally up or down.


   I know about RFC 7223, which was done out of consideration for
system-generated interfaces, but how many other such models are there
envisioned to be?


RW:
- Any models that augment RFC 7223 and have config false nodes will be
impacted.
- I thought that quite a lot of other IETF models that are in the
process of being standardized have a top level split between "foo" and
"foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has
this split.  I suspect that all the routing models will be structured
similarly.

Correct. One reason is that the core routing model envisions
system-controlled RIBs.


- Although it is perhaps worth pointing out that I think that the
OpenConfig modules effectively have exactly this same issue (e.g. they
have a combined interfaces tree keyed by config true leaves), and they
pragmatically just ignore the issue of system created interface
entries.

The NETMOD WG considered this issue quite important in the past.

My impression from the OpState discussion is that we are on the quest of
the philosopher's stone, trying to find a shortcut where none is
possible in general. The long session in Berlin concentrated on the
life-cycle of a single parameter that's somehow configured, then
manipulated, and eventually ends up as operational state. IMO this
is too simplistic, the relationship between configuration and state can
be much more complex. RIB is one example - it combines contributions
from configuration (static routes) and derived state (routing
protocols).

If one were to support the Applied-Config data store, it be comprised of
only the current state of the configured static routes.  The complete RIB
would still need to be accessible in separate data nodes.

Yes, but I didn't talk about intended-applied. I understand that another goal 
of OpState is to unify config and (true) state and get rid of the foo and 
foo-state dichotomy in the data model. I am sceptical about it.
The goal is/was to unify where the only reason that they were split was 
because the lifetime of the configured containing datanode may differ 
from the operational containing datanode.  E.g. interfaces vs 
interfaces-state was split to allow for system created interfaces that 
were not configured, but other than this reason the split seems quite 
artificial and not particularly helpful.


OpenConfig is modelling interfaces and interfaces-state as a single 
list.  It would be kind of helpful if IETF models and OpenConfig models 
could be consistent in this regard, and I prefer the combined list 
approach used by OpenConfig interfaces (on the assumption that we can 
solve the technical problems associated with this approach - which I 
think that we can).


I've no particular issue with a RIB existing under routing-state. But 
personally, if it was the ISIS specific routing table, I would prefer it 
to be under a single top level ISIS container on the assumption that you 
cannot really have an ISIS routing table if ISIS isn't actually running 
on the device.


Cheers,
Rob



Lada


Thanks,
Acee




After all, most real devices have some configuration mode and "show"
commands. They are separate even though there is certainly some
relationship between their data.

Lada


Is this issue currently blocking models from progressing, or are we
getting ourselves wrapped around a hypothetical?


RW:
I think that it is blocking models from progressing.

The current guidance for "intended vs applied" is clear.  I.e. there
must not be "config false" 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Ladislav Lhotka]

> On 28 Jul 2016, at 15:57, Acee Lindem (acee)  wrote:
> 
> Hi Lada, 
> 
> On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
> 
>> Robert Wilton  writes:
>> 
>>> On 26/07/2016 21:36, Kent Watsen wrote:
 
 
 
 
 So my thinking is that if we can't merge "foo-state" into "foo" then
 instead we should have consistent rules that explicitly state that for
 all IETF models "foo" and "foo-state" are separate trees with a
 consistent naming convention and structure.  That should hopefully
 allow tooling to programmatically relate the two separate trees
 together.  It may give a path to allow "foo-state" to be merged into
 "foo" in future, but once IETF has standardized 600+ models with
 separate sub-trees, I cannot see that they would get merged back
 together again.
 
 What other alternatives are available?  As a WG we need to tell the
 other WGs how the IETF YANG models should be structured.
 
 In short, unfortunately I think that we have probably already missed
 the opportunity to merge "foo" and "foo-state" subtrees together ...
 
 
 
 Firstly, I’m trying to get a sense of how big a problem this
 foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
 counters, not opstate].
 
>>> RW:
>>> By counters, I think that we also mean any config false nodes that
>>> don't 
>>> directly represent "applied configuration", right?  E.g. is an
>>> interface 
>>> operationally up or down.
>>> 
   I know about RFC 7223, which was done out of consideration for
 system-generated interfaces, but how many other such models are there
 envisioned to be?
 
>>> RW:
>>> - Any models that augment RFC 7223 and have config false nodes will be
>>> impacted.
>>> - I thought that quite a lot of other IETF models that are in the
>>> process of being standardized have a top level split between "foo" and
>>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has
>>> this split.  I suspect that all the routing models will be structured
>>> similarly.
>> 
>> Correct. One reason is that the core routing model envisions
>> system-controlled RIBs.
>> 
>>> - Although it is perhaps worth pointing out that I think that the
>>> OpenConfig modules effectively have exactly this same issue (e.g. they
>>> have a combined interfaces tree keyed by config true leaves), and they
>>> pragmatically just ignore the issue of system created interface
>>> entries.
>> 
>> The NETMOD WG considered this issue quite important in the past.
>> 
>> My impression from the OpState discussion is that we are on the quest of
>> the philosopher's stone, trying to find a shortcut where none is
>> possible in general. The long session in Berlin concentrated on the
>> life-cycle of a single parameter that's somehow configured, then
>> manipulated, and eventually ends up as operational state. IMO this
>> is too simplistic, the relationship between configuration and state can
>> be much more complex. RIB is one example - it combines contributions
>> from configuration (static routes) and derived state (routing
>> protocols).
> 
> If one were to support the Applied-Config data store, it be comprised of
> only the current state of the configured static routes.  The complete RIB
> would still need to be accessible in separate data nodes.

Yes, but I didn't talk about intended-applied. I understand that another goal 
of OpState is to unify config and (true) state and get rid of the foo and 
foo-state dichotomy in the data model. I am sceptical about it.

Lada

> 
> Thanks,
> Acee 
> 
> 
> 
>> 
>> After all, most real devices have some configuration mode and "show"
>> commands. They are separate even though there is certainly some
>> relationship between their data.
>> 
>> Lada
>> 
>>> 
 Is this issue currently blocking models from progressing, or are we
 getting ourselves wrapped around a hypothetical?
 
>>> RW:
>>> I think that it is blocking models from progressing.
>>> 
>>> The current guidance for "intended vs applied" is clear.  I.e. there
>>> must not be "config false" leaves in the IETF YANG data models to
>>> represent "applied config".
>>> 
>>> But there is no clear guidance for the rest of operational state that
>>> isn't applied config.  The other WGs need clear guidance (effectively
>>> now) to ensure that they can start publishing models as RFCs.
>>> 
>>> 
  If RFC 7223 is an outlier, then we can address it as a special case
 (perhaps via the related-state/related-config YANG annotations).  What
 do you think?
 
>>> RW:
>>> Personally, I would like one common convention that applies to all IETF
>>> YANG models.
>>> 
>>> Idealistically I would like foo and foo-state to be merged because I
>>> think that will make the models easier to use and maintain in the long
>>> term, but I don't know if we 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

Hi Lada, 

On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Robert Wilton  writes:
>
>> On 26/07/2016 21:36, Kent Watsen wrote:
>>>
>>> 
>>>
>>>
>>> So my thinking is that if we can't merge "foo-state" into "foo" then
>>> instead we should have consistent rules that explicitly state that for
>>> all IETF models "foo" and "foo-state" are separate trees with a
>>> consistent naming convention and structure.  That should hopefully
>>> allow tooling to programmatically relate the two separate trees
>>> together.  It may give a path to allow "foo-state" to be merged into
>>> "foo" in future, but once IETF has standardized 600+ models with
>>> separate sub-trees, I cannot see that they would get merged back
>>> together again.
>>>
>>> What other alternatives are available?  As a WG we need to tell the
>>> other WGs how the IETF YANG models should be structured.
>>>
>>> In short, unfortunately I think that we have probably already missed
>>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>>
>>> 
>>>
>>> Firstly, I’m trying to get a sense of how big a problem this
>>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to
>>> counters, not opstate].
>>>
>> RW:
>> By counters, I think that we also mean any config false nodes that
>>don't 
>> directly represent "applied configuration", right?  E.g. is an
>>interface 
>> operationally up or down.
>>
>>>I know about RFC 7223, which was done out of consideration for
>>> system-generated interfaces, but how many other such models are there
>>> envisioned to be?
>>>
>> RW:
>> - Any models that augment RFC 7223 and have config false nodes will be
>> impacted.
>> - I thought that quite a lot of other IETF models that are in the
>> process of being standardized have a top level split between "foo" and
>> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has
>> this split.  I suspect that all the routing models will be structured
>> similarly.
>
>Correct. One reason is that the core routing model envisions
>system-controlled RIBs.
>
>> - Although it is perhaps worth pointing out that I think that the
>> OpenConfig modules effectively have exactly this same issue (e.g. they
>> have a combined interfaces tree keyed by config true leaves), and they
>> pragmatically just ignore the issue of system created interface
>> entries.
>
>The NETMOD WG considered this issue quite important in the past.
>
>My impression from the OpState discussion is that we are on the quest of
>the philosopher's stone, trying to find a shortcut where none is
>possible in general. The long session in Berlin concentrated on the
>life-cycle of a single parameter that's somehow configured, then
>manipulated, and eventually ends up as operational state. IMO this
>is too simplistic, the relationship between configuration and state can
>be much more complex. RIB is one example - it combines contributions
>from configuration (static routes) and derived state (routing
>protocols).

If one were to support the Applied-Config data store, it be comprised of
only the current state of the configured static routes.  The complete RIB
would still need to be accessible in separate data nodes.

Thanks,
Acee 



>
>After all, most real devices have some configuration mode and "show"
>commands. They are separate even though there is certainly some
>relationship between their data.
>
>Lada
>
>>
>>>  Is this issue currently blocking models from progressing, or are we
>>> getting ourselves wrapped around a hypothetical?
>>>
>> RW:
>> I think that it is blocking models from progressing.
>>
>> The current guidance for "intended vs applied" is clear.  I.e. there
>> must not be "config false" leaves in the IETF YANG data models to
>> represent "applied config".
>>
>> But there is no clear guidance for the rest of operational state that
>> isn't applied config.  The other WGs need clear guidance (effectively
>> now) to ensure that they can start publishing models as RFCs.
>>
>>
>>>   If RFC 7223 is an outlier, then we can address it as a special case
>>> (perhaps via the related-state/related-config YANG annotations).  What
>>> do you think?
>>>
>> RW:
>> Personally, I would like one common convention that applies to all IETF
>> YANG models.
>>
>> Idealistically I would like foo and foo-state to be merged because I
>> think that will make the models easier to use and maintain in the long
>> term, but I don't know if we are just too late to go in that direction.
>> 
>> It seems to me that the NETMOD WG really should try to come to a
>> decision quite quickly on this, but I don't know how to encourage that.
>> 
>> A virtual interim on just this topic perhaps?
>>
>>> Next, regarding paths forward (assuming 7223 is not an outlier), I’m
>>> thinking the opposite.  I’m quite sure that we would never merge the
>>> 600+ models with separate subtrees back together again.  So I’m
>>> thinking we 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Ladislav Lhotka]

Robert Wilton  writes:

> On 26/07/2016 21:36, Kent Watsen wrote:
>>
>> 
>>
>>
>> So my thinking is that if we can't merge "foo-state" into "foo" then 
>> instead we should have consistent rules that explicitly state that for 
>> all IETF models "foo" and "foo-state" are separate trees with a 
>> consistent naming convention and structure.  That should hopefully 
>> allow tooling to programmatically relate the two separate trees 
>> together.  It may give a path to allow "foo-state" to be merged into 
>> "foo" in future, but once IETF has standardized 600+ models with 
>> separate sub-trees, I cannot see that they would get merged back 
>> together again.
>>
>> What other alternatives are available?  As a WG we need to tell the 
>> other WGs how the IETF YANG models should be structured.
>>
>> In short, unfortunately I think that we have probably already missed 
>> the opportunity to merge "foo" and "foo-state" subtrees together ...
>>
>> 
>>
>> Firstly, I’m trying to get a sense of how big a problem this 
>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to 
>> counters, not opstate].
>>
> RW:
> By counters, I think that we also mean any config false nodes that don't 
> directly represent "applied configuration", right?  E.g. is an interface 
> operationally up or down.
>
>>I know about RFC 7223, which was done out of consideration for 
>> system-generated interfaces, but how many other such models are there 
>> envisioned to be?
>>
> RW:
> - Any models that augment RFC 7223 and have config false nodes will be 
> impacted.
> - I thought that quite a lot of other IETF models that are in the 
> process of being standardized have a top level split between "foo" and 
> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has 
> this split.  I suspect that all the routing models will be structured 
> similarly.

Correct. One reason is that the core routing model envisions
system-controlled RIBs.

> - Although it is perhaps worth pointing out that I think that the 
> OpenConfig modules effectively have exactly this same issue (e.g. they 
> have a combined interfaces tree keyed by config true leaves), and they 
> pragmatically just ignore the issue of system created interface
> entries.

The NETMOD WG considered this issue quite important in the past.

My impression from the OpState discussion is that we are on the quest of
the philosopher's stone, trying to find a shortcut where none is
possible in general. The long session in Berlin concentrated on the
life-cycle of a single parameter that's somehow configured, then
manipulated, and eventually ends up as operational state. IMO this
is too simplistic, the relationship between configuration and state can
be much more complex. RIB is one example - it combines contributions
from configuration (static routes) and derived state (routing
protocols).

After all, most real devices have some configuration mode and "show"
commands. They are separate even though there is certainly some
relationship between their data.

Lada

>
>>  Is this issue currently blocking models from progressing, or are we 
>> getting ourselves wrapped around a hypothetical?
>>
> RW:
> I think that it is blocking models from progressing.
>
> The current guidance for "intended vs applied" is clear.  I.e. there 
> must not be "config false" leaves in the IETF YANG data models to 
> represent "applied config".
>
> But there is no clear guidance for the rest of operational state that 
> isn't applied config.  The other WGs need clear guidance (effectively 
> now) to ensure that they can start publishing models as RFCs.
>
>
>>   If RFC 7223 is an outlier, then we can address it as a special case 
>> (perhaps via the related-state/related-config YANG annotations).  What 
>> do you think?
>>
> RW:
> Personally, I would like one common convention that applies to all IETF 
> YANG models.
>
> Idealistically I would like foo and foo-state to be merged because I 
> think that will make the models easier to use and maintain in the long 
> term, but I don't know if we are just too late to go in that direction.  
> It seems to me that the NETMOD WG really should try to come to a 
> decision quite quickly on this, but I don't know how to encourage that.  
> A virtual interim on just this topic perhaps?
>
>> Next, regarding paths forward (assuming 7223 is not an outlier), I’m 
>> thinking the opposite.  I’m quite sure that we would never merge the 
>> 600+ models with separate subtrees back together again.  So I’m 
>> thinking we immediately merge foo and foo-state in all active YANG 
>> models (so that the YANG “conceptual” models are stable and good) 
>> *and* then we use your idea to programmatically generate the 
>> “foo-state” tree, presumably only when needed.  This foo-state tree 
>> could be generated offline by tools and provided as a second YANG 
>> module in drafts.  In this way, servers (opstate aware or not) can 
>> advertise if clients can 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

Hi,

*Re: - Any models that augment RFC 7223 and have config false nodes will be
impacted.*

There are many such vendor modules already.
They augment the /interfaces container with config
and the /interfaces-state container with non-config.
Nobody is complaining this is broken, AFAIK.
If you tell them to throw it out and start over, the request
is likely to be ignored.


Andy


On Wed, Jul 27, 2016 at 1:09 PM, Kent Watsen  wrote:

> >> Firstly, I’m trying to get a sense of how big a problem this
>
> >> foo/foo-state thing is.  [Note: by foo-state, I’m only referring
>
> >> to counters, not opstate].
>
>
>
> RW:
> By counters, I think that we also mean any config false nodes that don't
> directly represent "applied configuration", right?  E.g. is an interface
> operationally up or down.
>
> KW:  Yes, the term “counters” is a misnomer.  We are indeed talking about
> regular old config false nodes, whether they be used for counters, gauges,
> or whatever.   It is what the opstate-reqs draft refers to as derived state.
>
>
>
>
>
>
>
> >> I know about RFC 7223, which was done out of consideration
>
> >> for system-generated interfaces, but how many other such models
>
> >> are there envisioned to be?
>
>
>
> RW:
> - Any models that augment RFC 7223 and have config false nodes will be
> impacted.
> - I thought that quite a lot of other IETF models that are in the process
> of being standardized have a top level split between "foo" and
> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has
> this split.  I suspect that all the routing models will be structured
> similarly.
>
>
>
> KW: I also notice that draft-ietf-netmod-routing-cfg does this and, to
> your point, you know the ietf-routing module is intended to be augmented by
> many other modules.  This issue is not easily isolated.
>
>
>
> RW:
> The current guidance for "intended vs applied" is clear.  I.e. there must
> not be "config false" leaves in the IETF YANG data models to represent
> "applied config".  But there is no clear guidance for the rest of
> operational state that isn't applied config.  The other WGs need clear
> guidance (effectively now) to ensure that they can start publishing models
> as RFCs.
>
> KW: indeed.
>
>
>
>
>
> RW:
> Personally, I would like one common convention that applies to all IETF
> YANG models.
>
> Idealistically I would like foo and foo-state to be merged because I think
> that will make the models easier to use and maintain in the long term, but
> I don't know if we are just too late to go in that direction.  It seems to
> me that the NETMOD WG really should try to come to a decision quite quickly
> on this, but I don't know how to encourage that.  A virtual interim on just
> this topic perhaps?
>
> KW: I was going to suggest the same - will discuss with Lou.
>
>
>
>
>
> >> Next, regarding paths forward (assuming 7223 is not an outlier), I’m
>
> >> thinking the opposite.  I’m quite sure that we would never merge the
>
> >> 600+ models with separate subtrees back together again.  So I’m
>
> >> thinking we immediately merge foo and foo-state in all active YANG
>
> >> models (so that the YANG “conceptual” models are stable and good)
>
> >> *and* then we use your idea to programmatically generate the
>
> >> “foo-state” tree, presumably only when needed.  This foo-state tree
>
> >> could be generated offline by tools and provided as a second YANG
>
> >> module in drafts.  In this way, servers (opstate aware or not) can
>
> >> advertise if clients can access the foo-state tree (an opstate-aware
>
> >> server may still advertise it for business reasons, and it can
> ‘deprecate’
>
> >> the tree when no longer needed).   We could do the same without tools
>
> >> today by just using a feature statement on, for instance, the
> interfaces-
>
> >> state container, but I like pushing for tooling upfront so that we’re
>
> >> guaranteed mergeability later.  Thoughts?
>
>
>
>
>
> RW:
> So the generated "foo-state" tree would contain a copy of all config false
> nodes in the YANG schema and a "config false copy" of any config true nodes
> in the YANG schema that are required to provide parental structure for the
> descendant config false nodes.
> - The Xpath expressions would also need to be adjusted, and possibly some
> of those might break (or need to be fixed by hand).
> - Groupings might be a problem, but potentially they could be expanded.
>
>
>
> KW: all good points.
>
> Technically this solution might work, but is it possible to get everyone
> to agree that this is the right direction to go in before we spend time on
> this?
>
> KW: it was just an idea.   I’m trying to strike a balance between having
> the YANG models we want, and what is possible today (while waiting for the
> opstate solution to roll out).
>
>
>
>
>
>
>
> To flesh this idea out just a bit more, let’s say we have module
> “ietf-foo” as follows:
>
>
>
> module ietf-foo {
>
>   namespace “foo-namespace”;
>
>   container foo {

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Kent Watsen]

>> Firstly, I’m trying to get a sense of how big a problem this
>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring
>> to counters, not opstate].

RW:
By counters, I think that we also mean any config false nodes that don't 
directly represent "applied configuration", right?  E.g. is an interface 
operationally up or down.

KW:  Yes, the term “counters” is a misnomer.  We are indeed talking about 
regular old config false nodes, whether they be used for counters, gauges, or 
whatever.   It is what the opstate-reqs draft refers to as derived state.



>> I know about RFC 7223, which was done out of consideration
>> for system-generated interfaces, but how many other such models
>> are there envisioned to be?

RW:
- Any models that augment RFC 7223 and have config false nodes will be impacted.
- I thought that quite a lot of other IETF models that are in the process of 
being standardized have a top level split between "foo" and "foo-state".  E.g 
the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect 
that all the routing models will be structured similarly.

KW: I also notice that draft-ietf-netmod-routing-cfg does this and, to your 
point, you know the ietf-routing module is intended to be augmented by many 
other modules.  This issue is not easily isolated.

RW:
The current guidance for "intended vs applied" is clear.  I.e. there must not 
be "config false" leaves in the IETF YANG data models to represent "applied 
config".  But there is no clear guidance for the rest of operational state that 
isn't applied config.  The other WGs need clear guidance (effectively now) to 
ensure that they can start publishing models as RFCs.

KW: indeed.



RW:
Personally, I would like one common convention that applies to all IETF YANG 
models.

Idealistically I would like foo and foo-state to be merged because I think that 
will make the models easier to use and maintain in the long term, but I don't 
know if we are just too late to go in that direction.  It seems to me that the 
NETMOD WG really should try to come to a decision quite quickly on this, but I 
don't know how to encourage that.  A virtual interim on just this topic perhaps?

KW: I was going to suggest the same - will discuss with Lou.


>> Next, regarding paths forward (assuming 7223 is not an outlier), I’m
>> thinking the opposite.  I’m quite sure that we would never merge the
>> 600+ models with separate subtrees back together again.  So I’m
>> thinking we immediately merge foo and foo-state in all active YANG
>> models (so that the YANG “conceptual” models are stable and good)
>> *and* then we use your idea to programmatically generate the
>> “foo-state” tree, presumably only when needed.  This foo-state tree
>> could be generated offline by tools and provided as a second YANG
>> module in drafts.  In this way, servers (opstate aware or not) can
>> advertise if clients can access the foo-state tree (an opstate-aware
>> server may still advertise it for business reasons, and it can ‘deprecate’
>> the tree when no longer needed).   We could do the same without tools
>> today by just using a feature statement on, for instance, the interfaces-
>> state container, but I like pushing for tooling upfront so that we’re
>> guaranteed mergeability later.  Thoughts?


RW:
So the generated "foo-state" tree would contain a copy of all config false 
nodes in the YANG schema and a "config false copy" of any config true nodes in 
the YANG schema that are required to provide parental structure for the 
descendant config false nodes.
- The Xpath expressions would also need to be adjusted, and possibly some of 
those might break (or need to be fixed by hand).
- Groupings might be a problem, but potentially they could be expanded.

KW: all good points.

Technically this solution might work, but is it possible to get everyone to 
agree that this is the right direction to go in before we spend time on this?

KW: it was just an idea.   I’m trying to strike a balance between having the 
YANG models we want, and what is possible today (while waiting for the opstate 
solution to roll out).



To flesh this idea out just a bit more, let’s say we have module “ietf-foo” as 
follows:

module ietf-foo {
  namespace “foo-namespace”;
  container foo {
list bar {
  key a;
  leaf a {
type string;
  }
  leaf b {
 type int8;
 config false;
  }
   }
  }
}

whereby it’s possible that the system may generate some bars as well.  To 
address this, the module is run through a TBD-tool to generate second module 
foo-state as follows:

module ietf-foo-state {
  namespace “foo-state-namespace”;
  container foo-state {
list bar {
  config false;<-- everything below is config false
  key a;
  leaf a {<-- this config true node kept only because it’s the key
type string;
  }
  leaf b {
 type int8;
 config false;
  }
   }
  }
}

Now, here are the choices:

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

Hi Xufeng,

OK, so perhaps there is even less consistency in the IETF models than I 
thought!


But actually what I am most interested in (from you and others reading 
the Netmod WG alias), is whether you have an opinion on which direction 
we should go.  Even hearing that you don't have an opinion at all is 
useful input :-)


Thanks,
Rob


On 27/07/2016 19:22, Xufeng Liu wrote:


The assumption of “I suspect that all the routing models will be 
structured similarly” is not correct. Very few models in routing area 
structure this way.


Regards,

- Xufeng

*From:*netmod [mailto:netmod-boun...@ietf.org] *On Behalf Of *Robert 
Wilton

*Sent:* Wednesday, July 27, 2016 1:05 PM
*To:* Kent Watsen <kwat...@juniper.net>; netmod WG <netmod@ietf.org>
*Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF 
YANG Model Structure


On 26/07/2016 21:36, Kent Watsen wrote:




So my thinking is that if we can't merge "foo-state" into "foo"
then instead we should have consistent rules that explicitly state
that for all IETF models "foo" and "foo-state" are separate trees
with a consistent naming convention and structure.  That should
hopefully allow tooling to programmatically relate the two
separate trees together.  It may give a path to allow "foo-state"
to be merged into "foo" in future, but once IETF has standardized
600+ models with separate sub-trees, I cannot see that they would
get merged back together again.

What other alternatives are available?  As a WG we need to tell
the other WGs how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already
missed the opportunity to merge "foo" and "foo-state" subtrees
together ...




Firstly, I’m trying to get a sense of how big a problem this
foo/foo-state thing is. [Note: by foo-state, I’m only referring to
counters, not opstate].

RW:
By counters, I think that we also mean any config false nodes that 
don't directly represent "applied configuration", right?  E.g. is an 
interface operationally up or down.



   I know about RFC 7223, which was done out of consideration for
system-generated interfaces, but how many other such models are
there envisioned to be?

RW:
- Any models that augment RFC 7223 and have config false nodes will be 
impacted.
- I thought that quite a lot of other IETF models that are in the 
process of being standardized have a top level split between "foo" and 
"foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) 
has this split.  I suspect that all the routing models will be 
structured similarly.
- Although it is perhaps worth pointing out that I think that the 
OpenConfig modules effectively have exactly this same issue (e.g. they 
have a combined interfaces tree keyed by config true leaves), and they 
pragmatically just ignore the issue of system created interface entries.



 Is this issue currently blocking models from progressing, or are
we getting ourselves wrapped around a hypothetical?

RW:
I think that it is blocking models from progressing.

The current guidance for "intended vs applied" is clear. I.e. there 
must not be "config false" leaves in the IETF YANG data models to 
represent "applied config".


But there is no clear guidance for the rest of operational state that 
isn't applied config.  The other WGs need clear guidance (effectively 
now) to ensure that they can start publishing models as RFCs.




  If RFC 7223 is an outlier, then we can address it as a special
case (perhaps via the related-state/related-config YANG
annotations).  What do you think?

RW:
Personally, I would like one common convention that applies to all 
IETF YANG models.


Idealistically I would like foo and foo-state to be merged because I 
think that will make the models easier to use and maintain in the long 
term, but I don't know if we are just too late to go in that 
direction.  It seems to me that the NETMOD WG really should try to 
come to a decision quite quickly on this, but I don't know how to 
encourage that.  A virtual interim on just this topic perhaps?



Next, regarding paths forward (assuming 7223 is not an outlier),
I’m thinking the opposite.  I’m quite sure that we would never
merge the 600+ models with separate subtrees back together again. 
So I’m thinking we immediately merge foo and foo-state in all

active YANG models (so that the YANG “conceptual” models are
stable and good) *and* then we use your idea to programmatically
generate the “foo-state” tree, presumably only when needed.  This
foo-state tree could be generated offline by tools and provided as
a second YANG module in drafts.  In this way, servers (opstate
aware or not) can advertise if clients can acces

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Mahesh Jethanandani 
<mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>
Date: Wednesday, July 27, 2016 at 9:07 PM
To: Xufeng Liu <xufeng.liu.i...@gmail.com<mailto:xufeng.liu.i...@gmail.com>>
Cc: netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure

Robert mentions IS-IS, and if I look at OSPF, I see a clear separation of rw 
and ro nodes.

Right - and this separation is based on the routing and routing-state split in 
the ietf-routing-cfg model. In general, ietf-routing-cfg specifies that all 
control plane protocol YANG models should adapt this structure. Anyone who 
thinks collapsing all the models one config/state tree is simply a matter of 
moving a few counters should taking a better look at the existing drafts. I 
outlined the options in the E-mail thread prior to IETF 96.  Now, with the 
context of IETF 96 behind us, I believe more NETMOD participants will 
understand the options. To review the options specified in the previous E-mail 
thread.

   1. Do nothing - allow them proceed as they are with multiple ways of
   representing the applied configuration. This would provide visibility to
   the data independent of whether or not the device supported the revised
   data-stores supporting implicit retrieval of the applied configuration.
   2. Prune out the redundant data nodes except those required as list
keys, etc, since they can be obtained from the applied state data store.
  3. #2 plus collapse the config (read-write) and  system-state
   (read-only) into common containers. No more branching of
   -config and -state at the top level of the model.

Prior to IETF 96, I don’t believe we had selected a direction. However, I 
believe we agreed on option #1 in order to allow the publication of these 
models within the next year. We’d still be able to avail the benefits of 
applied vs intended configuration on network devices supporting these data 
stores.

Thanks,
Acee





On Jul 27, 2016, at 11:22 AM, Xufeng Liu 
<xufeng.liu.i...@gmail.com<mailto:xufeng.liu.i...@gmail.com>> wrote:

The assumption of “I suspect that all the routing models will be structured 
similarly” is not correct. Very few models in routing area structure this way.

Regards,

- Xufeng

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Wednesday, July 27, 2016 1:05 PM
To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>; netmod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure





On 26/07/2016 21:36, Kent Watsen wrote:



So my thinking is that if we can't merge "foo-state" into "foo" then instead we 
should have consistent rules that explicitly state that for all IETF models 
"foo" and "foo-state" are separate trees with a consistent naming convention 
and structure.  That should hopefully allow tooling to programmatically relate 
the two separate trees together.  It may give a path to allow "foo-state" to be 
merged into "foo" in future, but once IETF has standardized 600+ models with 
separate sub-trees, I cannot see that they would get merged back together again.

What other alternatives are available?  As a WG we need to tell the other WGs 
how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...





Firstly, I’m trying to get a sense of how big a problem this foo/foo-state 
thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].
RW:
By counters, I think that we also mean any config false nodes that don't 
directly represent "applied configuration", right?  E.g. is an interface 
operationally up or down.


   I know about RFC 7223, which was done out of consideration for 
system-generated interfaces, but how many other such models are there 
envisioned to be?
RW:
- Any models that augment RFC 7223 and have config false nodes will be impacted.
- I thought that quite a lot of other IETF models that are in the process of 
being standardized have a top level split between "foo" and "foo-state".  E.g 
the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect 
that all the routing models will be structured similarly.
- Although it is perhaps worth pointing out that I think that the OpenConfig 
modules effectively have exactly this same issue (e.g. they have a combined 
interfaces tree keyed by config true leaves), and they pragmatically just 
ignore the issue of system created interface entries.


 Is this issue currently blocking mode

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Mahesh Jethanandani]

Robert mentions IS-IS, and if I look at OSPF, I see a clear separation of rw 
and ro nodes. 

> On Jul 27, 2016, at 11:22 AM, Xufeng Liu <xufeng.liu.i...@gmail.com> wrote:
> 
> The assumption of “I suspect that all the routing models will be structured 
> similarly” is not correct. Very few models in routing area structure this way.
>  
> Regards,
>  
> - Xufeng
>  
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
> Sent: Wednesday, July 27, 2016 1:05 PM
> To: Kent Watsen <kwat...@juniper.net>; netmod WG <netmod@ietf.org>
> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG 
> Model Structure
>  
>  
> 
>  
> On 26/07/2016 21:36, Kent Watsen wrote:
>>  
>> 
>> 
>> So my thinking is that if we can't merge "foo-state" into "foo" then instead 
>> we should have consistent rules that explicitly state that for all IETF 
>> models "foo" and "foo-state" are separate trees with a consistent naming 
>> convention and structure.  That should hopefully allow tooling to 
>> programmatically relate the two separate trees together.  It may give a path 
>> to allow "foo-state" to be merged into "foo" in future, but once IETF has 
>> standardized 600+ models with separate sub-trees, I cannot see that they 
>> would get merged back together again.
>> 
>> What other alternatives are available?  As a WG we need to tell the other 
>> WGs how the IETF YANG models should be structured.
>> 
>> In short, unfortunately I think that we have probably already missed the 
>> opportunity to merge "foo" and "foo-state" subtrees together ...
>> 
>> 
>> 
>>  
>>  
>> Firstly, I’m trying to get a sense of how big a problem this foo/foo-state 
>> thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].
> RW:
> By counters, I think that we also mean any config false nodes that don't 
> directly represent "applied configuration", right?  E.g. is an interface 
> operationally up or down.
> 
> 
>>I know about RFC 7223, which was done out of consideration for 
>> system-generated interfaces, but how many other such models are there 
>> envisioned to be?
> RW:
> - Any models that augment RFC 7223 and have config false nodes will be 
> impacted.
> - I thought that quite a lot of other IETF models that are in the process of 
> being standardized have a top level split between "foo" and "foo-state".  E.g 
> the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect 
> that all the routing models will be structured similarly.
> - Although it is perhaps worth pointing out that I think that the OpenConfig 
> modules effectively have exactly this same issue (e.g. they have a combined 
> interfaces tree keyed by config true leaves), and they pragmatically just 
> ignore the issue of system created interface entries.
> 
> 
>>  Is this issue currently blocking models from progressing, or are we getting 
>> ourselves wrapped around a hypothetical?
> RW:
> I think that it is blocking models from progressing.
> 
> The current guidance for "intended vs applied" is clear.  I.e. there must not 
> be "config false" leaves in the IETF YANG data models to represent "applied 
> config".
> 
> But there is no clear guidance for the rest of operational state that isn't 
> applied config.  The other WGs need clear guidance (effectively now) to 
> ensure that they can start publishing models as RFCs.
> 
> 
> 
>>   If RFC 7223 is an outlier, then we can address it as a special case 
>> (perhaps via the related-state/related-config YANG annotations).  What do 
>> you think?
> RW:
> Personally, I would like one common convention that applies to all IETF YANG 
> models.
> 
> Idealistically I would like foo and foo-state to be merged because I think 
> that will make the models easier to use and maintain in the long term, but I 
> don't know if we are just too late to go in that direction.  It seems to me 
> that the NETMOD WG really should try to come to a decision quite quickly on 
> this, but I don't know how to encourage that.  A virtual interim on just this 
> topic perhaps?
> 
> 
>>  
>> Next, regarding paths forward (assuming 7223 is not an outlier), I’m 
>> thinking the opposite.  I’m quite sure that we would never merge the 600+ 
>> models with separate subtrees back together again.  So I’m thinking we 
>> immediately merge foo and foo-state in all active YANG models (so that the 
>> YANG “conceptu

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Xufeng Liu]

The assumption of “I suspect that all the routing models will be structured 
similarly” is not correct. Very few models in routing area structure this way.

 

Regards,

 

- Xufeng

 

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Wednesday, July 27, 2016 1:05 PM
To: Kent Watsen <kwat...@juniper.net>; netmod WG <netmod@ietf.org>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure

 

 

 

On 26/07/2016 21:36, Kent Watsen wrote:

 




So my thinking is that if we can't merge "foo-state" into "foo" then instead we 
should have consistent rules that explicitly state that for all IETF models 
"foo" and "foo-state" are separate trees with a consistent naming convention 
and structure.  That should hopefully allow tooling to programmatically relate 
the two separate trees together.  It may give a path to allow "foo-state" to be 
merged into "foo" in future, but once IETF has standardized 600+ models with 
separate sub-trees, I cannot see that they would get merged back together again.

What other alternatives are available?  As a WG we need to tell the other WGs 
how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...






 

 

Firstly, I’m trying to get a sense of how big a problem this foo/foo-state 
thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].

RW:
By counters, I think that we also mean any config false nodes that don't 
directly represent "applied configuration", right?  E.g. is an interface 
operationally up or down.




   I know about RFC 7223, which was done out of consideration for 
system-generated interfaces, but how many other such models are there 
envisioned to be?

RW:
- Any models that augment RFC 7223 and have config false nodes will be impacted.
- I thought that quite a lot of other IETF models that are in the process of 
being standardized have a top level split between "foo" and "foo-state".  E.g 
the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect 
that all the routing models will be structured similarly.
- Although it is perhaps worth pointing out that I think that the OpenConfig 
modules effectively have exactly this same issue (e.g. they have a combined 
interfaces tree keyed by config true leaves), and they pragmatically just 
ignore the issue of system created interface entries.




 Is this issue currently blocking models from progressing, or are we getting 
ourselves wrapped around a hypothetical?

RW:
I think that it is blocking models from progressing.

The current guidance for "intended vs applied" is clear.  I.e. there must not 
be "config false" leaves in the IETF YANG data models to represent "applied 
config".

But there is no clear guidance for the rest of operational state that isn't 
applied config.  The other WGs need clear guidance (effectively now) to ensure 
that they can start publishing models as RFCs.





  If RFC 7223 is an outlier, then we can address it as a special case (perhaps 
via the related-state/related-config YANG annotations).  What do you think?

RW:
Personally, I would like one common convention that applies to all IETF YANG 
models.

Idealistically I would like foo and foo-state to be merged because I think that 
will make the models easier to use and maintain in the long term, but I don't 
know if we are just too late to go in that direction.  It seems to me that the 
NETMOD WG really should try to come to a decision quite quickly on this, but I 
don't know how to encourage that.  A virtual interim on just this topic perhaps?




 

Next, regarding paths forward (assuming 7223 is not an outlier), I’m thinking 
the opposite.  I’m quite sure that we would never merge the 600+ models with 
separate subtrees back together again.  So I’m thinking we immediately merge 
foo and foo-state in all active YANG models (so that the YANG “conceptual” 
models are stable and good) *and* then we use your idea to programmatically 
generate the “foo-state” tree, presumably only when needed.  This foo-state 
tree could be generated offline by tools and provided as a second YANG module 
in drafts.  In this way, servers (opstate aware or not) can advertise if 
clients can access the foo-state tree (an opstate-aware server may still 
advertise it for business reasons, and it can ‘deprecate’ the tree when no 
longer needed).   We could do the same without tools today by just using a 
feature statement on, for instance, the interfaces-state container, but I like 
pushing for tooling upfront so that we’re guaranteed mergeability later.  
Thoughts?

RW:
So the generated "foo-state" tree would contain a copy of all config false 
nodes in the YANG sc

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 26/07/2016 21:36, Kent Watsen wrote:





So my thinking is that if we can't merge "foo-state" into "foo" then 
instead we should have consistent rules that explicitly state that for 
all IETF models "foo" and "foo-state" are separate trees with a 
consistent naming convention and structure.  That should hopefully 
allow tooling to programmatically relate the two separate trees 
together.  It may give a path to allow "foo-state" to be merged into 
"foo" in future, but once IETF has standardized 600+ models with 
separate sub-trees, I cannot see that they would get merged back 
together again.


What other alternatives are available?  As a WG we need to tell the 
other WGs how the IETF YANG models should be structured.


In short, unfortunately I think that we have probably already missed 
the opportunity to merge "foo" and "foo-state" subtrees together ...




Firstly, I’m trying to get a sense of how big a problem this 
foo/foo-state thing is.  [Note: by foo-state, I’m only referring to 
counters, not opstate].



RW:
By counters, I think that we also mean any config false nodes that don't 
directly represent "applied configuration", right?  E.g. is an interface 
operationally up or down.


   I know about RFC 7223, which was done out of consideration for 
system-generated interfaces, but how many other such models are there 
envisioned to be?



RW:
- Any models that augment RFC 7223 and have config false nodes will be 
impacted.
- I thought that quite a lot of other IETF models that are in the 
process of being standardized have a top level split between "foo" and 
"foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has 
this split.  I suspect that all the routing models will be structured 
similarly.
- Although it is perhaps worth pointing out that I think that the 
OpenConfig modules effectively have exactly this same issue (e.g. they 
have a combined interfaces tree keyed by config true leaves), and they 
pragmatically just ignore the issue of system created interface entries.


 Is this issue currently blocking models from progressing, or are we 
getting ourselves wrapped around a hypothetical?



RW:
I think that it is blocking models from progressing.

The current guidance for "intended vs applied" is clear.  I.e. there 
must not be "config false" leaves in the IETF YANG data models to 
represent "applied config".


But there is no clear guidance for the rest of operational state that 
isn't applied config.  The other WGs need clear guidance (effectively 
now) to ensure that they can start publishing models as RFCs.



  If RFC 7223 is an outlier, then we can address it as a special case 
(perhaps via the related-state/related-config YANG annotations).  What 
do you think?



RW:
Personally, I would like one common convention that applies to all IETF 
YANG models.


Idealistically I would like foo and foo-state to be merged because I 
think that will make the models easier to use and maintain in the long 
term, but I don't know if we are just too late to go in that direction.  
It seems to me that the NETMOD WG really should try to come to a 
decision quite quickly on this, but I don't know how to encourage that.  
A virtual interim on just this topic perhaps?


Next, regarding paths forward (assuming 7223 is not an outlier), I’m 
thinking the opposite.  I’m quite sure that we would never merge the 
600+ models with separate subtrees back together again.  So I’m 
thinking we immediately merge foo and foo-state in all active YANG 
models (so that the YANG “conceptual” models are stable and good) 
*and* then we use your idea to programmatically generate the 
“foo-state” tree, presumably only when needed.  This foo-state tree 
could be generated offline by tools and provided as a second YANG 
module in drafts.  In this way, servers (opstate aware or not) can 
advertise if clients can access the foo-state tree (an opstate-aware 
server may still advertise it for business reasons, and it can 
‘deprecate’ the tree when no longer needed).   We could do the same 
without tools today by just using a feature statement on, for 
instance, the interfaces-state container, but I like pushing for 
tooling upfront so that we’re guaranteed mergeability later.  Thoughts?



RW:
So the generated "foo-state" tree would contain a copy of all config 
false nodes in the YANG schema and a "config false copy" of any config 
true nodes in the YANG schema that are required to provide parental 
structure for the descendant config false nodes.
- The Xpath expressions would also need to be adjusted, and possibly 
some of those might break (or need to be fixed by hand).

- Groupings might be a problem, but potentially they could be expanded.

Technically this solution might work, but is it possible to get everyone 
to agree that this is the right direction to go in before we spend time 
on this?


Thanks,
Rob



Kent // as a contributor



___
netmod mailing list

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Date: Wednesday, July 27, 2016 at 12:19 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Robert Wilton -X 
(rwilton - ENSOFT LIMITED at Cisco)" 
<rwil...@cisco.com<mailto:rwil...@cisco.com>>, netmod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure


There are a number of issues here. The first is that you are now depending on 
the separate applied state data store being implemented on every network device 
if you are going to eliminate the duplication of actual values in the OpState. 
The second is that OpsState is MUCH more than just counters. For example, for 
routing protocols will many times include a local RIB. The third is that it is 
a big change for these draft models and, if you have been following the 
discussion on the list, you should know that this option is not universally 
accepted (reference the E-mail thread I started with options before IETF 96).



But I specifically called out that I was only talking about counters (e.g., 
7223) and not applied config.   For applied config, I think that we’ll wait for 
the opstate solution, per decision ‘B’.

Why would we consider handling counters differently from other operational 
state that is not part of applied config???

Acee




Regardless, let’s not lose focus on my first question about how prevalent an 
issue this is.  If 7223 is a singularity, then we should stop worrying about 
this as a general problem.  I’d like to understand how big this box is before 
jumping into it.

We’ve had config false leafs mixed in config true trees forever.  Only when 
there are system-generated values or values whose lifetimes extend past the 
lifetime of the config true object is there an issue.   This isn’t a new thing, 
nor an applied config thing, but it can be nicely solved by the opstate 
solution.  The only question is what we do in the interim.

Kent  // as a contributor


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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Kent Watsen]

There are a number of issues here. The first is that you are now depending on 
the separate applied state data store being implemented on every network device 
if you are going to eliminate the duplication of actual values in the OpState. 
The second is that OpsState is MUCH more than just counters. For example, for 
routing protocols will many times include a local RIB. The third is that it is 
a big change for these draft models and, if you have been following the 
discussion on the list, you should know that this option is not universally 
accepted (reference the E-mail thread I started with options before IETF 96).



But I specifically called out that I was only talking about counters (e.g., 
7223) and not applied config.   For applied config, I think that we’ll wait for 
the opstate solution, per decision ‘B’.

Regardless, let’s not lose focus on my first question about how prevalent an 
issue this is.  If 7223 is a singularity, then we should stop worrying about 
this as a general problem.  I’d like to understand how big this box is before 
jumping into it.

We’ve had config false leafs mixed in config true trees forever.  Only when 
there are system-generated values or values whose lifetimes extend past the 
lifetime of the config true object is there an issue.   This isn’t a new thing, 
nor an applied config thing, but it can be nicely solved by the opstate 
solution.  The only question is what we do in the interim.

Kent  // as a contributor


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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Date: Tuesday, July 26, 2016 at 10:36 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
<rwil...@cisco.com<mailto:rwil...@cisco.com>>, netmod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure




So my thinking is that if we can't merge "foo-state" into "foo" then instead we 
should have consistent rules that explicitly state that for all IETF models 
"foo" and "foo-state" are separate trees with a consistent naming convention 
and structure.  That should hopefully allow tooling to programmatically relate 
the two separate trees together.  It may give a path to allow "foo-state" to be 
merged into "foo" in future, but once IETF has standardized 600+ models with 
separate sub-trees, I cannot see that they would get merged back together again.

What other alternatives are available?  As a WG we need to tell the other WGs 
how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...




Firstly, I’m trying to get a sense of how big a problem this foo/foo-state 
thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].   
I know about RFC 7223, which was done out of consideration for system-generated 
interfaces, but how many other such models are there envisioned to be?  Is this 
issue currently blocking models from progressing, or are we getting ourselves 
wrapped around a hypothetical?  If RFC 7223 is an outlier, then we can address 
it as a special case (perhaps via the related-state/related-config YANG 
annotations).  What do you think?

Next, regarding paths forward (assuming 7223 is not an outlier), I’m thinking 
the opposite.  I’m quite sure that we would never merge the 600+ models with 
separate subtrees back together again.  So I’m thinking we immediately merge 
foo and foo-state in all active YANG models (so that the YANG “conceptual” 
models are stable and good) *and* then we use your idea to programmatically 
generate the “foo-state” tree, presumably only when needed.  This foo-state 
tree could be generated offline by tools and provided as a second YANG module 
in drafts.  In this way, servers (opstate aware or not) can advertise if 
clients can access the foo-state tree (an opstate-aware server may still 
advertise it for business reasons, and it can ‘deprecate’ the tree when no 
longer needed).   We could do the same without tools today by just using a 
feature statement on, for instance, the interfaces-state container, but I like 
pushing for tooling upfront so that we’re guaranteed mergeability later.  
Thoughts?

There are a number of issues here. The first is that you are now depending on 
the separate applied state data store being implemented on every network device 
if you are going to eliminate the duplication of actual values in the OpState. 
The second is that OpsState is MUCH more than just counters. For example, for 
routing protocols will many times include a local RIB. The third is that it is 
a big change for these draft models and, if you have been following the 
discussion on the list, you should know that this option is not universally 
accepted (reference the E-mail thread I started with options before IETF 96).

Acee







Kent // as a contributor



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Kent Watsen]

So my thinking is that if we can't merge "foo-state" into "foo" then instead we 
should have consistent rules that explicitly state that for all IETF models 
"foo" and "foo-state" are separate trees with a consistent naming convention 
and structure.  That should hopefully allow tooling to programmatically relate 
the two separate trees together.  It may give a path to allow "foo-state" to be 
merged into "foo" in future, but once IETF has standardized 600+ models with 
separate sub-trees, I cannot see that they would get merged back together again.

What other alternatives are available?  As a WG we need to tell the other WGs 
how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...




Firstly, I’m trying to get a sense of how big a problem this foo/foo-state 
thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].   
I know about RFC 7223, which was done out of consideration for system-generated 
interfaces, but how many other such models are there envisioned to be?  Is this 
issue currently blocking models from progressing, or are we getting ourselves 
wrapped around a hypothetical?  If RFC 7223 is an outlier, then we can address 
it as a special case (perhaps via the related-state/related-config YANG 
annotations).  What do you think?

Next, regarding paths forward (assuming 7223 is not an outlier), I’m thinking 
the opposite.  I’m quite sure that we would never merge the 600+ models with 
separate subtrees back together again.  So I’m thinking we immediately merge 
foo and foo-state in all active YANG models (so that the YANG “conceptual” 
models are stable and good) *and* then we use your idea to programmatically 
generate the “foo-state” tree, presumably only when needed.  This foo-state 
tree could be generated offline by tools and provided as a second YANG module 
in drafts.  In this way, servers (opstate aware or not) can advertise if 
clients can access the foo-state tree (an opstate-aware server may still 
advertise it for business reasons, and it can ‘deprecate’ the tree when no 
longer needed).   We could do the same without tools today by just using a 
feature statement on, for instance, the interfaces-state container, but I like 
pushing for tooling upfront so that we’re guaranteed mergeability later.  
Thoughts?

Kent // as a contributor



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Rob Shakir]

> On 26 Jul, 2016, at 9:52 AM, Robert Wilton  wrote:
> 
> What other alternatives are available?  As a WG we need to tell the other WGs 
> how the IETF YANG models should be structured.

An interested observer could note that the convention that was described in the 
initial OpenConfig proposal had objections to it based on the fact that it 
required models to be written in a certain way. Although this way is 
prescriptive, and could be observed to cause some pain to the model writer 
(albeit limited), it has a number of advantages in terms of being very 
deterministic as to how the model should be structured, allowing leaves to be 
easily related to each other, and can be programmatically verified.

It seems to me like the working group is trying to have its cake and eat it — 
that is to say, get these advantages without being prescriptive to the model 
writer. It is not clear to me that this is actually achievable.

r, An Interested Observer.___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 25/07/2016 21:03, Kent Watsen wrote:


>> Juergen writes:

>> Bottom line: I think we should continue to follow the model used by

>> the ietf-interfaces model and the ietf-ip model until we have a better

>> solution in place (and subsequently we can deprecate objects that

>> became redundant).

>

> Rob writes:

> This is pretty much what I'm trying to say as well, but in a stronger

> way.  I.e. mandating that all IETF YANG models MUST follow this

> structure, and split config and state into two top level trees.

I agree that a revised datastore model plus matching solutions can

eliminate the need for the interfaces-state convention.  But this would

only apply to client/servers that have been updated to grok the new

approach - right?


RW: Yes.


  If these nodes are subsequently deprecated, or new

modules are created assuming the new approach from the get go, are

we leaving the legacy client/servers behind with no way to get, for

instance, the operational status for system-created interfaces?


RW: Yes.

When chatting to Chris Hopps, we had come to conclusion that this may 
not pragmatically matter, but it would still be a violation of the RFCs ...


So my thinking is that if we can't merge "foo-state" into "foo" then 
instead we should have consistent rules that explicitly state that for 
all IETF models "foo" and "foo-state" are separate trees with a 
consistent naming convention and structure.  That should hopefully allow 
tooling to programmatically relate the two separate trees together.  It 
may give a path to allow "foo-state" to be merged into "foo" in future, 
but once IETF has standardized 600+ models with separate sub-trees, I 
cannot see that they would get merged back together again.


What other alternatives are available?  As a WG we need to tell the 
other WGs how the IETF YANG models should be structured.


In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...


Rob


It seems that we need to make a hard cutover sooner or later...

Kent  // as a contributor



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Kent Watsen]

>> Juergen writes:
>> Bottom line: I think we should continue to follow the model used by
>> the ietf-interfaces model and the ietf-ip model until we have a better
>> solution in place (and subsequently we can deprecate objects that
>> became redundant).
>
> Rob writes:
> This is pretty much what I'm trying to say as well, but in a stronger
> way.  I.e. mandating that all IETF YANG models MUST follow this
> structure, and split config and state into two top level trees.


I agree that a revised datastore model plus matching solutions can
eliminate the need for the interfaces-state convention.  But this would
only apply to client/servers that have been updated to grok the new
approach - right?  If these nodes are subsequently deprecated, or new
modules are created assuming the new approach from the get go, are
we leaving the legacy client/servers behind with no way to get, for
instance, the operational status for system-created interfaces?

It seems that we need to make a hard cutover sooner or later...

Kent  // as a contributor

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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 21/07/2016 19:40, Juergen Schoenwaelder wrote:

On Thu, Jul 21, 2016 at 06:39:29PM +0200, Robert Wilton wrote:

Hi,

So after the various meetings and discussions this week, I think that the
most important thing for IETF to do is to publish reviewed YANG models
quickly, with the understanding that it is better to publish imperfect
models than to end up not publishing any models at all.  This is with the
understanding that these models could be fixed by subsequent RFCs if
required.

So, I effectively support Acee's solution (2).  But to state this more
precisely, I would suggest that the specific guidance should be:
1) IETF Models MUST NOT have a split for applied configuration leaves.  All
IETF models that have not been turned into RFCs must be modified to remove
any applied configuration nodes.  Any models that have this convention in
RFCs should be revised to follow a consistent intended/applied convention
for IETF models.  [The justification here is that IETF standard models have
to be able to assume that the applied configuration will be available via a
separate applied configuration (or operational state) datastore or
equivalent mechanism.]

Are there any published models that have "applied configuration
nodes"?
I'm not 100% sure.  I thought that there was a BGP model that was about 
to be published as an RFC standard that contains intended vs applied 
configuration split.  Possibly draft-ietf-idr-bgp-model-02.



  What is actually an "applied configuration node"?
A config false node written in the schema with the sole purpose of 
indicating whether of not the configuration has been applied on the device.


For example, looking at the "bgp-common-neighbor-group-timers-config" 
grouping in draft-ietf-idr-bgp-model-02, then the uses statement 
instantiates it twice for the BGP peer group timers, once under a 
"config" (config true) container to hold the configuration, and also 
under "state" (config false) to solely represent whether the 
configuration has been applied.



  Perhaps an
example helps: Are you trying to suggest that

   /if:interfaces-state/if:interface/ipv4/address/ip

is now made illegal and we have right now no way to represent
operationally used IP addresses? That sounds somewhat broken to me.
No, I'm not suggesting that.  I don't see that node as specifically only 
indicating whether the IP address configuration is applied, but instead 
represents the actual IP address in use by the system.






2) All IETF Models MUST put "derived state and statistics" into a separate
namespace from the configuration (i.e. top level "feature" and
"feature-state").  The two trees must be as structurally similar as
possible, sharing the same paths, node names (except the top level node),
using the same lists keys where appropriate, etc.*

Not sure what exactly drived state is.

From draft-ietf-netmod-opstate-reqs-04:

   Derived State:  This data represents information which is generated
   as part of the server's own interactions.  For example, derived
   state may consist of the results of protocol interactions (the
   negotiated duplex state of an Ethernet link), statistics (such as
   message queue depth), or counters (such as packet input or output
   bytes).


But in essence, I mean all config false nodes that are not "applied 
configuration nodes" (as per my example above).



  And even then, why MUST derived
state and statistics be in a separate tree?
My aim is to make the structure of the models consistent and 
predictable, with the specific aim of making it easier for tooling. If 
some IETF models are going to split configuration and state into 
separate trees (e.g. RFC 7723), then I'm suggesting that all IETF 
modules must have same structure.




  And can we please avoid
'feature' and 'feature-state' since YANG uses the term 'feature' in a
very different sense.

Yes, OK.




3) Both of these rules should be written into rfc6087bis.  We should then
get this guidelines document finished as quickly as possible at the highest
priority, and use that as the definitive guideline for the modules that the
working groups are working on.

* Note, I chose this option not because I think that it is elegant (because
I don't) but because it seems to me that it is the only pragmatically option
that we have available.  The alternatives appear to be: (i) we wait another
year before publishing any models (if ever), or (ii) we publish models that
no-one can use today without violating the existing RFCs, or (iii) we end up
with a hybrid mess without any consistency.

I do not see how the proposed rules achieve the goals you stated. Again,
examples may help:

   /if:interfaces-state/if:interface/ipv4/address/ip

This can be implemented today.




  It may not be necessary anymore some
time in the future if we have a revised datastore model plus matching
solutions. The upgrade path from this is, however, extremly simple:
We change the status of the definition of this object to 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Juergen Schoenwaelder]

On Thu, Jul 21, 2016 at 06:39:29PM +0200, Robert Wilton wrote:
> Hi,
> 
> So after the various meetings and discussions this week, I think that the
> most important thing for IETF to do is to publish reviewed YANG models
> quickly, with the understanding that it is better to publish imperfect
> models than to end up not publishing any models at all.  This is with the
> understanding that these models could be fixed by subsequent RFCs if
> required.
> 
> So, I effectively support Acee's solution (2).  But to state this more
> precisely, I would suggest that the specific guidance should be:
> 1) IETF Models MUST NOT have a split for applied configuration leaves.  All
> IETF models that have not been turned into RFCs must be modified to remove
> any applied configuration nodes.  Any models that have this convention in
> RFCs should be revised to follow a consistent intended/applied convention
> for IETF models.  [The justification here is that IETF standard models have
> to be able to assume that the applied configuration will be available via a
> separate applied configuration (or operational state) datastore or
> equivalent mechanism.]

Are there any published models that have "applied configuration
nodes"?  What is actually an "applied configuration node"? Perhaps an
example helps: Are you trying to suggest that

  /if:interfaces-state/if:interface/ipv4/address/ip

is now made illegal and we have right now no way to represent
operationally used IP addresses? That sounds somewhat broken to me.

> 2) All IETF Models MUST put "derived state and statistics" into a separate
> namespace from the configuration (i.e. top level "feature" and
> "feature-state").  The two trees must be as structurally similar as
> possible, sharing the same paths, node names (except the top level node),
> using the same lists keys where appropriate, etc.*

Not sure what exactly drived state is. And even then, why MUST derived
state and statistics be in a separate tree? And can we please avoid
'feature' and 'feature-state' since YANG uses the term 'feature' in a
very different sense.

> 3) Both of these rules should be written into rfc6087bis.  We should then
> get this guidelines document finished as quickly as possible at the highest
> priority, and use that as the definitive guideline for the modules that the
> working groups are working on.
> 
> * Note, I chose this option not because I think that it is elegant (because
> I don't) but because it seems to me that it is the only pragmatically option
> that we have available.  The alternatives appear to be: (i) we wait another
> year before publishing any models (if ever), or (ii) we publish models that
> no-one can use today without violating the existing RFCs, or (iii) we end up
> with a hybrid mess without any consistency.

I do not see how the proposed rules achieve the goals you stated. Again,
examples may help:

  /if:interfaces-state/if:interface/ipv4/address/ip

This can be implemented today. It may not be necessary anymore some
time in the future if we have a revised datastore model plus matching
solutions. The upgrade path from this is, however, extremly simple:
We change the status of the definition of this object to deprecated.

Bottom line: I think we should continue to follow the model used by
the ietf-interfaces model and the ietf-ip model until we have a better
solution in place (and subsequently we can deprecate objects that
became redundant).

/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] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

Hi,

So after the various meetings and discussions this week, I think that 
the most important thing for IETF to do is to publish reviewed YANG 
models quickly, with the understanding that it is better to publish 
imperfect models than to end up not publishing any models at all.  This 
is with the understanding that these models could be fixed by subsequent 
RFCs if required.


So, I effectively support Acee's solution (2).  But to state this more 
precisely, I would suggest that the specific guidance should be:
1) IETF Models MUST NOT have a split for applied configuration leaves.  
All IETF models that have not been turned into RFCs must be modified to 
remove any applied configuration nodes.  Any models that have this 
convention in RFCs should be revised to follow a consistent 
intended/applied convention for IETF models.  [The justification here is 
that IETF standard models have to be able to assume that the applied 
configuration will be available via a separate applied configuration (or 
operational state) datastore or equivalent mechanism.]
2) All IETF Models MUST put "derived state and statistics" into a 
separate namespace from the configuration (i.e. top level "feature" and 
"feature-state").  The two trees must be as structurally similar as 
possible, sharing the same paths, node names (except the top level 
node), using the same lists keys where appropriate, etc.*
3) Both of these rules should be written into rfc6087bis.  We should 
then get this guidelines document finished as quickly as possible at the 
highest priority, and use that as the definitive guideline for the 
modules that the working groups are working on.


* Note, I chose this option not because I think that it is elegant 
(because I don't) but because it seems to me that it is the only 
pragmatically option that we have available.  The alternatives appear to 
be: (i) we wait another year before publishing any models (if ever), or 
(ii) we publish models that no-one can use today without violating the 
existing RFCs, or (iii) we end up with a hybrid mess without any 
consistency.


Thanks,
Rob


On 11/07/2016 18:36, Acee Lindem (acee) wrote:

While there are details to be worked out between the two data stores
models (as indicated below), we now have implicit modeling of applied
configuration. Existing models (both standard and draft) do not take this
into consideration and, consequently, much of the state that is modeled
explicitly represents the application configuration. For the RFC models,
it probably doesn’t make much sense to redo them (unless they are being
reworked for other reasons). This still leaves the existing WG draft
models for which we have basically 3 options:

   1. Do nothing - allow them proceed as they are with multiple ways of
representing the applied configuration. This would provide visibility to
the data independent of whether or not the device supported the revised
data-stores supporting implicit retrieval of the applied configuration.
   2. Prune out the redundant data nodes except those required as list
keys, etc, since they can be obtained from the applied state data store.
   3. #2 plus collapse the config (read-write) and  system-state
(read-only) into common containers. No more branching of
-config and -state at the top level of the model.

At I high-level, I feel these are the options. I’m not married to any one
of these and the worse thing we could do is hold up progression of the
existing YANG model drafts for another couple years while we debate the
best course. Having said that, #3 is compelling since it will yield the
most concise models and colocates the schema data nodes for any managed
object.

Thanks,
Acee

On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
 wrote:


All,

It's time to make a consensus call on this topic, so that we can all move
on to defining a solution and aligning modules under development. Based
on the feedback received and the overall discussions on the topic, we see
that there is consensus to follow a datastore based approach to
supporting operational state, i.e., direction 'B'.

We will be asking the authors of [4] and [5] to review their proposals
(individual drafts) in Berlin, as well as to highlight differences and
suggest ways that their work could be consolidated. Of course, others may
also choose to submit their own proposals. Given the importance of this
work, we will be looking to have active discussion on the topic both in
Berlin and on the list, with an objective of having a draft ready for
considerations as a WG document by the November IETF.

We have reviewed this decision with our AD and the NetConf chairs and
have agreed to begin this work in NetMod. We certainly expect to
coordinate the work with the NetConf WG and re-home work as/if needed.

Finally, we'd also like to thank all those who have contributed to this
discussion to date, from problem identification to proposed solutions,
and we 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

On 7/15/16, 10:23 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)"  wrote:

>
>
>On 15/07/2016 15:16, Acee Lindem (acee) wrote:
>>
>> On 7/14/16, 4:00 PM, "Kent Watsen"  wrote:
>>
>>> [This thread took on a life of its own, so I’m replying to this email
>> >from two days ago]
>>> I had assumed the plan/recommendation would be:
>>>   - for works-in-progress, to evaluate if their models can be improved.
>>>   - for existing RFCs, do nothing (though we may want to consider
>>> RFC7223).
>>>
>>> By “if their models can be improved” in the above, I’m implying that
>>> having a top-level -state branch may still be the best solution for
>>>some
>>> models.  It’s up to each model designer to decide the best approach for
>>> their models.
>>>
>>> Makes sense?
>> I think the statement “if their models can be improved” leaves too much
>> subjectivity in the guideline. Either we are going to avail the revised
>> data store model to avoid duplication of YANG schema nodes or we are
>>going
>> to leverage the new data stores solely to meet the intended/applied
>>config
>> requirement. If it is the latter and a good portion of the network
>>devices
>> will not support, then I would agree.
>Devices can still leverage the new operational state datastore (and
>hence allow foo and foo-state to be merged) without having to supporting
>an intended/applied configuration split (i.e. they just treat applied =
>intended).

Right - but then the applied configuration wouldn’t be available for the
cases where it does differ from intended configuration.

>
>I'm keen to get the models simpler were possible because I think that
>will help with their longevity and ease of use.

For the record, I agree. However, reaching consensus will be difficult.

Thanks,
Acee



>
>Thanks,
>Rob
>
>
>>
>>
>>
>>
>>> Kent  // as a contributor
>>>
>>>
>>> On 7/12/16, 11:23 AM, "netmod on behalf of Lou Berger"
>>>  wrote:
>>>
>>> Acee,
>>>
>>> I personally was assuming we'd follow 3, but I'd like to understand
>>> the implication of 2 as I'm not sure I really understand what you're
>>> thinking here.  Can you elaborate what you're thinking here?
>>>
>>> Thanks,
>>>
>>> Lou
>>>
>>> On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
 While there are details to be worked out between the two data stores
 models (as indicated below), we now have implicit modeling of applied
 configuration. Existing models (both standard and draft) do not take
 this
 into consideration and, consequently, much of the state that is
modeled
 explicitly represents the application configuration. For the RFC
models,
 it probably doesn’t make much sense to redo them (unless they are
being
 reworked for other reasons). This still leaves the existing WG draft
 models for which we have basically 3 options:

1. Do nothing - allow them proceed as they are with multiple ways
of
 representing the applied configuration. This would provide visibility
to
 the data independent of whether or not the device supported the
revised
 data-stores supporting implicit retrieval of the applied
configuration.
2. Prune out the redundant data nodes except those required as list
 keys, etc, since they can be obtained from the applied state data
store.
3. #2 plus collapse the config (read-write) and  system-state
 (read-only) into common containers. No more branching of
 -config and -state at the top level of the
 model.

 At I high-level, I feel these are the options. I’m not married to any
 one
 of these and the worse thing we could do is hold up progression of the
 existing YANG model drafts for another couple years while we debate
the
 best course. Having said that, #3 is compelling since it will yield
the
 most concise models and colocates the schema data nodes for any
managed
 object.

 Thanks,
 Acee

 On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
  wrote:

> All,
>
> It's time to make a consensus call on this topic, so that we can all
> move
> on to defining a solution and aligning modules under development.
>Based
> on the feedback received and the overall discussions on the topic, we
> see
> that there is consensus to follow a datastore based approach to
> supporting operational state, i.e., direction 'B'.
>
> We will be asking the authors of [4] and [5] to review their
>proposals
> (individual drafts) in Berlin, as well as to highlight differences
>and
> suggest ways that their work could be consolidated. Of course, others
> may
> also choose to submit their own proposals. Given the importance of
>this
> work, we will be looking to have active discussion on the 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

On 7/14/16, 4:00 PM, "Kent Watsen"  wrote:

>
>[This thread took on a life of its own, so I’m replying to this email
>from two days ago]
>
>I had assumed the plan/recommendation would be:
>  - for works-in-progress, to evaluate if their models can be improved.
>  - for existing RFCs, do nothing (though we may want to consider
>RFC7223).
>
>By “if their models can be improved” in the above, I’m implying that
>having a top-level -state branch may still be the best solution for some
>models.  It’s up to each model designer to decide the best approach for
>their models.
>
>Makes sense?

I think the statement “if their models can be improved” leaves too much
subjectivity in the guideline. Either we are going to avail the revised
data store model to avoid duplication of YANG schema nodes or we are going
to leverage the new data stores solely to meet the intended/applied config
requirement. If it is the latter and a good portion of the network devices
will not support, then I would agree.




>
>Kent  // as a contributor
>
>
>On 7/12/16, 11:23 AM, "netmod on behalf of Lou Berger"
> wrote:
>
>Acee,
>
>I personally was assuming we'd follow 3, but I'd like to understand
>the implication of 2 as I'm not sure I really understand what you're
>thinking here.  Can you elaborate what you're thinking here?
>
>Thanks,
>
>Lou
>
>On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
>> While there are details to be worked out between the two data stores
>> models (as indicated below), we now have implicit modeling of applied
>> configuration. Existing models (both standard and draft) do not take
>>this
>> into consideration and, consequently, much of the state that is modeled
>> explicitly represents the application configuration. For the RFC models,
>> it probably doesn’t make much sense to redo them (unless they are being
>> reworked for other reasons). This still leaves the existing WG draft
>> models for which we have basically 3 options:
>>
>>   1. Do nothing - allow them proceed as they are with multiple ways of
>> representing the applied configuration. This would provide visibility to
>> the data independent of whether or not the device supported the revised
>> data-stores supporting implicit retrieval of the applied configuration.
>>   2. Prune out the redundant data nodes except those required as list
>> keys, etc, since they can be obtained from the applied state data store.
>>   3. #2 plus collapse the config (read-write) and  system-state
>> (read-only) into common containers. No more branching of
>> -config and -state at the top level of the
>>model.
>>
>> At I high-level, I feel these are the options. I’m not married to any
>>one
>> of these and the worse thing we could do is hold up progression of the
>> existing YANG model drafts for another couple years while we debate the
>> best course. Having said that, #3 is compelling since it will yield the
>> most concise models and colocates the schema data nodes for any managed
>> object. 
>>
>> Thanks,
>> Acee 
>>
>> On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
>>  wrote:
>>
>>> All,
>>>
>>> It's time to make a consensus call on this topic, so that we can all
>>>move
>>> on to defining a solution and aligning modules under development. Based
>>> on the feedback received and the overall discussions on the topic, we
>>>see
>>> that there is consensus to follow a datastore based approach to
>>> supporting operational state, i.e., direction 'B'.
>>>
>>> We will be asking the authors of [4] and [5] to review their proposals
>>> (individual drafts) in Berlin, as well as to highlight differences and
>>> suggest ways that their work could be consolidated. Of course, others
>>>may
>>> also choose to submit their own proposals. Given the importance of this
>>> work, we will be looking to have active discussion on the topic both in
>>> Berlin and on the list, with an objective of having a draft ready for
>>> considerations as a WG document by the November IETF.
>>>
>>> We have reviewed this decision with our AD and the NetConf chairs and
>>> have agreed to begin this work in NetMod. We certainly expect to
>>> coordinate the work with the NetConf WG and re-home work as/if needed.
>>>
>>> Finally, we'd also like to thank all those who have contributed to this
>>> discussion to date, from problem identification to proposed solutions,
>>> and we look forward to your continued efforts to publish a standard
>>> solution. 
>>>
>>> Lou (and Kent)
>>>
>>>
>>> On 6/7/2016 10:19 AM, Lou Berger wrote:
 All,

 We want to provide an update based on the off line discussions
 related to OpState Solutions that we have been having and solicit
 input from the WG.

 All authors of current solution drafts [1,2,3] together with those
 who helped conduct the solutions analysis* were invited to the these
 discussions -- with 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Wed, Jul 13, 2016 at 3:17 PM, Kent Watsen  wrote:

>
>
>
>
> > RW:
> > Are you thinking of a single global notification of convergence?
>
>
>
>
>
> > No
>
> >
>
> > I think the client would request a notification for its edit.
>
> > There would be a long-form and short-form notification.
>
> >
>
> > The interaction model is simple:
>
> >   A) at the time of the request the client opt-in for being notified
>
>
>
> opstate-reqs refers to this as an asynchronous configuration operation.
> Requirement 2-B says:
>
>
>
>Servers that support asynchronous configuration operations
>
>MUST provide a mechanism to notify the client when a request
>
>has completed processing.  The notification MUST indicate
>
>whether the intended config is now fully applied or if there
>
>were any errors from applying the configuration change.
>
>
>
> I don’t see a need for long/short forms or timeouts here.  Are you
> suggesting a need to change how the requirements are worded?
>
>
>

I am just suggesting how I would design this feature.
I certainly don't want to read any more requirements drafts, so implement
whatever you want.

The short-form is really just the long-form with an empty list of unapplied
edits.



> Kent
>
>
>


Andy


>
>
> >   B) the server will send the short form (all-ok) ASAP or even return
> the short-form all-ok
>
> >in the response and skip the notifications if possible
>
> >C) if the timeout occurs, then the server sends the long-form
> notification, which lists
>
> > all the intended config operations not yet applied.  (This is
> easier to do for YANG Patch
>
> >where the edits are identified, than with  that has
> an unordered blob of XML).
>
> >
>
> >
>
> > Parameters would be added to the edit request:
>
> >
>
> >- want-notif:  (boolean: default false)
>
> >- notif-timeout: how long the server should wait before sending the
> long-form notification
>
> >- trace-id:  string provided by the client similar to persist-id that
> will identify this edit
>
> >   in the notifications
>
> >
>
> >
>
> > This approach does not deal with multi-client conflicts.
>
> > If client A does "create /foo" then the server ACKs that edit even if
> client B
>
> > has started a subsequent "delete /foo" edit before the first edit was
> ACKed.
>
> >
>
> > A separate RPC to retrieve the long-form notification for all pending
> edits would
>
> > also be needed to allow for a notification to be lost or a client to
> query the entire
>
> > list of unapplied edits.
>
> >
>
> > Andy
>
>
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Kent Watsen]

> RW:
> Are you thinking of a single global notification of convergence?


> No
>
> I think the client would request a notification for its edit.
> There would be a long-form and short-form notification.
>
> The interaction model is simple:
>   A) at the time of the request the client opt-in for being notified

opstate-reqs refers to this as an asynchronous configuration operation.  
Requirement 2-B says:

   Servers that support asynchronous configuration operations
   MUST provide a mechanism to notify the client when a request
   has completed processing.  The notification MUST indicate
   whether the intended config is now fully applied or if there
   were any errors from applying the configuration change.

I don’t see a need for long/short forms or timeouts here.  Are you suggesting a 
need to change how the requirements are worded?

Kent


>   B) the server will send the short form (all-ok) ASAP or even return the 
> short-form all-ok
>in the response and skip the notifications if possible
>C) if the timeout occurs, then the server sends the long-form 
> notification, which lists
> all the intended config operations not yet applied.  (This is easier 
> to do for YANG Patch
>where the edits are identified, than with  that has an 
> unordered blob of XML).
>
>
> Parameters would be added to the edit request:
>
>- want-notif:  (boolean: default false)
>- notif-timeout: how long the server should wait before sending the 
> long-form notification
>- trace-id:  string provided by the client similar to persist-id that will 
> identify this edit
>   in the notifications
>
>
> This approach does not deal with multi-client conflicts.
> If client A does "create /foo" then the server ACKs that edit even if client B
> has started a subsequent "delete /foo" edit before the first edit was ACKed.
>
> A separate RPC to retrieve the long-form notification for all pending edits 
> would
> also be needed to allow for a notification to be lost or a client to query 
> the entire
> list of unapplied edits.
>
> Andy



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Wed, Jul 13, 2016 at 2:43 AM, Robert Wilton  wrote:

> Please see RW: inline
>
> On 12/07/2016 20:15, Andy Bierman wrote:
>
>
>
> On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de
> > wrote:
>
>> On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote:
>> > Yes there is value in modeling conventions in general.
>> > I am trying to understand the value of this specific convention.
>> >
>> > If I have an RPC that asks for applied state, then it doesn't really
>> matter
>> > how the config and state is organized.  There is only overlap in the
>> objects
>> > if the data model is designed that way.
>> >
>> > Whether or not an edit is applied yet is a property of the
>> implementation,
>> > not the data model.
>>
>> The current /foo and /foo-state approach requires some amount of
>> duplication. If the trees contain some nested lists of lists, you have
>> to at least replicate all the key leafs in the schema definition. For
>> a small model, this is not a bit deal; for more complex models, this
>> becomes complex and there are possible sources of errors. If it is
>> possible to simply data models, this may be a long-term win.
>>
>>
>
> It only requires duplication if you insist on modeling opstate objects.
> IMO an RPC + notification approach is far superior.
>
> RW:
>
> Are you thinking of a single global notification of convergence?
>


No

I think the client would request a notification for its edit.
There would be a long-form and short-form notification.

The interaction model is simple:
   A) at the time of the request the client opt-in for being notified
   B) the server will send the short form (all-ok) ASAP or even return the
short-form all-ok
in the response and skip the notifications if possible
C) if the timeout occurs, then the server sends the long-form
notification, which lists
 all the intended config operations not yet applied.  (This is
easier to do for YANG Patch
where the edits are identified, than with  that has an
unordered blob of XML).


Parameters would be added to the edit request:

- want-notif:  (boolean: default false)
- notif-timeout: how long the server should wait before sending the
long-form notification
- trace-id:  string provided by the client similar to persist-id that
will identify this edit
   in the notifications


This approach does not deal with multi-client conflicts.
If client A does "create /foo" then the server ACKs that edit even if
client B
has started a subsequent "delete /foo" edit before the first edit was ACKed.

A separate RPC to retrieve the long-form notification for all pending edits
would
also be needed to allow for a notification to be lost or a client to query
the entire
list of unapplied edits.


Andy




> Although such a scheme may be sufficient if the configuration is changing
> infrequently, it is not sufficient for a system in which configuration is
> changing frequently (e.g. say to provision very short lived tunnels across
> a data center network).
>
> If the client is interested when a particular config change has converged
> then a global converged flag:
>  (i) may be delayed a long time (if at all) after the config change has
> completed (because other subsequent config operations are in progress)
>  (ii) may be hard to relate back to the original config change
>
> Hence, I think that there are only 2 technical solutions to this problem:
> (a) reporting/notifying the state of the applied configuration nodes (as
> per the requirements stated in draft-ietf-netmod-opstate-reqs, and covered
> by the all the various solution drafts)
> (b) report the success/failure of the particular config operation.
>
> My opinion, is that as network configuration becomes more dynamic, and
> programmatically controlled then (a) is the easier solution and more robust
> to failure over (b).  But both approaches can be supported by devices.
>
>
> In this approach I only need to identify the intended config object
> and retrieve (or be notified) of the applied-state transition.
>
> RW:
>
> This is only part of the solution, since metadata can only be used when
> nodes exist in the YANG data tree.  So, this method alone cannot indicate
> configuration that is applied by the device and is in the process of being
> deleted.
>
> That is primarily why draft-wilton-netconf-opstate-metadata-00 offers
> metadata both on the "persistent" datastore and "operational state
> datastore".
>
>
>
>
>
>
>> The reason why we have the /foo and /foo-state convention is, I
>> believe, the design of the NETCONF  operation, which assumes
>> state and config can be represented together in a single tree. And we
>> have carried this further into YANG (e.g., the way contexts are
>> constructed for xpath expressions). In hindsight, I am not sure the
>> consequences of the  design were that well thought through - but
>> I am not complaining, 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 13/07/2016 17:27, Andy Bierman wrote:



On Wed, Jul 13, 2016 at 3:04 AM, Robert Wilton <rwil...@cisco.com 
<mailto:rwil...@cisco.com>> wrote:


Hi Alex,


What you describe is close, but not quite what either of the two
datastore solutions are proposing.

In this case, the two solutions in both proposed drafts would contain:
  - intended config doesn't contain the list entries
  - applied config doesn't contain the list entries
  - operational state datastore contains the system created
(config true) list entries + descendant config false nodes.

The reason why these system created entries are not in the applied
configuration is because of the requirement from
draft-ietf-netmod-opstate-reqs state that "intended config" =
"applied config" if the system has converged and all configuration
has been successfully applied.

But, yes, the reason for allowing system created config true
entries in the operational state datastore is to solve this problem.




I do not agree with Alex that config=true can mean "no client can ever 
set this value".

It can only if NACM is configured to disable client write access.

RW:
I agree with you, but I didn't read Alex's email as stating that.

Instead, I read it as: even if a device doesn't allow the nodes to be 
configured then they could still be populated by the device in the 
applied configuration datastore.



I understand how one might want to use server-created values in 
validation rules

but YANG does not support that right now (for config=false).

The line between server-created config and operational state is 
confusing at best.

RW:

Yes, OK.  That is perhaps because they are not completely related.

The original OpenConfig opstate draft also asked for a solution to what 
they perceived as an unnecessary split between "feature" vs "feature-state".


When discussing the datastore solutions it became clear that having a 
formal definition of an "operational state datastore" also allowed for a 
solution to the problem above.  Specifically by allowing the operational 
state datastore to contain any necessary config true leaves (even if 
they have not been configured) that are required to hold any descendant 
config false leaves.


To cite an example:

If the schema content of if:interfaces-state was merged into the schema 
for if:interfaces then the "operational state datastore" of a device 
would be allowed to contain entries in the if:interfaces list for 
interfaces that exist in the system but have not been configured.


As a side note, the metadata draft that I've put forward then suggests 
to use metadata annotations of these system created entries in the 
"operational state datastore" to allow clients to distinguish between 
config true entries that exist because they are applied configuration, 
vs config true entries that exist because they are system created.


Rob








Rob



Andy


On 13/07/2016 10:49, Alex Campbell wrote:

Isn't that exactly what the proposed applied configuration
datastore is for?
If a device doesn't allow management stations to create or remove
list entries, but still creates or removes list entries itself,
then it can publish them through the applied configuration
datastore, while leaving the intended configuration datastore
empty. Operational data can be contained inside those list
entries which exist in the applied configuration store, instead
of needing a separate tree to contain it.

- Alex





*From:* netmod <netmod-boun...@ietf.org>
<mailto:netmod-boun...@ietf.org> on behalf of Andy Bierman
<a...@yumaworks.com> <mailto:a...@yumaworks.com>
*Sent:* Wednesday, 13 July 2016 4:17 a.m.
    *To:* Lou Berger
    *Cc:* netmod WG
*Subject:* Re: [netmod] OpsState Direction Impact on Recommended
IETF YANG Model Structure


On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net
<mailto:lber...@labn.net>> wrote:

Acee,

I personally was assuming we'd follow 3, but I'd like to
understand
the implication of 2 as I'm not sure I really understand what
you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level
of the model.
>.



I would really like to understand what problem (3) is supposed to
solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary
configuration mechanisms.
(e

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Wed, Jul 13, 2016 at 3:04 AM, Robert Wilton <rwil...@cisco.com> wrote:

> Hi Alex,
>
>
> What you describe is close, but not quite what either of the two datastore
> solutions are proposing.
>
> In this case, the two solutions in both proposed drafts would contain:
>   - intended config doesn't contain the list entries
>   - applied config doesn't contain the list entries
>   - operational state datastore contains the system created (config true)
> list entries + descendant config false nodes.
>
> The reason why these system created entries are not in the applied
> configuration is because of the requirement from
> draft-ietf-netmod-opstate-reqs state that "intended config" = "applied
> config" if the system has converged and all configuration has been
> successfully applied.
>
> But, yes, the reason for allowing system created config true entries in
> the operational state datastore is to solve this problem.
>
>


I do not agree with Alex that config=true can mean "no client can ever set
this value".
It can only if NACM is configured to disable client write access.
I understand how one might want to use server-created values in validation
rules
but YANG does not support that right now (for config=false).

The line between server-created config and operational state is confusing
at best.




Rob
>
>

Andy


>
> On 13/07/2016 10:49, Alex Campbell wrote:
>
> Isn't that exactly what the proposed applied configuration datastore is
> for?
> If a device doesn't allow management stations to create or remove list
> entries, but still creates or removes list entries itself, then it can
> publish them through the applied configuration datastore, while leaving the
> intended configuration datastore empty.  Operational data can be contained
> inside those list entries which exist in the applied configuration store,
> instead of needing a separate tree to contain it.
>
> - Alex
>
>
>
>
> --
> *From:* netmod <netmod-boun...@ietf.org> <netmod-boun...@ietf.org> on
> behalf of Andy Bierman <a...@yumaworks.com> <a...@yumaworks.com>
> *Sent:* Wednesday, 13 July 2016 4:17 a.m.
> *To:* Lou Berger
> *Cc:* netmod WG
> *Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF
> YANG Model Structure
>
>
>
> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net> wrote:
>
>> Acee,
>>
>> I personally was assuming we'd follow 3, but I'd like to understand
>> the implication of 2 as I'm not sure I really understand what you're
>> thinking here.  Can you elaborate what you're thinking here?
>>
>> Thanks,
>>
>> Lou
>> .
>> >   3. #2 plus collapse the config (read-write) and  system-state
>> > (read-only) into common containers. No more branching of
>> > -config and -state at the top level of the
>> model.
>> >.
>
>
>
> I would really like to understand what problem (3) is supposed to solve.
>
> Most of the foo-state variables are for monitoring.
> This information is useful even if the server uses proprietary
> configuration mechanisms.
> (e.g., the way the SNMP world has worked for 30 years)
>
> If you forbid separate monitoring subtrees and force the data to be
> co-located
> with configuration, that means the standard monitoring will not be
> supported
> unless the standard configuration is also supported.  Why is that progress?
>
>
> Andy
>
>
>
>
>
>
> ___
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

Hi Alex,


What you describe is close, but not quite what either of the two 
datastore solutions are proposing.


In this case, the two solutions in both proposed drafts would contain:
  - intended config doesn't contain the list entries
  - applied config doesn't contain the list entries
  - operational state datastore contains the system created (config 
true) list entries + descendant config false nodes.


The reason why these system created entries are not in the applied 
configuration is because of the requirement from 
draft-ietf-netmod-opstate-reqs state that "intended config" = "applied 
config" if the system has converged and all configuration has been 
successfully applied.


But, yes, the reason for allowing system created config true entries in 
the operational state datastore is to solve this problem.


Rob


On 13/07/2016 10:49, Alex Campbell wrote:
Isn't that exactly what the proposed applied configuration datastore 
is for?
If a device doesn't allow management stations to create or remove list 
entries, but still creates or removes list entries itself, then it can 
publish them through the applied configuration datastore, while 
leaving the intended configuration datastore empty.  Operational data 
can be contained inside those list entries which exist in the applied 
configuration store, instead of needing a separate tree to contain it.


- Alex





*From:* netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman 
<a...@yumaworks.com>

*Sent:* Wednesday, 13 July 2016 4:17 a.m.
*To:* Lou Berger
*Cc:* netmod WG
*Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF 
YANG Model Structure



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net 
<mailto:lber...@labn.net>> wrote:


Acee,

I personally was assuming we'd follow 3, but I'd like to
understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of
the model.
>.



I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary 
configuration mechanisms.

(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be 
co-located
with configuration, that means the standard monitoring will not be 
supported
unless the standard configuration is also supported.  Why is that 
progress?



Andy





___
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] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Alex Campbell]

Isn't that exactly what the proposed applied configuration datastore is for?
If a device doesn't allow management stations to create or remove list entries, 
but still creates or removes list entries itself, then it can publish them 
through the applied configuration datastore, while leaving the intended 
configuration datastore empty.  Operational data can be contained inside those 
list entries which exist in the applied configuration store, instead of needing 
a separate tree to contain it.

- Alex






From: netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman 
<a...@yumaworks.com>
Sent: Wednesday, 13 July 2016 4:17 a.m.
To: Lou Berger
Cc: netmod WG
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger 
<lber...@labn.net<mailto:lber...@labn.net>> wrote:
Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>.


I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration 
mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.  Why is that progress?


Andy




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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

Please see RW: inline


On 12/07/2016 20:15, Andy Bierman wrote:



On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder 
> wrote:


On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote:
> Yes there is value in modeling conventions in general.
> I am trying to understand the value of this specific convention.
>
> If I have an RPC that asks for applied state, then it doesn't
really matter
> how the config and state is organized.  There is only overlap in
the objects
> if the data model is designed that way.
>
> Whether or not an edit is applied yet is a property of the
implementation,
> not the data model.

The current /foo and /foo-state approach requires some amount of
duplication. If the trees contain some nested lists of lists, you have
to at least replicate all the key leafs in the schema definition. For
a small model, this is not a bit deal; for more complex models, this
becomes complex and there are possible sources of errors. If it is
possible to simply data models, this may be a long-term win.



It only requires duplication if you insist on modeling opstate objects.
IMO an RPC + notification approach is far superior.

RW:

Are you thinking of a single global notification of convergence?

Although such a scheme may be sufficient if the configuration is 
changing infrequently, it is not sufficient for a system in which 
configuration is changing frequently (e.g. say to provision very short 
lived tunnels across a data center network).


If the client is interested when a particular config change has 
converged then a global converged flag:
 (i) may be delayed a long time (if at all) after the config change has 
completed (because other subsequent config operations are in progress)

 (ii) may be hard to relate back to the original config change

Hence, I think that there are only 2 technical solutions to this problem:
(a) reporting/notifying the state of the applied configuration nodes (as 
per the requirements stated in draft-ietf-netmod-opstate-reqs, and 
covered by the all the various solution drafts)

(b) report the success/failure of the particular config operation.

My opinion, is that as network configuration becomes more dynamic, and 
programmatically controlled then (a) is the easier solution and more 
robust to failure over (b).  But both approaches can be supported by 
devices.




In this approach I only need to identify the intended config object
and retrieve (or be notified) of the applied-state transition.

RW:

This is only part of the solution, since metadata can only be used when 
nodes exist in the YANG data tree.  So, this method alone cannot 
indicate configuration that is applied by the device and is in the 
process of being deleted.


That is primarily why draft-wilton-netconf-opstate-metadata-00 offers 
metadata both on the "persistent" datastore and "operational state 
datastore".






The reason why we have the /foo and /foo-state convention is, I
believe, the design of the NETCONF  operation, which assumes
state and config can be represented together in a single tree. And we
have carried this further into YANG (e.g., the way contexts are
constructed for xpath expressions). In hindsight, I am not sure the
consequences of the  design were that well thought through - but
I am not complaining, at that time we did not have YANG nor did we
have experience with bigger data models written in YANG. Is it worth
fixing it? This is a tough question and I understand that people have
different opinions and also different views on where we are on the
lifecycle of this technology. The challenge, as always, is to evolve a
technology along with its usage and upcoming new requirements. If the
evolution is too fast, you risk fragmentation since people will then
run many different versions. If evolution is too slow or stops
entirely, you pave the way for complete replacements of the
technology.

I think it is worth to step back for a moment and to think about where
we like to be in 5 or 10 years from now when we discuss architectural
questions.



We have read-only foo-state because we have only been standardizing
monitoring data for the last 30 years.  I completely agree that if the 
state depends
on the config in order for an instance to exist, then co-locate the 
config and

state and share the node naming.


But modeling admin-state and oper-state with the same object is not a 
requirement.

RW:

I agree, but when the oper-state exactly of a node reflects the applied 
admin-state then I see no benefit in having a separate duplicate "config 
false" node.


Rob


Being able to determine if the intended config is applied yet is a 
requirement.
This can be done with protocol operations so it is 100% data model 
neutral.




/js


Andy


--
  

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 12/07/2016 20:07, Juergen Schoenwaelder wrote:

I think it is worth to step back for a moment and to think about where
we like to be in 5 or 10 years from now when we discuss architectural
questions.

RW:

This makes sense, if we can do it in parallel to making progress on the 
opstate discussions.  In particular, I think that IETF needs to very 
quickly resolve any open issues that are preventing WGs from publishing 
standard YANG models (e.g. the config/state split). Delaying this risks 
making the IETF YANG models some what obsolete (at least in some parts 
of the market) before they are published.


Not necessarily directly related, but my understanding is that the way 
that some of the OpenConfig operators are intending to configure and 
manage networks is quite different from how networks have been 
historically managed.  I think that writing up this architecture as an 
Information draft would likely benefit individuals who are trying to 
understand the proposed changes to NETCONF/YANG and what those changes 
are trying to achieve.


Rob



/js



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote:
> > Yes there is value in modeling conventions in general.
> > I am trying to understand the value of this specific convention.
> >
> > If I have an RPC that asks for applied state, then it doesn't really
> matter
> > how the config and state is organized.  There is only overlap in the
> objects
> > if the data model is designed that way.
> >
> > Whether or not an edit is applied yet is a property of the
> implementation,
> > not the data model.
>
> The current /foo and /foo-state approach requires some amount of
> duplication. If the trees contain some nested lists of lists, you have
> to at least replicate all the key leafs in the schema definition. For
> a small model, this is not a bit deal; for more complex models, this
> becomes complex and there are possible sources of errors. If it is
> possible to simply data models, this may be a long-term win.
>
> The reason why we have the /foo and /foo-state convention is, I
> believe, the design of the NETCONF  operation, which assumes
> state and config can be represented together in a single tree. And we
> have carried this further into YANG (e.g., the way contexts are
> constructed for xpath expressions). In hindsight, I am not sure the
> consequences of the  design were that well thought through - but
> I am not complaining, at that time we did not have YANG nor did we
> have experience with bigger data models written in YANG. Is it worth
> fixing it? This is a tough question and I understand that people have
> different opinions and also different views on where we are on the
> lifecycle of this technology. The challenge, as always, is to evolve a
> technology along with its usage and upcoming new requirements. If the
> evolution is too fast, you risk fragmentation since people will then
> run many different versions. If evolution is too slow or stops
> entirely, you pave the way for complete replacements of the
> technology.
>
>

I think the foo-state convention comes from the fact that 99% of the NM
standards
have been read-only until now.  It is often desirable to index the
monitoring
tables differently than the configuration, even for opstate values.
The data structures for counters may mirror the hardware, which
may not be how the service configuration is indexed.

The premise all those years (still valid today) is that standard monitoring
makes it easier for application developers to write monitoring applications.
Configuration was left to the proprietary CLI.

It would be a mistake to lose standard monitoring unless and until
the standard configuration was finished and implemented.
This would be an unintended side effect of moving all monitoring under
the configuration subtree for a feature.


I think it is worth to step back for a moment and to think about where
> we like to be in 5 or 10 years from now when we discuss architectural
> questions.
>
> /js
>
>

Andy



> --
> 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] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Juergen Schoenwaelder]

On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote:
> Yes there is value in modeling conventions in general.
> I am trying to understand the value of this specific convention.
> 
> If I have an RPC that asks for applied state, then it doesn't really matter
> how the config and state is organized.  There is only overlap in the objects
> if the data model is designed that way.
> 
> Whether or not an edit is applied yet is a property of the implementation,
> not the data model.

The current /foo and /foo-state approach requires some amount of
duplication. If the trees contain some nested lists of lists, you have
to at least replicate all the key leafs in the schema definition. For
a small model, this is not a bit deal; for more complex models, this
becomes complex and there are possible sources of errors. If it is
possible to simply data models, this may be a long-term win.

The reason why we have the /foo and /foo-state convention is, I
believe, the design of the NETCONF  operation, which assumes
state and config can be represented together in a single tree. And we
have carried this further into YANG (e.g., the way contexts are
constructed for xpath expressions). In hindsight, I am not sure the
consequences of the  design were that well thought through - but
I am not complaining, at that time we did not have YANG nor did we
have experience with bigger data models written in YANG. Is it worth
fixing it? This is a tough question and I understand that people have
different opinions and also different views on where we are on the
lifecycle of this technology. The challenge, as always, is to evolve a
technology along with its usage and upcoming new requirements. If the
evolution is too fast, you risk fragmentation since people will then
run many different versions. If evolution is too slow or stops
entirely, you pave the way for complete replacements of the
technology.

I think it is worth to step back for a moment and to think about where
we like to be in 5 or 10 years from now when we discuss architectural
questions.

/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] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Lou Berger]

Andy,

This may be a bit OBE by the conversation on the list, but see below...


On 7/12/2016 12:17 PM, Andy Bierman wrote:
>
>
> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger  > wrote:
>
> Acee,
>
> I personally was assuming we'd follow 3, but I'd like to
> understand
> the implication of 2 as I'm not sure I really understand what you're
> thinking here.  Can you elaborate what you're thinking here?
>
> Thanks,
>
> Lou
> .
> >   3. #2 plus collapse the config (read-write) and  system-state
> > (read-only) into common containers. No more branching of
> > -config and -state at the top level of
> the model.
> >.
>
>
>
> I would really like to understand what problem (3) is supposed to solve.
>

The config/state split discussed in the context of opstate, and the
openconfig draft in particular, reflects two different types of separations:

1) configuration vs operational information (e.g., intf parameter vs
counters)

2) intended vs applied configuration

My earlier comment about assuming that we're getting rid of -config and
-state (as part f the decision to move to revised datastores) was really
focused on the second.


> Most of the foo-state variables are for monitoring.

I really wasn't commenting on conventions WRT configuration data and
operational parameters relationship/organization -- although I think
having a general convention for these is "a good idea".


> This information is useful even if the server uses proprietary
> configuration mechanisms.
> (e.g., the way the SNMP world has worked for 30 years)
>
> If you forbid separate monitoring subtrees and force the data to be
> co-located
> with configuration, that means the standard monitoring will not be
> supported
> unless the standard configuration is also supported.  Why is that
> progress?
>
>

Again, I was focusing on the intended vs applied aspects here.  I can
see reasons to keep a top level spit for config vs operational state,
but alos don't have a strong personal bias on this.

Lou

> Andy
>
>
>  


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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Tue, Jul 12, 2016 at 10:43 AM, Acee Lindem (acee) <a...@cisco.com> wrote:

>
>
> From: netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman <
> a...@yumaworks.com>
> Date: Tuesday, July 12, 2016 at 1:27 PM
> To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <
> rwil...@cisco.com>
> Cc: netmod WG <netmod@ietf.org>
> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG
> Model Structure
>
>
>
> On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton <rwil...@cisco.com> wrote:
>
>>
>>
>> On 12/07/2016 18:05, Andy Bierman wrote:
>>
>>
>>
>> On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton <rwil...@cisco.com> wrote:
>>
>>> Hi Andy,
>>>
>>> On 12/07/2016 17:17, Andy Bierman wrote:
>>>
>>>
>>>
>>> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger < <lber...@labn.net>
>>> lber...@labn.net> wrote:
>>>
>>>> Acee,
>>>>
>>>> I personally was assuming we'd follow 3, but I'd like to understand
>>>> the implication of 2 as I'm not sure I really understand what you're
>>>> thinking here.  Can you elaborate what you're thinking here?
>>>>
>>>> Thanks,
>>>>
>>>> Lou
>>>> .
>>>> >   3. #2 plus collapse the config (read-write) and  system-state
>>>> > (read-only) into common containers. No more branching of
>>>> > -config and -state at the top level of the
>>>> model.
>>>> >.
>>>
>>>
>>>
>>> I would really like to understand what problem (3) is supposed to solve.
>>>
>>> My personal view is that I think that it makes the models simpler, with
>>> less duplication.
>>>
>>> E.g. I also see that it makes it easier for a client to fetch all of the
>>> information associated with a particular feature in a single sub tree
>>> rather that needing to merge data from two separate config & state sub
>>> trees.
>>>
>>>
>> This is your opinion.
>> I think separate makes it easier to read, especially if the monitoring
>> data
>> is relevant regardless of how associated configuration was done.
>>
>> This is easily achievable by filtering (e.g. only return config false
>> leaves + config true structural nodes).
>>
>>
>
> Filtering is not widely implemented or implemented correctly.
>
> IMO it is up to the data model designers how they want to organize their
> data.
> I have not heard any valid reasons why a generalized solution is even
> needed,
> let alone why separate config and state needs to be avoided.
>
>
> There is definitely value in having model conventions. One argument for
> collapsing the config and state is that once you have the implicit
> retrieval of the applied state, there is much less operational state that
> isn’t redundant.
>
>
Yes there is value in modeling conventions in general.
I am trying to understand the value of this specific convention.

If I have an RPC that asks for applied state, then it doesn't really matter
how the config and state is organized.  There is only overlap in the objects
if the data model is designed that way.

Whether or not an edit is applied yet is a property of the implementation,
not the data model.

There is also requirement #4 in
> https://www.ietf.org/id/draft-ietf-netmod-opstate-reqs-04.txt. However, I
> know you’ve never been a fan of this document.
>
> Thanks,
> Acee
>
>
>
>
>
Andy


>
>
> Andy
>
>
>>
>>
>>
>>
>>>
>>> Most of the foo-state variables are for monitoring.
>>> This information is useful even if the server uses proprietary
>>> configuration mechanisms.
>>> (e.g., the way the SNMP world has worked for 30 years)
>>>
>>> I thought that it was config that was originally driving YANG because
>>> there is already a solution for state data (SNMP).  Hence, I would have
>>> thought that the most common case would be that YANG is used just for
>>> config, or config & state.  So, I think that it makes sense to optimize
>>> models for these scenarios.
>>>
>>
>>
>> This is marketing.
>> Do you have any technical arguments?
>>
>> Yes, I gave them below: I don't see that merging config and state
>> prevents entities from only monitoring state if they wish.
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>>>
>>>
>>> If you forbid 

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 1:27 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
<rwil...@cisco.com<mailto:rwil...@cisco.com>>
Cc: netmod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton 
<rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote:


On 12/07/2016 18:05, Andy Bierman wrote:


On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton 
<rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote:

Hi Andy,

On 12/07/2016 17:17, Andy Bierman wrote:


On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger 
<<mailto:lber...@labn.net>lber...@labn.net<mailto:lber...@labn.net>> wrote:
Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>.


I would really like to understand what problem (3) is supposed to solve.
My personal view is that I think that it makes the models simpler, with less 
duplication.

E.g. I also see that it makes it easier for a client to fetch all of the 
information associated with a particular feature in a single sub tree rather 
that needing to merge data from two separate config & state sub trees.


This is your opinion.
I think separate makes it easier to read, especially if the monitoring data
is relevant regardless of how associated configuration was done.
This is easily achievable by filtering (e.g. only return config false leaves + 
config true structural nodes).



Filtering is not widely implemented or implemented correctly.

IMO it is up to the data model designers how they want to organize their data.
I have not heard any valid reasons why a generalized solution is even needed,
let alone why separate config and state needs to be avoided.

There is definitely value in having model conventions. One argument for 
collapsing the config and state is that once you have the implicit retrieval of 
the applied state, there is much less operational state that isn’t redundant.

There is also requirement #4 in 
https://www.ietf.org/id/draft-ietf-netmod-opstate-reqs-04.txt. However, I know 
you’ve never been a fan of this document.

Thanks,
Acee






Andy





Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration 
mechanisms.
(e.g., the way the SNMP world has worked for 30 years)
I thought that it was config that was originally driving YANG because there is 
already a solution for state data (SNMP).  Hence, I would have thought that the 
most common case would be that YANG is used just for config, or config & state. 
 So, I think that it makes sense to optimize models for these scenarios.


This is marketing.
Do you have any technical arguments?
Yes, I gave them below: I don't see that merging config and state prevents 
entities from only monitoring state if they wish.

Thanks,
Rob





If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.
Both datastore draft solutions allow for system created config entries.  So in 
both drafts the operational state datastore can instantiate whatever config 
nodes are necessary to parent config false state nodes.

I also don't think that separate monitoring subtrees are going to be banned, 
they should be used where appropriate.  It is just that it will be no longer be 
required to have separate state subtrees purely because of potential 
differences in the lifetime of config vs state objects (e.g. interfaces vs 
interfaces-state).

I would be very happy if "interfaces" and "interfaces-state" could be merged 
into "interfaces" as a new/updated interfaces YANG model that draft models 
could be updated to use.  I understand that would be a impactful change to make 
(but seemingly mostly on IETF models that haven't yet been standardized).  But 
I hope that we are going to have to live with the YANG model structure for a 
long time, and if we still have an opportunity to "fix" a fairly big wart then 
I think that it would be good to do so.


I can't say if the pre-provisioning model in ietf-interfaces should be 
generalized.
I have not seen any good general solutions for combining config and state.



Rob

Andy


  Why is that progress?


An

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton  wrote:

>
>
> On 12/07/2016 18:05, Andy Bierman wrote:
>
>
>
> On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> On 12/07/2016 17:17, Andy Bierman wrote:
>>
>>
>>
>> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger < 
>> lber...@labn.net> wrote:
>>
>>> Acee,
>>>
>>> I personally was assuming we'd follow 3, but I'd like to understand
>>> the implication of 2 as I'm not sure I really understand what you're
>>> thinking here.  Can you elaborate what you're thinking here?
>>>
>>> Thanks,
>>>
>>> Lou
>>> .
>>> >   3. #2 plus collapse the config (read-write) and  system-state
>>> > (read-only) into common containers. No more branching of
>>> > -config and -state at the top level of the
>>> model.
>>> >.
>>
>>
>>
>> I would really like to understand what problem (3) is supposed to solve.
>>
>> My personal view is that I think that it makes the models simpler, with
>> less duplication.
>>
>> E.g. I also see that it makes it easier for a client to fetch all of the
>> information associated with a particular feature in a single sub tree
>> rather that needing to merge data from two separate config & state sub
>> trees.
>>
>>
> This is your opinion.
> I think separate makes it easier to read, especially if the monitoring data
> is relevant regardless of how associated configuration was done.
>
> This is easily achievable by filtering (e.g. only return config false
> leaves + config true structural nodes).
>
>

Filtering is not widely implemented or implemented correctly.

IMO it is up to the data model designers how they want to organize their
data.
I have not heard any valid reasons why a generalized solution is even
needed,
let alone why separate config and state needs to be avoided.


Andy


>
>
>
>
>>
>> Most of the foo-state variables are for monitoring.
>> This information is useful even if the server uses proprietary
>> configuration mechanisms.
>> (e.g., the way the SNMP world has worked for 30 years)
>>
>> I thought that it was config that was originally driving YANG because
>> there is already a solution for state data (SNMP).  Hence, I would have
>> thought that the most common case would be that YANG is used just for
>> config, or config & state.  So, I think that it makes sense to optimize
>> models for these scenarios.
>>
>
>
> This is marketing.
> Do you have any technical arguments?
>
> Yes, I gave them below: I don't see that merging config and state prevents
> entities from only monitoring state if they wish.
>
> Thanks,
> Rob
>
>
>
>
>>
>>
>> If you forbid separate monitoring subtrees and force the data to be
>> co-located
>> with configuration, that means the standard monitoring will not be
>> supported
>> unless the standard configuration is also supported.
>>
>> Both datastore draft solutions allow for system created config entries.
>> So in both drafts the operational state datastore can instantiate whatever
>> config nodes are necessary to parent config false state nodes.
>>
>> I also don't think that separate monitoring subtrees are going to be
>> banned, they should be used where appropriate.  It is just that it will be
>> no longer be required to have separate state subtrees purely because of
>> potential differences in the lifetime of config vs state objects (e.g.
>> interfaces vs interfaces-state).
>>
>> I would be very happy if "interfaces" and "interfaces-state" could be
>> merged into "interfaces" as a new/updated interfaces YANG model that draft
>> models could be updated to use.  I understand that would be a impactful
>> change to make (but seemingly mostly on IETF models that haven't yet been
>> standardized).  But I hope that we are going to have to live with the YANG
>> model structure for a long time, and if we still have an opportunity to
>> "fix" a fairly big wart then I think that it would be good to do so.
>>
>>
> I can't say if the pre-provisioning model in ietf-interfaces should be
> generalized.
> I have not seen any good general solutions for combining config and state.
>
>
>
>
>
>> Rob
>>
>
> Andy
>
>
>>
>>   Why is that progress?
>>
>>
>> Andy
>>
>>
>>
>>
>>
>> ___
>> netmod mailing 
>> listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

On 12/07/2016 18:05, Andy Bierman wrote:



On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton > wrote:


Hi Andy,


On 12/07/2016 17:17, Andy Bierman wrote:



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger > wrote:

Acee,

I personally was assuming we'd follow 3, but I'd like to
understand
the implication of 2 as I'm not sure I really understand what
you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level
of the model.
>.



I would really like to understand what problem (3) is supposed to
solve.

My personal view is that I think that it makes the models simpler,
with less duplication.

E.g. I also see that it makes it easier for a client to fetch all
of the information associated with a particular feature in a
single sub tree rather that needing to merge data from two
separate config & state sub trees.


This is your opinion.
I think separate makes it easier to read, especially if the monitoring 
data

is relevant regardless of how associated configuration was done.
This is easily achievable by filtering (e.g. only return config false 
leaves + config true structural nodes).







Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary
configuration mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

I thought that it was config that was originally driving YANG
because there is already a solution for state data (SNMP).  Hence,
I would have thought that the most common case would be that YANG
is used just for config, or config & state.  So, I think that it
makes sense to optimize models for these scenarios.



This is marketing.
Do you have any technical arguments?
Yes, I gave them below: I don't see that merging config and state 
prevents entities from only monitoring state if they wish.


Thanks,
Rob






If you forbid separate monitoring subtrees and force the data to
be co-located
with configuration, that means the standard monitoring will not
be supported
unless the standard configuration is also supported.

Both datastore draft solutions allow for system created config
entries.  So in both drafts the operational state datastore can
instantiate whatever config nodes are necessary to parent config
false state nodes.

I also don't think that separate monitoring subtrees are going to
be banned, they should be used where appropriate.  It is just that
it will be no longer be required to have separate state subtrees
purely because of potential differences in the lifetime of config
vs state objects (e.g. interfaces vs interfaces-state).

I would be very happy if "interfaces" and "interfaces-state" could
be merged into "interfaces" as a new/updated interfaces YANG model
that draft models could be updated to use.  I understand that
would be a impactful change to make (but seemingly mostly on IETF
models that haven't yet been standardized).  But I hope that we
are going to have to live with the YANG model structure for a long
time, and if we still have an opportunity to "fix" a fairly big
wart then I think that it would be good to do so.


I can't say if the pre-provisioning model in ietf-interfaces should be 
generalized.

I have not seen any good general solutions for combining config and state.




Rob


Andy



  Why is that progress?


Andy




___
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] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Tue, Jul 12, 2016 at 9:56 AM, Acee Lindem (acee) <a...@cisco.com> wrote:

>
>
> From: Andy Bierman <a...@yumaworks.com>
> Date: Tuesday, July 12, 2016 at 12:38 PM
> To: Acee Lindem <a...@cisco.com>
> Cc: Lou Berger <lber...@labn.net>, netmod WG <netmod@ietf.org>
> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG
> Model Structure
>
>
>
> On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) <a...@cisco.com>
> wrote:
>
>> Hi Andy,
>>
>> From: Andy Bierman <a...@yumaworks.com>
>> Date: Tuesday, July 12, 2016 at 12:17 PM
>> To: Lou Berger <lber...@labn.net>
>> Cc: Acee Lindem <a...@cisco.com>, netmod WG <netmod@ietf.org>
>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG
>> Model Structure
>>
>>
>>
>> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net> wrote:
>>
>>> Acee,
>>>
>>> I personally was assuming we'd follow 3, but I'd like to understand
>>> the implication of 2 as I'm not sure I really understand what you're
>>> thinking here.  Can you elaborate what you're thinking here?
>>>
>>> Thanks,
>>>
>>> Lou
>>> .
>>> >   3. #2 plus collapse the config (read-write) and  system-state
>>> > (read-only) into common containers. No more branching of
>>> > -config and -state at the top level of the
>>> model.
>>> >.
>>
>>
>>
>> I would really like to understand what problem (3) is supposed to solve.
>>
>> Most of the foo-state variables are for monitoring.
>> This information is useful even if the server uses proprietary
>> configuration mechanisms.
>> (e.g., the way the SNMP world has worked for 30 years)
>>
>> If you forbid separate monitoring subtrees and force the data to be
>> co-located
>> with configuration, that means the standard monitoring will not be
>> supported
>> unless the standard configuration is also supported.
>>
>>
>> If they are meant to be supported independently, why wouldn’t they be
>> separate models?
>>
>>
>
> YANG features can be used and they can still be supported independently.
>
>
> True - but I have not run across a model featured at the config/state
> branch.
>
>
Can you answer the question "What problem is created by having separate
configuration
and monitoring subtrees?"

Seems like an RPC-based opstate solution does not depend on this change,
so why is it being proposed?


Acee
>
>
>
Andy


>
>
>
>
>> Thanks,
>> Acee
>>
>>
> Andy
>
>
>>
>> Why is that progress?
>>
>>
>> Andy
>>
>>
>>
>>
>>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton]

Hi Andy,


On 12/07/2016 17:17, Andy Bierman wrote:



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger > wrote:


Acee,

I personally was assuming we'd follow 3, but I'd like to
understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of
the model.
>.



I would really like to understand what problem (3) is supposed to solve.
My personal view is that I think that it makes the models simpler, with 
less duplication.


E.g. I also see that it makes it easier for a client to fetch all of the 
information associated with a particular feature in a single sub tree 
rather that needing to merge data from two separate config & state sub 
trees.




Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary 
configuration mechanisms.

(e.g., the way the SNMP world has worked for 30 years)
I thought that it was config that was originally driving YANG because 
there is already a solution for state data (SNMP).  Hence, I would have 
thought that the most common case would be that YANG is used just for 
config, or config & state.  So, I think that it makes sense to optimize 
models for these scenarios.




If you forbid separate monitoring subtrees and force the data to be 
co-located
with configuration, that means the standard monitoring will not be 
supported

unless the standard configuration is also supported.
Both datastore draft solutions allow for system created config entries.  
So in both drafts the operational state datastore can instantiate 
whatever config nodes are necessary to parent config false state nodes.


I also don't think that separate monitoring subtrees are going to be 
banned, they should be used where appropriate.  It is just that it will 
be no longer be required to have separate state subtrees purely because 
of potential differences in the lifetime of config vs state objects 
(e.g. interfaces vs interfaces-state).


I would be very happy if "interfaces" and "interfaces-state" could be 
merged into "interfaces" as a new/updated interfaces YANG model that 
draft models could be updated to use.  I understand that would be a 
impactful change to make (but seemingly mostly on IETF models that 
haven't yet been standardized).  But I hope that we are going to have to 
live with the YANG model structure for a long time, and if we still have 
an opportunity to "fix" a fairly big wart then I think that it would be 
good to do so.


Rob


  Why is that progress?


Andy




___
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] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 12:38 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Lou Berger <lber...@labn.net<mailto:lber...@labn.net>>, netmod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Andy,

From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 12:17 PM
To: Lou Berger <lber...@labn.net<mailto:lber...@labn.net>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, netmod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger 
<lber...@labn.net<mailto:lber...@labn.net>> wrote:
Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>.


I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration 
mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.

If they are meant to be supported independently, why wouldn’t they be separate 
models?



YANG features can be used and they can still be supported independently.

True - but I have not run across a model featured at the config/state branch.

Acee





Thanks,
Acee


Andy


Why is that progress?


Andy




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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) <a...@cisco.com> wrote:

> Hi Andy,
>
> From: Andy Bierman <a...@yumaworks.com>
> Date: Tuesday, July 12, 2016 at 12:17 PM
> To: Lou Berger <lber...@labn.net>
> Cc: Acee Lindem <a...@cisco.com>, netmod WG <netmod@ietf.org>
> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG
> Model Structure
>
>
>
> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net> wrote:
>
>> Acee,
>>
>> I personally was assuming we'd follow 3, but I'd like to understand
>> the implication of 2 as I'm not sure I really understand what you're
>> thinking here.  Can you elaborate what you're thinking here?
>>
>> Thanks,
>>
>> Lou
>> .
>> >   3. #2 plus collapse the config (read-write) and  system-state
>> > (read-only) into common containers. No more branching of
>> > -config and -state at the top level of the
>> model.
>> >.
>
>
>
> I would really like to understand what problem (3) is supposed to solve.
>
> Most of the foo-state variables are for monitoring.
> This information is useful even if the server uses proprietary
> configuration mechanisms.
> (e.g., the way the SNMP world has worked for 30 years)
>
> If you forbid separate monitoring subtrees and force the data to be
> co-located
> with configuration, that means the standard monitoring will not be
> supported
> unless the standard configuration is also supported.
>
>
> If they are meant to be supported independently, why wouldn’t they be
> separate models?
>
>

YANG features can be used and they can still be supported independently.



> Thanks,
> Acee
>
>
Andy


>
> Why is that progress?
>
>
> Andy
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

Hi Andy,

From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Tuesday, July 12, 2016 at 12:17 PM
To: Lou Berger <lber...@labn.net<mailto:lber...@labn.net>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, netmod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model 
Structure



On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger 
<lber...@labn.net<mailto:lber...@labn.net>> wrote:
Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou
.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>.


I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration 
mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.

If they are meant to be supported independently, why wouldn’t they be separate 
models?

Thanks,
Acee


Why is that progress?


Andy



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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman]

On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger  wrote:

> Acee,
>
> I personally was assuming we'd follow 3, but I'd like to understand
> the implication of 2 as I'm not sure I really understand what you're
> thinking here.  Can you elaborate what you're thinking here?
>
> Thanks,
>
> Lou
> .
> >   3. #2 plus collapse the config (read-write) and  system-state
> > (read-only) into common containers. No more branching of
> > -config and -state at the top level of the model.
> >.



I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary
configuration mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be
co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.  Why is that progress?


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

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Lou Berger]

Acee,

I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou

On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
> While there are details to be worked out between the two data stores
> models (as indicated below), we now have implicit modeling of applied
> configuration. Existing models (both standard and draft) do not take this
> into consideration and, consequently, much of the state that is modeled
> explicitly represents the application configuration. For the RFC models,
> it probably doesn’t make much sense to redo them (unless they are being
> reworked for other reasons). This still leaves the existing WG draft
> models for which we have basically 3 options:
>
>   1. Do nothing - allow them proceed as they are with multiple ways of
> representing the applied configuration. This would provide visibility to
> the data independent of whether or not the device supported the revised
> data-stores supporting implicit retrieval of the applied configuration.
>   2. Prune out the redundant data nodes except those required as list
> keys, etc, since they can be obtained from the applied state data store.
>   3. #2 plus collapse the config (read-write) and  system-state
> (read-only) into common containers. No more branching of
> -config and -state at the top level of the model.
>
> At I high-level, I feel these are the options. I’m not married to any one
> of these and the worse thing we could do is hold up progression of the
> existing YANG model drafts for another couple years while we debate the
> best course. Having said that, #3 is compelling since it will yield the
> most concise models and colocates the schema data nodes for any managed
> object. 
>
> Thanks,
> Acee 
>
> On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
>  wrote:
>
>> All,
>>
>> It's time to make a consensus call on this topic, so that we can all move
>> on to defining a solution and aligning modules under development. Based
>> on the feedback received and the overall discussions on the topic, we see
>> that there is consensus to follow a datastore based approach to
>> supporting operational state, i.e., direction 'B'.
>>
>> We will be asking the authors of [4] and [5] to review their proposals
>> (individual drafts) in Berlin, as well as to highlight differences and
>> suggest ways that their work could be consolidated. Of course, others may
>> also choose to submit their own proposals. Given the importance of this
>> work, we will be looking to have active discussion on the topic both in
>> Berlin and on the list, with an objective of having a draft ready for
>> considerations as a WG document by the November IETF.
>>
>> We have reviewed this decision with our AD and the NetConf chairs and
>> have agreed to begin this work in NetMod. We certainly expect to
>> coordinate the work with the NetConf WG and re-home work as/if needed.
>>
>> Finally, we'd also like to thank all those who have contributed to this
>> discussion to date, from problem identification to proposed solutions,
>> and we look forward to your continued efforts to publish a standard
>> solution. 
>>
>> Lou (and Kent)
>>
>>
>> On 6/7/2016 10:19 AM, Lou Berger wrote:
>>> All,
>>>
>>> We want to provide an update based on the off line discussions
>>> related to OpState Solutions that we have been having and solicit
>>> input from the WG.
>>>
>>> All authors of current solution drafts [1,2,3] together with those
>>> who helped conduct the solutions analysis* were invited to the these
>>> discussions -- with the objective of coming up with a single
>>> consolidated proposal to bring to the WG. (I/Lou acted as facilitator
>>> as Kent and Juergen were and are involved with the technical details.)
>>>
>>> The discussions have yielded some results but, unfortunately,
>>> not a single consolidated proposal as hoped, but rather two
>>> alternate directions -- and clearly we need to choose one:
>>>
>>> 1) Adopt the conventions for representing state/config
>>>based on Section 6 of [1].
>>>
>>>From a model definition perspective, these conventions
>>>impact every model and every model writer.
>>>
>>> 2) Model OpState using a revised logical datastore definition
>>>as introduced in [4] and also covered in [5]. There is
>>>also a variant of this that we believe doesn't significantly
>>>impact this choice.
>>>
>>>With this approach, model definitions need no explicit
>>>changes to support applied configuration.
>>>
>>> >From a technology/WG standpoint, we believe an approach
>>> that doesn't impact every model written (i.e., #2) is superior.
>>> The counterpoint to this is that the conventions based
>>> approach (i.e., #1) is available today and being followed in
>>> OpenConfig defined models.
>>>

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Acee Lindem (acee)]

Hi Lou, 
I’m not advocating this #2. If you are going to rely on the revised data
stores to obtain the information, you should go all the way to #3. For
example, based on the control-plane-protocols in routing-cfg, we have
separate top level containers for config state.

 +--rw routing
  +--rw router-id?
  +--rw control-plane-protocols
  |  +--rw control-plane-protocol* [type name]


And:
+— ro routing-state
  +--ro router-id?
  +--ro interfaces
  |  +--ro interface*
  +--ro control-plane-protocols
  |  +--ro control-plane-protocol* [type name]
  | +--ro type
  | +--ro name


The control plane protocols augment these two lists separately. With #2,
we leave the bifurcated structure and simply remove the data nodes that
are not needed from the protocol state.

Thanks,
Acee 

On 7/12/16, 11:23 AM, "Lou Berger"  wrote:

>Acee,
>
>I personally was assuming we'd follow 3, but I'd like to understand
>the implication of 2 as I'm not sure I really understand what you're
>thinking here.  Can you elaborate what you're thinking here?
>
>Thanks,
>
>Lou
>
>On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
>> While there are details to be worked out between the two data stores
>> models (as indicated below), we now have implicit modeling of applied
>> configuration. Existing models (both standard and draft) do not take
>>this
>> into consideration and, consequently, much of the state that is modeled
>> explicitly represents the application configuration. For the RFC models,
>> it probably doesn’t make much sense to redo them (unless they are being
>> reworked for other reasons). This still leaves the existing WG draft
>> models for which we have basically 3 options:
>>
>>   1. Do nothing - allow them proceed as they are with multiple ways of
>> representing the applied configuration. This would provide visibility to
>> the data independent of whether or not the device supported the revised
>> data-stores supporting implicit retrieval of the applied configuration.
>>   2. Prune out the redundant data nodes except those required as list
>> keys, etc, since they can be obtained from the applied state data store.
>>   3. #2 plus collapse the config (read-write) and  system-state
>> (read-only) into common containers. No more branching of
>> -config and -state at the top level of the
>>model.
>>
>> At I high-level, I feel these are the options. I’m not married to any
>>one
>> of these and the worse thing we could do is hold up progression of the
>> existing YANG model drafts for another couple years while we debate the
>> best course. Having said that, #3 is compelling since it will yield the
>> most concise models and colocates the schema data nodes for any managed
>> object. 
>>
>> Thanks,
>> Acee 
>>
>> On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
>>  wrote:
>>
>>> All,
>>>
>>> It's time to make a consensus call on this topic, so that we can all
>>>move
>>> on to defining a solution and aligning modules under development. Based
>>> on the feedback received and the overall discussions on the topic, we
>>>see
>>> that there is consensus to follow a datastore based approach to
>>> supporting operational state, i.e., direction 'B'.
>>>
>>> We will be asking the authors of [4] and [5] to review their proposals
>>> (individual drafts) in Berlin, as well as to highlight differences and
>>> suggest ways that their work could be consolidated. Of course, others
>>>may
>>> also choose to submit their own proposals. Given the importance of this
>>> work, we will be looking to have active discussion on the topic both in
>>> Berlin and on the list, with an objective of having a draft ready for
>>> considerations as a WG document by the November IETF.
>>>
>>> We have reviewed this decision with our AD and the NetConf chairs and
>>> have agreed to begin this work in NetMod. We certainly expect to
>>> coordinate the work with the NetConf WG and re-home work as/if needed.
>>>
>>> Finally, we'd also like to thank all those who have contributed to this
>>> discussion to date, from problem identification to proposed solutions,
>>> and we look forward to your continued efforts to publish a standard
>>> solution. 
>>>
>>> Lou (and Kent)
>>>
>>>
>>> On 6/7/2016 10:19 AM, Lou Berger wrote:
 All,

 We want to provide an update based on the off line discussions
 related to OpState Solutions that we have been having and solicit
 input from the WG.

 All authors of current solution drafts [1,2,3] together with those
 who helped conduct the solutions analysis* were invited to the these
 discussions -- with the objective of coming up with a single
 consolidated proposal to bring to the WG. (I/Lou acted as facilitator
 as Kent and Juergen were and are involved with the technical details.)

 The discussions have yielded some results but, unfortunately,
 not a single