Subject: Re: [Rtg-yang-coord] Operational State Modeling

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 May 2015 21:26:33 +0000

Hi Xufeng,

My interpretation of the OpenConfig draft is that it recommends option 1. Actually, option 3 seems like a variation of 1 with some superfluous levels.

Thanks,
Acee

From: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 12, 2015 at 4:56 PM
To: Routing YANG <[email-masked]<mailto:[email-masked]>>
Subject: [Rtg-yang-coord] Operational State Modeling

During the YANG MPLS/TE design team discussions, the topic of operational state modeling was brought up. We discussed the proposal presented in http://www.ietf.org/id/draft-openconfig-netmod-opstate-00.txt and some various approaches. Here are some thoughts and questions.
1.    Requirements
We agree with the requirements presented in draft-openconfig-netmod-opstate. These requirements are summarized as followings.
1.1.Performance Requirement

·            Operational state access is much more frequent than configuration

·            State data is generally higher volume than configuration data

1.2.Data Type Requirements

·            Representing intended configuration (actual vs. configured)

·            Derived, negotiated, and system assigned data

·            Counters or statistics

1.3.Operation Requirements

·            Separate configuration and operational state data

·            Retrieve configuration and operational state data independently

·            Retrieve derived state and statistics state independently

·            Consistent schema locations for configuration and corresponding operational state data

2.    Some Options
2.1.Option 1

/routing/routing-instance:

   +--rw te!

      +--rw globals

      +--rw interfaces

      |  +--rw interface* [interface]

      |     +--rw interface                 if:interface-ref

            +--rw config

      |        +--rw switching-capabilities* [switching-capability]

                  +--rw config

      |           |  +--rw capability?   identityref

      |          |  +--rw encoding?     identityref

                  +--ro state

      |              +--ro capability?   identityref

      |             +--ro encoding?     identityref

      |        +--rw te-metric?                ietf-te-types:te-metric

            +--ro state

      |        +--ro te-metric?                ietf-te-types:te-metric

               +--ro oper-status?            enumeration

               +--ro counters

                     +--ro pkts-sent?              yang:counter32

      +--rw tunnels

         +--rw tunnel* [name type]

            +--rw name                    string

            +--rw config

               |  +--rw admin-status?           identityref

            |  +--rw forwarding

                  +--rw config

            |        +--rw load-share?   uint32

                  +--ro state

            |        +--ro load-share?   uint32

            +--ro state

                  +--ro admin-status?           identityref

               +--ro oper-status?            enumeration

               +--ro counters

                  +--ro events?              yang:counter32

2.2.Option 2

/routing/routing-instance:

   +--rw te!

      +--rw globals

      +--rw interfaces

      |  +--rw interface* [interface]

      |     +--rw interface                 if:interface-ref

      |     +--rw switching-capabilities* [switching-capability]

      |     |  +--rw capability?   identityref

      |     |  +--rw encoding?     identityref

      |     +--rw te-metric?                ietf-te-types:te-metric

      +--rw tunnels

         +--rw tunnel* [name type]

            +--rw name                    string

            +--rw admin-status?           identityref

            +--rw forwarding

               +--rw load-share?   uint32

/routing-state/routing-instance:

   +--ro te!

      +--ro globals

      +--ro interfaces

      |  +--ro interface* [interface]

      |     +--ro interface                 if:interface-ref

      |     +--ro switching-capabilities* [switching-capability]

      |     |  +--ro capability?   identityref

      |     |  +--ro encoding?     identityref

      |     +--ro te-metric?                ietf-te-types:te-metric

            +--ro oper-status?            enumeration

            +--ro counters

               +--ro pkts-sent?              yang:counter32

      +--ro tunnels

         +--ro tunnel* [name type]

            +--ro name                    string

            +--ro admin-status?           identityref

            +--ro forwarding

               +--ro load-share?   uint32

            +--ro oper-status?            enumeration

            +--ro counters

               +--ro events?              yang:counter32

2.3.Option 3

