Hi Martin,
On 26/01/2016 14:33, Martin Bjorklund wrote:
Robert Wilton <rwil...@cisco.com> wrote:
Hi Juergen,
Hopefully my explanations below help clarify.
On 26/01/2016 12:32, Juergen Schoenwaelder wrote:
On Mon, Jan 18, 2016 at 09:47:31AM +0000, Robert Wilton wrote:
As I understand it, what you are proposing here is not what the
section
4 requirements were intended to express.
The section 4 requirements are meant to be at the YANG schema level,
i.e. illustrating possible relationships between YANG schema
nodes. E.g.
for a particular interface IP address they wouldn't be able to
indicate
whether it was actually configured by explicit IP address
configuration
or due to DHCP. They would only be able to tell which configurations
nodes could influence a particular derived state node.
I am confused and I may not understand your example. My point is that
an operationally used IP address can be there for a variety of reasons
and the reasons depend on runtime state not on schema structure.
Yes, exactly.
But this requirements draft is based on the improvements that the
operators would like to see to YANG/NETCONF/etc to make it easier for
them to use/deploy.
For this section 4 requirements, my understanding is that they are not
asking to know why a particular operation node has a particular value,
they are only asking for an indication of which configuration leaves
could influence its value. Solving the latter is easier and can be
implemented at the schema level.
To support my interpretation I recall that Rob Shakir, at the first
Netmod WG meeting IETF 94, indicated that their proposed opstate
solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the
opstate requirements. Their draft doesn't have any mechanism to
indicate why a particular state leaf has a particular value, but it
does provide a schema level relationship between the configuration and
operation state nodes - i.e. the co-located config and state
containers that they consistently use throughout the OpenConfig
schema.
I think that there are a couple of cases where this relationship is
useful:
(1) If you modify a config node, it allows the client to know (in
advance) which derived state nodes may be affected and hence should be
retrieved to confirm the change.
(2) Conversely, if a derived state note has an unexpected value, it
allows a client to know which configuration nodes it should retrieve
to
try and infer what the cause of the value is.
If I understand your proposal, then what you are proposing is
meta-data
annotations of the derived state nodes in the data tree. I.e. the
annotations would allow you to tell you whether a particular interface
IP address had that value due to explicit IP address configuration or
because it was allocated by DHCP. I agree that this is useful, but I
think that it is very hard to implement (on the systems that I'm
familiar with) and is also beyond the requirement as originally stated
by the opstate requirements draft.
I agree its hard to implement in general but I am not sure why the
other proposal would be any simpler to implement. Your instrumentation
is either able to keep track of 'why something has a certain value' or
it is not.
I'm saying that there is no requirement (at least from the opstate
draft) to generally track "why something has a certain value" at all.
As such, I think that we should restrict the scope of the requirements
draft (and proposed solutions) to YANG schema level annotations that
are
easier to solve. If you agree, then do we need to tweak the text of
requirement 4 to make this explicit?
But this approach requires to partition things artificially. For
example, I can't have a simple list of IP addresses used by the
interface anymore but instead I need to have a list of IP address
coming from static config, a list of IP addresses coming from DHCP, a
list of IP addresses coming from SLAAC and so on. I seriously can't
imagine that debugging network configurations becomes simpler if we
spread around the information one needs to look at in several branches
of the data model. [I hope I completely misunderstand requirement 4.]
I don't think that they are asking/suggesting separate lists of
operational IP addresses.
Taking the OpenConfig IP YANG model as an example
(https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang):
They have a list of IP addresses. Each entry contains:
- the configured IP address (if any),
- the operational IP address,
- an enum indicating the source of the operational IP address value
- (static, dhcp, link_layer, random or other).
I assume you refer to this list:
Yes.
list address {
key ip;
description
"The list of configured IPv4 addresses on the interface.";
leaf ip {
type leafref {
path "../ocip:config/ocip:ip";
}
description "References the configured IP address";
}
container config {
description "Configuration data for each configured IPv4
address on the interface";
uses ipv4-config-address;
}
container state {
config false;
description "Operational state data for each IPv4 address
configured on the interface";
uses ipv4-config-address;
uses ipv4-state-address;
}
}
Note how the key contains the "configured IP address" (and it is a
config true list). So this list cannot contain addresses that are
not configured.
OK, yes. I had missed that.
I presume that they would ideally like this list to contain all IP
addresses on an interface whether configured or operational. Otherwise
if it contains just the list of configured addresses then the "origin"
leaf in the ipv4-state-address grouping seems pretty pointless since the
only sane value that it could hold is STATIC :-)
I suspect that this issue ties back to sections 8.1.2 and 9.2 of
https://www.ietf.org/archive/id/draft-openconfig-netmod-opstate-01.txt
(text reproduced below) where they would like the YANG schema to have a
combined list of configured and state entries.
8.1.2. Handling lists
In YANG 1.0, lists have requirements that complicate the creation of
the parallel configuration and state data structures. First, keys
must be children of the list; they cannot be further down the data
hierarchy within a subsequent container. For example, the
'interface' list cannot be keyed by /interfaces/interface/config/
name. Second, YANG requires that the list key is part of the
configuration or state data in each list member.
We consider two possible approaches for lists:
1. list keys appear only at the top level of the list, i.e., not
duplicated under the 'config' or 'state' containers within the
list
2. the data represented by the list key appears in the config and
state containers, and a key with type leafref is used in the top
level of the list pointing to the corresponding data node in the
config (or state) container.
Option 1 has the advantage of not duplicating data, but treats the
data item (or items) that are keys as special cases, i.e., not
included in the config or state containers. Option 2 is appealing in
that configurable data always appears in the config container, but
requires an arguably unnecessary key pointing to the data from the
top level of the list.
Appendix C shows a simple example of both options.
9.2. YANG lists as maps
YANG has two list constructs, the 'leaf-list' which is similar to a
list of scalars (arrays) in other programming languages, and the
'list' which allows a keyed list of complex structures, where the key
is also part of the data values. As described in Section 8.1.2, the
current requirements on YANG list keys require either duplication of
data, or treating some data (i.e., those that comprise list keys) as
a special case. One solution is to generalize lists to be more like
map data structures found in most modern programming languages, where
each list member has a key that is not required to part of the
configuration or state data, and also not subject to existing
"config-under-state limitations. This allows list keys to be
arbitrarily defined by the user if desired, or based on values of
data nodes. In the latter case, the specification of which data
nodes are used in constructing the list key could be indicated in the
meta-data associated with the key.
Rob
/martin
Their schema doesn't completely follow the opstate draft requirements.
In particular, they should have separate leaves for the applied
configuration value vs the operational state value. I presume that
this will be fixed at some point.
In summary, I think that knowing the source of a piece of operational
data is valuable in some circumstances (e.g. IP addresses), but
probably isn't actually required for most operational values, and at
least from an opstate perspective isn't a general requirement that
needs to be solved with a generic solution.
Rob
/js
_______________________________________________
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
