Robert Wilton <rwil...@cisco.com> wrote: > 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 :-)
Exactly. This is the core of the problem with their models, imo. > 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. Like SNMP tables... > 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. This doesn't solve the problem; it just creates a more complex model. > 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. I don't understand how this would solve the problem either, but in any case, I don't think this idea has been presented in greater detail, so I am not sure how it would actually work. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