/routing/routing-instance:

   +--rw te!

      +--rw globals

      +--rw interfaces

      |  +--rw interface* [interface]

      |     +--rw interface                 if:interface-ref

            +--rw config

      |        +--rw switching-capabilities* [switching-capability]

                  +--rw config

      |           |  +--rw capability?   identityref

      |          |  +--rw encoding?     identityref

                  +--ro state

      |              +--ro capability?   identityref

      |             +--ro encoding?     identityref

      |        +--rw te-metric?                ietf-te-types:te-metric

            +--ro state

      |        +--ro te-metric?                ietf-te-types:te-metric

      +--rw tunnels

         +--rw tunnel* [name type]

            +--rw name                    string

            +--rw config

               |  +--rw admin-status?           identityref

            |  +--rw forwarding

                  +--rw config

            |        +--rw load-share?   uint32

                  +--ro state

            |        +--ro load-share?   uint32

            +--ro state

               +--ro admin-status?           identityref

/routing-state/routing-instance:

   +--ro te!

      +--ro globals

      +--ro interfaces

      |  +--ro interface* [interface]

      |     +--ro interface                 if:interface-ref

            +--ro oper-status?            enumeration

            +--ro counters

               +--ro pkts-sent?              yang:counter32

      +--ro tunnels

         +--ro tunnel* [name type]

            +--ro name                    string

            +--ro oper-status?            enumeration

            +--ro counters

               +--ro events?              yang:counter32

3.    Approach Rationales
1.1.Performance Requirement

·            Separating configuration and state branches allows implementing state data through a separate fast channel to deliver high frequent and high volume data.

·            In this aspect, Option 2 has a clearer separation between configuration and state data, and easier to achieve better performance by using separate channels.

1.2.Data Type Requirements

·            Duplicating all configuration attributes makes actual configuration settings available

·            Derived, negotiated, and system assigned data are added to the state branch

·            Counters or statistics are added to the state branch

·            All three options satisfy these requirements

1.3.Operation Requirements

·            Separating configuration and operational state data allows retrieving configuration and operational state data independently.

·            Separating derived state and statistics state allows retrieving them independently

·            The state branch is an exact mirror of the configuration branch, so the schema locations are consistent.

·            In this aspect, all three options satisfy the requirements. For option 1, to check the state value for a specific configuration attribute, the client software can simply add the “state” to the end of the schema node path. For option 2, to check the state value for a specific configuration attribute, the client software can simply add the “-state” suffix to the name of the top container. Option 1 seems to be easiest in this regard, but others are acceptable?

1.4.Other Requirements

·             Model system created read-only objects (e.g. TE tunnels). When state data and config data share the same parent, they share the same key for the parent list. Even though that the state branch is read-only, its parent is not and the key of the parent is not. Therefore, we will have difficulty to achieve this in Option 1.

·             Compatible with the existing models. The related models include RFC7223, RFC7277 and draft-ietf-netmod-routing-cfg-18. In this aspect, Option 2 seems to do better.

Your comments and preferences are appreciated.
Thanks,

- Xufeng

---

From: Anees Shaikh <[email-masked]>
Date: Wed, 13 May 2015 00:51:41 -0700

Xufeng, thanks very much for taking the time to do this systematic analysis
-- much appreciated.   We've also talked to a subset of the MPLS/TE DT just
today about opstate to reiterate the reasons for the OpenConfig proposal.
I will just comment on your rationale section.

1.1 Performance requirements

Implementations today already support the retrieval of operational state
and configuration data together.  In fact, platforms that support NETCONF
would need to handle both simultaneously in a <get> request.  The
<get-config> request does not return opstate at all.  There is no option
today for <get-operational> to retrieve only state (though our draft
proposes, or more accurately, re-proposes it).  The performance
implications may be due to the datastore design for the different types of
data, but where the data lives in the *schema* should not have a major
impact on the performance to read it.  In other words, if you accept the
requirement that configuration needs to be part of state (which you seem to
in the beginning of the note), then the location in the schema really
shouldn't matter.  It does matter for other reasons (see below).

1.2 Data type requirements -- agree with your conclusions

1.3 Operation requirements

You mention, "*For option 2, to check the state value for a specific
configuration attribute, the client software can simply add the “-state”
suffix to the name of the top container*"

The question that this doesn't answer is what is the top container?  It may
be clear in an individual model, but I don't manage a device using just
routing, or just interfaces.  I want to compose a set of models into a
coherent whole and be able to access config and corresponding state in a
consistent way.  When I compose the models, what I thought was the "top"
container is no longer top -- it shows up somewhere in the middle, and my
paths are now totally dependent on how modelers have decided to combine or
separate their individual models and modules.  From our perspective, option
2 doesn't meet this requirement.  Rather than debate what the real top of a
usable model is, we take the approach of pushing the separation to leaves
of the tree, which works no matter how models are composed structurally.

