On Thu, Jan 12, 2017 at 4:47 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> Andy Bierman <a...@yumaworks.com> wrote:
> > On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> >
> > >
> > > > On 11 Jan 2017, at 17:56, Andy Bierman <a...@yumaworks.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > >
> > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwil...@cisco.com>
> > > wrote:
> > > >
> > > >
> > > > On 11/01/2017 09:22, Martin Bjorklund wrote:
> > > > Andy Bierman <a...@yumaworks.com> wrote:
> > > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwat...@juniper.net>
> > > wrote:
> > > >
> > > > I think it is better to have a human decide what is in the module
> > > > instead of relying on a pyang plugin to generate some additional
> module
> > > > that follows some simplistic pattern.
> > > > It may be simple, but I’m thinking that’s only because it’s not
> tricky
> > > ;)
> > > >
> > > >
> > > > The client and server developers still need to know about this
> > > > auto-generated module
> > > > and implement it. Operators might have to know about it to use it.
> > > > My idea is not to auto generate models on the fly.
> > > >
> > > > My aim is to allow folks to start writing models in the desired long
> > > term format (i.e. combined config and state tree) with the model
> designer
> > > being able to assume the existence of the operational state datastore.
> > > >
> > > >
> > > >
> > > > I am not convinced this "new format" has solved anything.
> > > > Don't you need separate description-stmts in every node for each
> > > > datastore? What does the value mean if pre-configured? configured?
> > > > operational? Will the auto-generated objects be exactly correct
> > > > and never need any alterations or additional text?
> > > > They still need to be used by developers and YANG tools.
> > >
> > > Right, this is one problem of this "deduplication": even if two nodes -
> > > one config and the other state - have the same name or even type
> (which is
> > > not always the case, as we know), their semantics is often different.
> An IP
> > > address in configuration means a manually configured address whereas in
> > > state it may come from any source. So writing sensible descriptions
> will
> > > become tricky.
> > >
> > > >
> > > > Is is that realistic to force the config structure and operational
> > > structure
> > > > to be the same? Seems it is quite common to monitor data structures
> > > > with additional keys or different keys. This is completely
> unsupported
> > > > so separate /foo and /foo-state trees will still exist.
> > >
> > > I agree.
> > >
> > > Lada
> > >
> > > >
> > > > IMO this combination of trees needs to be proven.
> > > > Take ietf-interfaces and show how much better it will work
> > > > if the /interfaces and /interfaces-state trees were combined.
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > The tooling would be there to statically generate the extra foo-state
> > > config false node modules for servers that don't support the
> operational
> > > state datastore. This could be done once, and the extra foo-state
> modules
> > > committed to the github YANG respository in the same way that models
> are
> > > extracted from IETF RFCs today.
> > > >
> > > > The aim here is that the single model being produced by IETF would be
> > > usable both by new client/servers that support an operational state
> > > datastore, and also by existing NETCONF client/servers that don't
> implement
> > > an operational state datastore.
> > > >
> > > > I'm not proposing that as a long term solution, but as a path to
> make it
> > > easier for folk to migrate, and to not slow down the model writing
> effort.
> > > Otherwise, it may be hard to get a protocol model writer to design the
> YANG
> > > model in a way that is not fully usable on any current devices.
> > > >
> > > > As an illustration, an RFC published combined ietf-interfaces model
> may
> > > look like this:
> > > >
> > >
> >
> >
> > OK -- let me see if I understand the value of combining ietf-interfaces.
> >
> >
> > Here is the starting tree:
> >
> >
> > +--rw interfaces
> > | +--rw interface* [name]
> > | +--rw name string
> > | +--rw description? string
> > | +--rw type identityref
> > | +--rw enabled? boolean
> > | +--rw link-up-down-trap-enable? enumeration
> > +--ro interfaces-state
> > +--ro interface* [name]
> > +--ro name string
> > +--ro type identityref
> > +--ro admin-status enumeration
> > +--ro oper-status enumeration
> > +--ro last-change? yang:date-and-time
> > +--ro if-index int32
> > +--ro phys-address? yang:phys-address
> > +--ro higher-layer-if* interface-state-ref
> > +--ro lower-layer-if* interface-state-ref
> > +--ro speed? yang:gauge64
> > +--ro statistics
> > +--ro discontinuity-time yang:date-and-time
> > +--ro in-octets? yang:counter64
> > +--ro in-unicast-pkts? yang:counter64
> > +--ro in-broadcast-pkts? yang:counter64
> > +--ro in-multicast-pkts? yang:counter64
> > +--ro in-discards? yang:counter32
> > +--ro in-errors? yang:counter32
> > +--ro in-unknown-protos? yang:counter32
> >
> > +--ro out-octets? yang:counter64
> > +--ro out-unicast-pkts? yang:counter64
> > +--ro out-broadcast-pkts? yang:counter64
> > +--ro out-multicast-pkts? yang:counter64
> > +--ro out-discards? yang:counter32
> > +--ro out-errors? yang:counter32
> >
> >
> >
> > So these are the objects that would no longer be duplicated:
> >
> > - name
> > - type
> >
> > Neither one is supposed to have a different value in operational state vs
> > configuration.
> >
> > - enabled
> > - link-up-down-trap-enable
> >
> > These 2 could be different in operational state I suppose.
> > An RPC can provide the operational value without changing the YANG module
> >
> > rpc get-oper-value {
> > input {
> > leaf node {
> > type instance-identifier;
> > description "the config=true node to check";
> > }
> > }
> > output {
> > anydata value {
> > description
> > "contains 1 child node matching the input 'node'
> parameter.
> > The value of the node is the current operational value."
> > }
> > }
> > }
>
> This is essentially what we propose, except that we have generalized
> it so that more than one value can be retreived: <get-state> or
> <get-data> which takes a filter just like <get>.
>
>
OK
How do I retrieve the same subtree from multiple contexts at once
so I can reduce time-skew caused by retrieving config-tree then oper-tree?
>
> > <rpc>
> > <get-oper-value>
> > <node>/if:interfaces/if:interface[if:name='eth0']/
> enabled</node>
> > </get-oper-value>
> > </rpc>
> >
> >
> > <rpc-reply>
> > <value>
> > <if:enabled>false</if:enabled>
> > </value>
> > </rpc-reply>
> >
> > I don't need to change the YANG module at all to support operational
> state.
>
> Correct. Old modules will continue to work. Clients that <get-state>
> both /interfaces and /interfaces-state will receive some duplicate
> data.
>
> However, the new model allows for combined trees to be defined.
>
>
Here are the things that do not work anymore if a designer uses the new
tree approach:
YANG statements:
- It is not possible to define these statements so they are different
for config and oper
- must
- when
- unique
- key
- min-elements
- max-elements
- leafref (path)
- if-feature
- deviation
- type (or any sub-statements of type-stmt)
- status
- description
- reference
YANG allows must-when to reference state data nodes in every XPath context
except 1:
- state data
- RPC input
- RPC output
- action input
- action output
- notification payload
Seems like you are removing a lot of YANG functionality in order to make
the problem-space
fit your solution-space.
>
> /martin
>
> >
> >
> > Andy
> >
>
Andy
> >
> >
> > > > module: ietf-interfaces-combined
> > > > +--rw interfaces
> > > > +--rw interface* [name]
> > > > +--rw name string
> > > > +--rw description? string
> > > > +--rw type identityref
> > > > +--rw enabled? boolean
> > > > +--rw link-up-down-trap-enable? enumeration {if-mib}?
> > > > +--ro oper-status enumeration
> > > > +--ro last-change? yang:date-and-time
> > > > +--ro if-index int32 {if-mib}?
> > > > +--ro phys-address? yang:phys-address
> > > > +--ro higher-layer-if* interface-ref
> > > > +--ro lower-layer-if* interface-ref
> > > > +--ro speed? yang:gauge64
> > > > +--ro statistics
> > > > +--ro discontinuity-time yang:date-and-time
> > > > +--ro in-octets? yang:counter64
> > > > +--ro in-unicast-pkts? yang:counter64
> > > > +--ro in-broadcast-pkts? yang:counter64
> > > > +--ro in-multicast-pkts? yang:counter64
> > > > +--ro in-discards? yang:counter32
> > > > +--ro in-errors? yang:counter32
> > > > +--ro in-unknown-protos? yang:counter32
> > > > +--ro out-octets? yang:counter64
> > > > +--ro out-unicast-pkts? yang:counter64
> > > > +--ro out-broadcast-pkts? yang:counter64
> > > > +--ro out-multicast-pkts? yang:counter64
> > > > +--ro out-discards? yang:counter32
> > > > +--ro out-errors? yang:counter32
> > > >
> > > > The extra generated model would look like this:
> > > >
> > > > module: ietf-interfaces-combined-state
> > > > +--ro interfaces-state
> > > > +--ro interface* [name]
> > > > +--ro name string
> > > > +--ro description? string
> > > > +--ro type identityref
> > > > +--ro enabled? boolean
> > > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}?
> > > > +--ro oper-status enumeration
> > > > +--ro last-change? yang:date-and-time
> > > > +--ro if-index int32 {if:if-mib}?
> > > > +--ro phys-address? yang:phys-address
> > > > +--ro higher-layer-if* if:interface-ref
> > > > +--ro lower-layer-if* if:interface-ref
> > > > +--ro speed? yang:gauge64
> > > > +--ro statistics
> > > > +--ro discontinuity-time yang:date-and-time
> > > > +--ro in-octets? yang:counter64
> > > > +--ro in-unicast-pkts? yang:counter64
> > > > +--ro in-broadcast-pkts? yang:counter64
> > > > +--ro in-multicast-pkts? yang:counter64
> > > > +--ro in-discards? yang:counter32
> > > > +--ro in-errors? yang:counter32
> > > > +--ro in-unknown-protos? yang:counter32
> > > > +--ro out-octets? yang:counter64
> > > > +--ro out-unicast-pkts? yang:counter64
> > > > +--ro out-broadcast-pkts? yang:counter64
> > > > +--ro out-multicast-pkts? yang:counter64
> > > > +--ro out-discards? yang:counter32
> > > > +--ro out-errors? yang:counter32
> > > >
> > > > Servers that support operational-state would just implement
> > > ietf-interfaces-combined
> > > >
> > > > Servers that don't support operational-state could implement
> > > ietf-interfaces-combined and ietf-interfaces-combined-state, probably
> not
> > > implementing the duplicate config false leaves under the interfaces
> config
> > > tree. Deviations could also be auto-generated to remove the config
> false
> > > leaves from the config tree so that they are only in the state tree.
> > > >
> > > > Of course, Clients may need to support both schemes depending on what
> > > types of devices they are interacting with.
> > > >
> > > > Finally, I've illustrated this using ietf-interfaces, but I'm not
> > > actually proposing immediately changing that model. I was more
> thinking
> > > about IETF protocols that in the process of working on their YANG
> models.
> > > >
> > > > Rob
> > > >
> > > >
> > > > Exactly. I agree that this is a real hack. Implementations can use
> > > > whatever transformation tricks they want in order to comply with
> > > > different standards, but the standard modules should be very clear.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > /martin
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> > >
> > >
> > >
> > >
> > >
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
