On 11/01/2017 20:32, Andy Bierman wrote:
On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <lho...@nic.cz
<mailto:lho...@nic.cz>> wrote:
> On 11 Jan 2017, at 17:56, Andy Bierman <a...@yumaworks.com
<mailto:a...@yumaworks.com>> wrote:
>
> Hi,
>
>
> On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton
<rwil...@cisco.com <mailto:rwil...@cisco.com>> wrote:
>
>
> On 11/01/2017 09:22, Martin Bjorklund wrote:
> Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>> wrote:
> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen
<kwat...@juniper.net <mailto: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.
I don't disagree that in some cases there is some nuanced differences
between configured values and values that may be learned via other
dynamic mechanisms.
The pragmatic point solution for these sorts of cases is to add an extra
leaf to indicate the source of the value. The existing ietf-ip YANG
model already has a "source" leaf to indicate whether the address is
static, dhcp, link-layer, random. This type of adhoc mechanism will
continue to work with a combined config/state data tree as well.
However, draft-ietf-netmod-revised-datastores also provides a
generalized solution to this problem, via using origin metadata
annotations (sections 5.2 and 8). This allows the server to annotate
whether a node in the operational state datastore has been populated via
running configuration, or has been acquired via some other mechanism.
Yes, the descriptions may have to be written in a slightly different
way, but I don't think that it is going to be too tricky to understand
that was is in running represents the configuration given to the system,
vs what is in the operational state datastore represents what
configuration the device is actually running, along with all of the
associated other operational state.
Rob
>
> 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 <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
