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

["Acee Lindem (acee)" <[e-mail]>]

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