Hi Andy,
On 11/09/2015 17:42, Andy Bierman wrote:
On Fri, Sep 11, 2015 at 12:38 AM, Martin Bjorklund <m...@tail-f.com
<mailto:m...@tail-f.com>> wrote:
Sam Aldrin <aldrin.i...@gmail.com <mailto:aldrin.i...@gmail.com>>
wrote:
>
> > On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
> > <mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>> wrote:
> >
> >
> >> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
> >> <camob...@cisco.com <mailto:camob...@cisco.com>
<mailto: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:
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?
I think that this same issue exists for a servers handling a sync config
commit as well. Presumably these would also block forever or require
some timeout to determine (2)?
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.
Yes, and this is why I am suggest that templating shouldn't be part of
applied cfg. It looks like templating only turns up in section 7 of
openconfig-netmod-opstate-01 rather than being listed in section 4 on
requirements.
If support for generic YANG templating is required, then I would suggest
that should be considered separately from the current opstate draft.
Thanks,
Rob
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
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
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