1.4 Other requirements

Regarding system-created tunnels, why is it necessary to consider them part
of read-only state?  I can just as well consider them as configured, only
they are configured by some agent on the system -- they should in fact be
configured using the same mechanism as a tunnel configured by an operator.
  If they are not writable, *and you want to enforce this in the model*,
they could show up in only the state part of the tree -- I agree this does
raise the issue with list keys that you mention.  But list keys (and lists
in general) are a bit broken in YANG 1.0/1.1 as we explain briefly in the
draft.  We can discuss the issues with lists in a separate thread given
more time.

Regarding compatibility with existing models, I really don't agree at all
that the existing RFC models should constrain what we do when trying to
meet the requirements of people trying to build real systems that use YANG
models.    With all respect to the authors of those few models (which we
leverage considerably in our models), YANG models are software code, and
should be treated as such IMO.  We don't say that software is "done" and
can't change -- it evolves and improves over time, sometimes in
non-backward-compatible ways.  And we don't issue a final version of
software without considerable experience using and testing it in production.

thanks.
-- Anees

On Tue, May 12, 2015 at 2:26 PM, Acee Lindem (acee) <[email-masked]> wrote:

>  Hi Xufeng,
>
>  My interpretation of the OpenConfig draft is that it recommends option
> 1. Actually, option 3 seems like a variation of 1 with some superfluous
> levels.
>
>  Thanks,
> Acee
>
>   From: Xufeng Liu <[email-masked]>
> To: Routing YANG <[email-masked]>
>    During the YANG MPLS/TE design team discussions, the topic of
> operational state modeling was brought up. We discussed the proposal
> presented in http://www.ietf.org/id/draft-openconfig-netmod-opstate-00.txt
> and some various approaches. Here are some thoughts and questions.
> 1.    Requirements
>
> We agree with the requirements presented in
> draft-openconfig-netmod-opstate. These requirements are summarized as
> followings.
> 2.    Some Options 2.1.Option 1
>
>
>
>                   *+--ro state*
> *      |              +--ro capability?   identityref*
>
> *      |             +--ro encoding?     identityref*
>
>             *+--ro state*
> *      |        +--ro te-metric?                ietf-te-types:te-metric*
>
> *                  +--ro state*
> *            |        +--ro load-share?   uint32*
>
> *            +--ro state*
>
> *                  +--ro admin-status?           identityref*
>
> *      |     +--ro switching-capabilities* [switching-capability]*
>
> *      |     |  +--ro capability?   identityref*
>
> *      |     |  +--ro encoding?     identityref*
>
> *      |     +--ro te-metric?                ietf-te-types:te-metric*
>
> *            +--ro admin-status?           identityref*
>
> *            +--ro forwarding*
>
> *               +--ro load-share?   uint32*
>
> *                  +--ro state*
> *      |              +--ro capability?   identityref*
>
> *      |             +--ro encoding?     identityref*
>
> *            +--ro state*
> *      |        +--ro te-metric?                ietf-te-types:te-metric*
>
>       +--rw tunnels
>
> *                  +--ro state*
> *            |        +--ro load-share?   uint32*
>
>             *+--ro state*
>
> *               +--ro admin-status?           identityref*
>
>
>
> 3.    Approach Rationales 1.1.Performance Requirement
>
> ·            Separating configuration and state branches allows
> implementing state data through a separate fast channel to deliver high
> frequent and high volume data.
>
> ·            In this aspect, Option 2 has a clearer separation between
> configuration and state data, and easier to achieve better performance by
> using separate channels.
> ·            Separating configuration and operational state data allows
> retrieving configuration and operational state data independently.
>
> ·            The state branch is an exact mirror of the configuration
> branch, so the schema locations are consistent.
>
> ·            In this aspect, all three options satisfy the requirements.
> For option 1, to check the state value for a specific configuration
> attribute, the client software can simply add the “state” to the end of the
> schema node path. For option 2, to check the state value for a specific
> configuration attribute, the client software can simply add the “-state”
> suffix to the name of the top container. Option 1 seems to be easiest in
> this regard, but others are acceptable?
> 1.4.Other Requirements
>
> ·             Model system created read-only objects (e.g. TE tunnels).
> When state data and config data share the same parent, they share the same
> key for the parent list. Even though that the state branch is read-only,
> its parent is not and the key of the parent is not. Therefore, we will have
> difficulty to achieve this in Option 1.
>
> ·             Compatible with the existing models. The related models
> include RFC7223, RFC7277 and draft-ietf-netmod-routing-cfg-18. In this
> aspect, Option 2 seems to do better.
>
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 May 2015 12:35:11 +0200

