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

[Xufeng Liu <[e-mail]>]

Hi Anees,

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

Best,

- Xufeng

From: Anees Shaikh [mailto:[e-mail]]
Sent: Wednesday, May 13, 2015 3:52 AM
To: Acee Lindem (acee)
Cc: Xufeng Liu; [e-mail]
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.

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

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.
[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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, May 12, 2015 at 4:56 PM
To: Routing YANG <[e-mail]<mailto:[e-mail]>>
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


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