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