> software without considerable experience using and testing it in production.

Standards and software are not the same. The value of standards is
that they provide a stable basis. In other words, the value of
standards is that they do not change every other day. Yes, you can
rewrite standardized data models but the cost of doing so is high and
hence the benefit of rewriting something must be high. I do not see
this here - not even remotely.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 13 May 2015 09:13:37 -0400

Speaking as an individual, while what Juergen says is true, that does not mean that existing models can never be refactored. 

	—Tom

> On May 13, 2015:6:35 AM, at 6:35 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 May 2015 09:04:09 -0700

> this here - not even remotely.

+1

YANG already has a config-stmt to identify configuration nodes.
Extra non-presence containers throughout the data model
for "config" and "state" adds clutter and extra complexity.

Replication of data nodes increases implementation costs.
The association between "turn a config knob here" and
"observe a state change there" is usually more complex than
this draft supports.

> /js

Andy

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 13 May 2015 21:39:11 +0000

Hi Anees,

Thanks for the replies. Have a couple of comments below.

Best,

- Xufeng

From: Anees Shaikh [mailto:[email-masked]]
Sent: Wednesday, May 13, 2015 3:52 AM
To: Acee Lindem (acee)
Cc: Xufeng Liu; [email-masked]
Subject: Re: [Rtg-yang-coord] Operational State Modeling

Xufeng, thanks very much for taking the time to do this systematic analysis -- much appreciated.   We've also talked to a subset of the MPLS/TE DT just today about opstate to reiterate the reasons for the OpenConfig proposal.  I will just comment on your rationale section.

Implementations today already support the retrieval of operational state and configuration data together.  In fact, platforms that support NETCONF would need to handle both simultaneously in a <get> request.  The <get-config> request does not return opstate at all.  There is no option today for <get-operational> to retrieve only state (though our draft proposes, or more accurately, re-proposes it).  The performance implications may be due to the datastore design for the different types of data, but where the data lives in the *schema* should not have a major impact on the performance to read it.  In other words, if you accept the requirement that configuration needs to be part of state (which you seem to in the beginning of the note),
[Xufeng] Even though the same config attributes appear in the state branch, they may not be taken from the configuration database, but taken from internal memory so as to retrieve the applied or negotiated values.
then the location in the schema really shouldn't matter.  It does matter for other reasons (see below).

You mention, "For option 2, to check the state value for a specific configuration attribute, the client software can simply add the “-state” suffix to the name of the top container"

The question that this doesn't answer is what is the top container?  It may be clear in an individual model, but I don't manage a device using just routing, or just interfaces.  I want to compose a set of models into a coherent whole and be able to access config and corresponding state in a consistent way.  When I compose the models, what I thought was the "top" container is no longer top -- it shows up somewhere in the middle, and my paths are now totally dependent on how modelers have decided to combine or separate their individual models and modules.  From our perspective, option 2 doesn't meet this requirement.  Rather than debate what the real top of a usable model is, we take the approach of pushing the separation to leaves of the tree, which works no matter how models are composed structurally.
[Xufeng] I’d like to see an example of your composed structure. Currently YANG does not allow you to mount a schema tree to another location. If it were allowed, the mounting process would be possible to process the split point and relocate it to the top.

1.4 Other requirements

Regarding system-created tunnels, why is it necessary to consider them part of read-only state?  I can just as well consider them as configured, only they are configured by some agent on the system -- they should in fact be configured using the same mechanism as a tunnel configured by an operator.   If they are not writable, *and you want to enforce this in the model*, they could show up in only the state part of the tree -- I agree this does raise the issue with list keys that you mention.  But list keys (and lists in general) are a bit broken in YANG 1.0/1.1 as we explain briefly in the draft.  We can discuss the issues with lists in a separate thread given more time.
[Xufeng] I think that the proposed list key change is rather dramatic. Our model would better be based on the current YANG version. I’d not want to want to have a model base on a non-existing feature.

