> On Sep 11, 2015, at 12:07 PM, Ladislav Lhotka <lho...@nic.cz> wrote: > > Martin Bjorklund <m...@tail-f.com> writes: > >> Sam Aldrin <aldrin.i...@gmail.com> wrote: >>> >>>> On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani >>>> <mjethanand...@gmail.com> wrote: >>>> >>>> >>>>> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg) >>>>> <camob...@cisco.com <mailto:camob...@cisco.com>> 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. >> >> 4. "Template substitution"; the draft uses the example of an 'all' >> interface that exists in intended config but not in applied. >> >> >> 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. > > Right. After yesterday's interim I am much less in favour of this > intended/applied proposal because > > - as you say, applied configuration falls short of representing "the > state that the network element is actually in", > > - states in which intended and applied configuration can be out of sync > are only transient. In the use cases I am interested in, such states > could be relatively normal and last long. > > Another example that comes to my mind are static routes: an operator > needs to know that a configured static route got installed, and this can > be verified only by inspecting a corresponding RIB (operational > state). I don't see how a copy of static routes in applied configuration > could help. > > I agree with Juergen that what we need is a clever representation of > operational state and this is hard work that needs to be done by experts > on an ad hoc basis. That's why I am also sceptical about the possibility > of having fixed and universally applicable relationships between > configuration and operational state.
This is very true! As the networking is done today by vendors, achieving universally applicable relation between config and operational state is very hard. Openconfig folks want to get a single tree with of variables and it is lot of work for existing vendors to translate between customer desires and current vendor implementations, having separate operational and config models. We should ask ourselves are we ready to work on an object oriented networking model with getter and setter functions and if vendors are ready to support such model. Dean > > Lada > >> >> 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? >> >> >> /martin >> _______________________________________________ >> 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
