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