On 11/01/2017 16:56, Andy Bierman wrote:
Hi,
On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
On 11/01/2017 09:22, Martin Bjorklund wrote:
Andy Bierman <[email protected] <mailto:[email protected]>>
wrote:
On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen
<[email protected] <mailto:[email protected]>> 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?
No, generally I don't this so. Assuming clients understand the general
semantics and datastore architecture it should be fairly easy for them
to understand the difference between the configured value and
operational value.
There might need to be some nuance as to how the description statements
are written, but this still seems better than requiring two separate
leaves for each property so that first one can have a description that
says "this is the configured value" and the second says "this is the
operational value". Anywhere where it is necessary to have manual
duplication leads to mistakes and inconsistencies creeping in.
What does the value mean if pre-configured? configured?
operational?
The datastore architecture defines the semantic meaning of what a node
means in a particular datastore.
This is true even today between startup, candidate, and running datastores.
Will the auto-generated objects be exactly correct
and never need any alterations or additional text?
Yes, they will be exactly correct, and never need any alterations, since
they have exactly the same semantic meaning as for the equivalent config
true leaf in the operational state datastore.
The auto-generation script could trivially append to each description
statement for nodes in the generated model to indicate that it
represents the operational value.
They still need to be used by developers and YANG tools.
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.
It is not forcing the config and operational state structure to be the
same, only that the operational state must extend from the config structure.
These "monitor data structures" can continue to exist as config false
structures just as they do today somewhere in the combined tree. They
could even be put in top level foo-state objects if there was nowhere
lower down the tree that is a better place for them, but I think that in
the general case (for components that can be configured on or off, they
can live under a single top level, config true, component container).
Finally, if you allow the core structure of the config tree and state
tree to deviate that it makes life much harder for management clients
because they have to be hardcoded to know where the corresponding state
lives for a particular set of configuration.
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.
Yes, this might be a good idea. But doing this for the base IETF
interface model on its own isn't really going to be informative. I
think that a larger example is necessary to properly see the benefits.
Rob
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
