Hi Mahesh, The answer (today) is that some operator knows the show commands to type, and then knows from the screen full of data that certain config commands are active.
It's not hard to imagine that how an API to do this without any magic would be useful. (Hence the openconfig requirement...) As Carl pointed out in the interim, current systems do not provide this level of automation. All this is new code, and perhaps there are complicated corner-cases to be found. All solutions expect the server to be able to determine applied status for every leaf in the intended config. All solutions require basically the same internal API support to check the relevant applied config or operational state. In every solution, the server will magically know how to check that the IP address is active. That's the point. It is better than forcing the client to know how to do this for every type of server. IMO, this requirement is clear, and each draft has a solution approach for this new API. Andy On Fri, Sep 11, 2015 at 2:52 PM, Mahesh Jethanandani < [email protected]> wrote: > And while we mull over the questions Andy has raised, I want to go back > and dwell on what Rob said about why he wanted a way to determine when the > configuration has taken effect. I might be simplifying the problem a little > too much, but I am sure Rob will correct me. The ask as I understand > is, give me a way to deterministically know when a given piece of > configuration has taken effect. > > As an exercise I wanted to mentally go through trying to configure an > interface to determine if the configuration has taken effect. Very simply, > I want to assign an IP address to an interface. If I now want to know if > this configuration has taken effect, I can check for the IP address of the > interface. Querying the IP address on an interface does not tell me if it > has taken effect. Yes, it has been written to a register, but what does > that tell me? Nothing. My only deterministic way of knowing that the IP > address has taken effect is if I can see traffic transmitted/received with > that IP address on that interface. > > To me that is the crux of the problem with simply reflecting operational > status with a flag that gets updated when the configuration gets written. > In most cases, the configuration will just work and the flag will tell me > nothing new. But when it does not, having written to a flag will also tell > me nothing, other than the fact that the configuration was written. > > I contend that the real ask with this example is to determine if I can > pass IP traffic, and to determine that, we need more than a “intended vs > actual” flag. > > On Sep 11, 2015, at 9:42 AM, Andy Bierman <[email protected]> wrote: > > > > On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund <[email protected]> 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: >> >> > > IMO it would help to think just a bit about the operational aspects > of these issues. > > There are at least 2 outcomes I can think of: > > Outcome 1) Convergence: > Intended config eventually matches Applied > > Outcome 2) Non-convergence: > Intended config is not going to become Applied > > A system needs to decide if/when outcome 2 has occurred. > When is a fault raised because convergence is not happening? > There are probably other uses for all this extra meta-data. > > So how do these 4 types of differences relate to these outcomes? > > 1. Time (in async systems). >> > > Obviously the main use-case. > Nothing in any solution proposal helps the client decide Outcome 2 has > occurred. > That is out of scope I guess. > > For most systems, this time delta will be too short to worry about ( < 5 > sec.) > A good solution would not impact this vast majority of servers. > > > > >> 2. Hardware. If something is in intended config but there is no hw >> present, it is not in applied. >> > > This is usually handled with a notification that the line-card was plugged > in, which > causes the NMS to re-check the config. The solution proposal assumes the > server > can identify all the resources or other reasons that some specific leaf is > not applied yet. > This seems very complicated to implement in the server. > > > >> 3. System-controlled stuff. If the system auto-creates an >> interface (for example), it will be in the applied config but >> not in intended. >> > > > There is no convergence here because this is a case where applied has more > than intended, > not the other way around. > > > >> 4. "Template substitution"; the draft uses the example of an 'all' >> interface that exists in intended config but not in applied. >> >> > There is no convergence here because the template is not supposed to show > up in Applied. > However it is worth noting than none of the proposals solve this problem. > The Intended and Applied will never match. The NMS must understand > how the specific template works to know what actual instances are expected > 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. >> >> 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 >> > > > Andy > > >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > > Mahesh Jethanandani > [email protected] > > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
