Robert Wilton <[email protected]> wrote: > Hi Martin, > > On 11/09/2015 08:38, Martin Bjorklund wrote: > > Sam Aldrin <[email protected]> wrote: > >>> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani > >>> <[email protected]> wrote: > >>> > >>> > >>>> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) > >>>> <[email protected] <mailto:[email protected]>> wrote: > >>>> > >>>> Now, think about configuration parameters that have applied > >>>> configuration located in more than one place. Let’s say you change the > >>>> IP address of an interface, it is likely that this configuration will > >>>> be passed around as input to a handful of subsystems (e.g. the DHCP > >>>> server, some routing daemons that may bind to specific IP > >>>> addresses). Is the intended and applied in sync when a specific subset > >>>> of those configurations are updated. What happens if there’s a partial > >>>> failure? > >>> This is a good example. Another example, and somebody on the call > >>> today started to ask this but got cut off, relates to interfaces on > >>> the device. > >>> > >>> Interfaces already exist on a system. As such they have a > >>> configuration (default values) that exists on them. They are enabled > >>> when configuration gets applied on them. They will have applied > >>> configuration but no intended configuration. Should this be reported? > >>> > >>> Yet another example is of a BFD session that gets bootstrapped because > >>> of a ping. There is no intended configuration, but the session exists > >>> and a query of configuration in this case would return a valid BFD > >>> session. > >>> > >>> Could we get some clarification (with examples, preferably) on what > >>> the expectation is from a openconfig opstate perspective? > >> Section 7 of draft-openconfig-netmod-opstate talks about > >> that. Specifically, #3 talks about the interface question you raise.. > > I think it is important that we understand how this 'applied config' > > is supposed to be populated on a device. > > > > First it was said that it there is just one way they can be different; > > time (on async systems). After some discussion I think there are now > > four ways: > > > > 1. Time (in async systems). > > > > 2. Hardware. If something is in intended config but there is no hw > > present, it is not in applied. > > > > 3. System-controlled stuff. If the system auto-creates an > > interface (for example), it will be in the applied config but > > not in intended. > > I don't agree with this one. > - if a system auto-creates an interface with no config then it is > - /interfaces-state, but not in /interfaces.
Yes this is how ietf-interfaces work. But the openconfig people want to change this, and introduce 'applied config' as a simplicifation. I am / we are trying to understand how they intend this 'applied config' to work. > - if a system auto-creates an interface and only then applies default > - config, the default config would go in intended and applied. > - interfaces with pre-config that could be put into intended, but be > - left out of applied (because the hw isn't present). > > So in summary, I would say that config is in applied and not intended > only if the config is in the process of being deleted (or the delete > operational failed for some reason). > > > > > 4. "Template substitution"; the draft uses the example of an 'all' > > interface that exists in intended config but not in applied. > I don't agree with this one either. I don't think that cfg intended > vs applied can or should be used as templating mechanism. See above; the four bullets are (my understanding of) what the openconfig people have said. I hope they clarify if this is not what they meant. /martin > But I think that there is another case, which is for config that was > accepted into the system (i.e. semantically valid) and then failed > when being applied. E.g. due to a system, or internal error. There > is also a possible failure due to out of resource (which could be > counted as the same as case 2). > > For a sync system, config failures can be returned as part of the > edit-config request. What is the equivalent mechanism for an async > system? > > > > > > Then Lada brought up the example of ip addresses. It was mentioned > > on the call that for ip addresses there would be three lists; one for > > intended, one for applied, and one in derived state, where the one in > > derived state is what the box *really* uses. So for example if it > > gets an ip from dhcp, it will be in the derived state list, but not in > > applied config. > > > > Why is this ip-address list different from the interface list? Why > > was it enough with two lists for interfaces, but we need three for ip > > addresses? > I don't see that they are different. I think that you have 3 > lists/leaves in both cases: > > I.e. I would say that 3 IP addr leaves are required in an async > system, at a given time t: > - only the intended leaf can indicate what IP addr config the operator > - wants on the interface (if any). > - only the applied leaf can indicate what IP addr is actually being used > - as the configured value on the interface. > - only the derived leaf can indicate what IP addr is actually > - operationally being used for the interface (which might be due to IP > - addr config, DHCP, or perhaps some other mechanism). > > I think that in the both kwatsen-netmod-opstate and > wilton-netmod-opstate there are logically 3 interface lists as well: > - /if:interfaces is logically split into 2, either through being present > - in separate running and applied datastores, or through having separate > - cfg-intended/cfg-applied leaves. > - /if:interfaces-state, which I perceive as logically the derived state > - for an interface. > > Cheers, > Rob > > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
