Martin Bjorklund <[email protected]> writes: > 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. > > 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. 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