Regarding compatibility with existing models, I really don't agree at all that the existing RFC models should constrain what we do when trying to meet the requirements of people trying to build real systems that use YANG models.    With all respect to the authors of those few models (which we leverage considerably in our models), YANG models are software code, and should be treated as such IMO.  We don't say that software is "done" and can't change -- it evolves and improves over time, sometimes in non-backward-compatible ways.  And we don't issue a final version of software without considerable experience using and testing it in production.

thanks.
-- Anees

On Tue, May 12, 2015 at 2:26 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Xufeng,

Thanks,
Acee

·            Counters or statistics

2.    Some Options
2.1.Option 1

   +--rw te!

      +--rw globals

      +--rw interfaces

            +--rw config

                  +--rw config

                  +--ro state

            +--ro state

               +--ro counters

      +--rw tunnels

            +--rw name                    string

            +--rw config

            |  +--rw forwarding

                  +--rw config

                  +--ro state

            +--ro state

               +--ro counters

2.2.Option 2

   +--rw te!

      +--rw globals

      +--rw interfaces

      +--rw tunnels

            +--rw name                    string

            +--rw forwarding

               +--rw load-share?   uint32

   +--ro te!

      +--ro globals

      +--ro interfaces

            +--ro counters

      +--ro tunnels

            +--ro name                    string

            +--ro forwarding

               +--ro load-share?   uint32

            +--ro counters

2.3.Option 3

   +--rw te!

      +--rw globals

      +--rw interfaces

            +--rw config

                  +--rw config

                  +--ro state

            +--ro state

      +--rw tunnels

            +--rw name                    string

            +--rw config

            |  +--rw forwarding

                  +--rw config

                  +--ro state

            +--ro state

   +--ro te!

      +--ro globals

      +--ro interfaces

            +--ro counters

      +--ro tunnels

            +--ro name                    string

            +--ro counters

3.    Approach Rationales

1.4.Other Requirements

- Xufeng

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

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 13 May 2015 22:01:06 +0000

Agree that standards need to be stable, and can be refactored if necessary.

From the perspective of these models, implementations need to put them together in a compatible way. If it is necessary to change them, they need to be changed coordinately.

- Xufeng

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Wednesday, May 13, 2015 9:14 AM
> To: Juergen Schoenwaelder
> Cc: Anees Shaikh; [email-masked]; Acee Lindem (acee); Xufeng Liu
> 	Speaking as an individual, while what Juergen says is true, that does not
> mean that existing models can never be refactored.
> 
> 	—Tom
> 
> 
> > On May 13, 2015:6:35 AM, at 6:35 AM, Juergen Schoenwaelder
> >> Regarding compatibility with existing models, I really don't agree at
> >> all that the existing RFC models should constrain what we do when
> >> trying to meet the requirements of people trying to build real systems that
> use YANG
> >> leverage considerably in our models), YANG models are software code,
> >> and should be treated as such IMO.  We don't say that software is
> >> "done" and can't change -- it evolves and improves over time,
> >> sometimes in non-backward-compatible ways.  And we don't issue a
> >> final version of software without considerable experience using and testing it
> in production.
> >>
> >

---

From: aldrin ietf <[email-masked]>
Date: Thu, 14 May 2015 11:07:34 -0700

That is the case we are making with openconfig model.
Details are in the draft on why it is helpful from operational perspective.
One do not want to create standards which are not operationally effective.

-sam
> On May 13, 2015, at 6:13 AM, Thomas D. Nadeau <[email-masked]> wrote:
> 
>

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 14 May 2015 16:51:10 -0700

Xufeng, thanks -- my responses below.

On Wed, May 13, 2015 at 2:39 PM, Xufeng Liu <[email-masked]> wrote:

> *From:* Anees Shaikh [mailto:[email-masked]]
> *Sent:* Wednesday, May 13, 2015 3:52 AM
> *To:* Acee Lindem (acee)
> *Cc:* Xufeng Liu; [email-masked]
> *Subject:* Re: [Rtg-yang-coord] Operational State Modeling
>
>
>
> Xufeng, thanks very much for taking the time to do this systematic
> analysis -- much appreciated.   We've also talked to a subset of the
> MPLS/TE DT just today about opstate to reiterate the reasons for the
> OpenConfig proposal.  I will just comment on your rationale section.
>
>
>
> in the beginning of the note),
>
> *[Xufeng] Even though the same config attributes appear in the state
> branch, they may not be taken from the configuration database, but taken
> from internal memory so as to retrieve the applied or negotiated values. *
>

