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:
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.
/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
