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

[Anees Shaikh <[e-mail]>]

Xufeng, thanks -- my responses below.

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

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

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.


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

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.




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