I agree that config-related state values may come from some alternate data
store but I'm not sure this changes the main point, i.e., that which
datastore the data comes from is separable from where it lies in the
schema.  And with NETCONF, assuming you'd want to support that model, there
is already the requirement to be able to return both configuration and
state.

> The question that this doesn't answer is what is the top container?  It
> may be clear in an individual model, but I don't manage a device using just
> *[Xufeng] I’d like to see an example of your composed structure. Currently
> YANG does not allow you to mount a schema tree to another location. If it
> were allowed, the mounting process would be possible to process the split
> point and relocate it to the top.*
>

Have a look at draft-openconfig-netmod-model-structure -- that doc
motivates the need for a composed model to represent an entire device, for
example, and a couple of options for doing the composition.  We don't need
to use mount points or anything special, just imports and/or augments.
Again, placing the config/state separation at the leaves of the tree avoids
the need to relocate anything when composing models.

>
> 1.4 Other requirements
>
>
>
> Regarding system-created tunnels, why is it necessary to consider them
> part of read-only state?  I can just as well consider them as configured,
> only they are configured by some agent on the system -- they should in fact
> be configured using the same mechanism as a tunnel configured by an
> operator.   If they are not writable, *and you want to enforce this in the
> model*, they could show up in only the state part of the tree -- I agree
> this does raise the issue with list keys that you mention.  But list keys
> (and lists in general) are a bit broken in YANG 1.0/1.1 as we explain
> briefly in the draft.  We can discuss the issues with lists in a separate
> thread given more time.
>
> *[Xufeng] I think that the proposed list key change is rather dramatic.
> Our model would better be based on the current YANG version. I’d not want
> to want to have a model base on a non-existing feature.*
>

Yes, agree that fixing YANG lists will take a while, but I would reiterate
that distinguishing elements that are configured by users vs. configured by
the system is a bit artificial.  And I'm not sure we want to be so
prescriptive in models so as to require system-configured items to be
read-only.  Some implementations may allow a user to reconfigure them.  I
would rather perhaps add a leaf that indicates the source of the config.

> My interpretation of the OpenConfig draft is that it recommends option 1.
> Actually, option 3 seems like a variation of 1 with some superfluous
> levels.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Xufeng Liu <[email-masked]>
> *Date: *Tuesday, May 12, 2015 at 4:56 PM
> *To: *Routing YANG <[email-masked]>
> *Subject: *[Rtg-yang-coord] Operational State Modeling
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 May 2015 10:52:28 +0200

> 	Speaking as an individual, while what Juergen says is true, that does not mean that existing models can never be refactored. 

Refactoring for the sake of 'it looks nicer' (for some definition of
nice) likely does not meet the bar. We are talking about APIs here
with multiple independent implementations and applications sitting on
top of these APIs.

/js

---

From: Christian Hopps <[email-masked]>
Date: Fri, 15 May 2015 09:34:10 -0400

> with multiple independent implementations and applications sitting on

Isn't the idea to create a common standard way to access state and
config? If so I don't think that qualifies as "it looks nicer", rather
it allows for creating generic code one time that works on any model
including as yet unwritten ones vs. custom code for each model.

Thanks,
Chris.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 May 2015 15:56:28 +0200

> On 15 May 2015, at 15:34, Christian Hopps <[email-masked]> wrote:
> 
> 

Well, the existing modules do propose a way to access state and config. It’s not perfect and perhaps some changes in YANG are needed as well in order to better support the interaction of config and state.

However, I agree with Juergen that the arguments presented so far in favour of leaf-level duplication aren’t very convincing. 

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 May 2015 16:30:50 +0200

> including as yet unwritten ones vs. custom code for each model.

If someone things get-state is needed, write an I-D for it. This is
not a big deal since NETCONF operations are extensible. Note that this
is not refactoring and fine.

That said, it is fairly easy to find out where the state data is
rooted in a YANG data model. Writing a script to find the state
root(s) of a data model is not a big deal.

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 May 2015 14:37:40 +0000

