> On 26 Jan 2016, at 15:19, 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.
This can IMO work only if the schemas of configuration and state data are identical or very similar. As an example, take RIBs (state data) and a list of static routes (configuration). There is a certain relationship between them, but the exact outcome depends on a number of other factors. I don't see how they can be co-located, or how the relationship can otherwise be formally expressed. Lada > >> >>> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
