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

[Anees Shaikh <[e-mail]>]

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) <[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]>
> Date: Tuesday, May 12, 2015 at 4:56 PM
> To: Routing YANG <[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]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>