On 5/15/15, 9:56 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>>>> 	Speaking as an individual, while what Juergen says is true, that
>>>>does not mean that existing models can never be refactored.
>>>> 
>>> 
>Well, the existing modules do propose a way to access state and config.
>It’s not perfect and perhaps some changes in YANG are needed as well in
>order to better support the interaction of config and state.
>
>However, I agree with Juergen that the arguments presented so far in
>favour of leaf-level duplication aren’t very convincing.

If you look at the existing IGP draft models, the config state is also
present in the operational state so this proposal doesn’t represent
additional leaf nodes - just a change to the organization to place the
config and operational state adjacent to one another in the tree.

---

From: Nadeau Thomas <[email-masked]>
Date: Fri, 15 May 2015 12:14:17 -0400

I don’t think the open config guys are asking for refactoring for purely aesthetic reasons. These guys operate some of the world’s largest networks with tens of thousands of devices, so I’d hope that their asking to move things around is in order to make interacting with those things at that scale better.

	—Tom

> On May 15, 2015:4:52 AM, at 4:52 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 May 2015 09:28:43 -0700

>         I don’t think the open config guys are asking for refactoring for purely aesthetic reasons. These guys operate some of the world’s largest networks with tens of thousands of devices, so I’d…

I think Juergen and I and others are pointing out that it
would be better to solve this problem by adding an
operation to NETCONF.  RESTCONF already has the
ability to retrieve just "content=nonconfig".

Replicating config as operational state in all the data models
is not a good idea.  Using arbitrary NP containers called
"config" and "state" (instead of the YANG config-stmt)
is not a good idea.

Andy

---

From: aldrin ietf <[email-masked]>
Date: Fri, 15 May 2015 09:53:17 -0700

It is totally misconstrued and wrong to think it is being done for the looks. It is clearly outlined in the draft on ‘why?'(<http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/?include_text=1 <http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/?include_text=1>>. 

We, the operator community, are requesting for a reason as outlined in the draft, to make it operationally efficient, when managing network @scale.

-sam
 
> On May 15, 2015, at 9:14 AM, Nadeau Thomas <[email-masked]> wrote:
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 May 2015 19:10:37 +0200

> We, the operator community, are requesting for a reason as outlined in the draft, to make it operationally efficient, when managing network @scale.

I read this I-D and I agree to some what it says. To some of what it
says I tend to disagree. My main concern is that trying to infer
semantics from structure is

- brittle, and

- it is for me more than unlikely that all YANG models will follow a
  common structure.

I also do not see anything wrong with the approach taken by RFC 7223
and on the other hand I do see problems with the example shown in
section 4 of the I-D (interface/name points to config and hence state
is bound to the lifetime of config, a limitation RFC 7223 does not
have - you can actually see unconfigured interfaces).

The bottom line is that I do not subscribe to all requirements stated
in the I-D and I do not subscribe to the solutions proposed. Nor have
I seen something that clearly tells me the structure we used in RFC
7223 is broken.

/js

---

From: Nadeau Thomas <[email-masked]>
Date: Fri, 15 May 2015 13:11:22 -0400

> On May 15, 2015:12:28 PM, at 12:28 PM, Andy Bierman <[email-masked]> wrote:
> 
> ability to retrieve just "content=nonconfig”.

	This is reasonable option/solution.  What do the open config folks think?

> "config" and "state" (instead of the YANG config-stmt)

	I think you are saying that, but the others are clearly not, so we need to listen to their reasons before discounting them as less efficient. Remember that the operators are users not implementing these models so they need to understand if the boxes/servers they are using can do this and what the costs are. If after they weigh the relative costs, they feel the return on that investment in say RAM on those servers is ok, then we need to think carefully about why we would not want to support that.  Remember, even though you as a server/compiler vendor might think its not a great idea, they might be willing to pay the price for say memory, to store the operational state.

	—Tom

---

From: aldrin ietf <[email-masked]>
Date: Fri, 15 May 2015 15:47:58 -0700

> On May 15, 2015, at 10:11 AM, Nadeau Thomas <[email-masked]> wrote:
> 
> 
> 
Tom,

We are in continual discussions with various vendors. If there exists, issues related to this, I am sure they will be brought forth by them for discussion with the community at large. 

-sam