On 11/01/2017 20:32, Andy Bierman wrote:
On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <[email protected]
<mailto:[email protected]>> wrote:
> On 11 Jan 2017, at 17:56, Andy Bierman <[email protected]
<mailto:[email protected]>> 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? 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
I (personally) would make the config "enabled" and the state
"admin-status" leaf the same as well.
But this example is really too simple on its own, a larger model needs
to be considered to properly see the benefits.
- 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.
This solution would naively seem to be very limited.
Rob
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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
>
>
> _______________________________________________
> netmod mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
