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