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."
}
}
}
<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.
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
