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

From: Xufeng Liu <[email-masked]>
Date: Tue, 12 May 2015 20:56:04 +0000

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: "Russ White" <[email-masked]>
Date: Tue, 12 May 2015 17:17:22 -0400

> 2.1.Option 1

This is my least preferred option, because it seems to tie the existence of
any tunnels to their configuration in some way. There may well be TE tunnels
not configured by a local process, and yet you want to be able to see their
state (?). Given this, I would prefer one of the options that separates rw
from ro more cleanly.

:-)

Russ

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 May 2015 23:23:42 +0200

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

There are sometimes slight differences in the value sets of objects
and in the constraints that apply. A valid configuration may have to
follow certain constraints but the operational state must report the
truth (and that might include violations of constraints).
 
> *            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…

Several of data models published in RFCs use the

/foo
/foo-state

approach and unless someone finds a serious flaw or limitation, I
suggest to stick with this approach. I do not think it helps operators
if data models developed in different parts of the IETF use different
approaches unless there is a strong reason to do so.

> *             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 stat…

Yes, branching in the middle is a bad idea. People seem to rediscover
this. ;-)

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

Yep. It is as simple as 'follow the existing pattern'. ;-)

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