Semi-in-reply-to: <[email protected]>
I keep thinking the terms in the draft somewhat confusing. Okay,
confusing isn't exactly right. I find the terms have a lot of
background that needs to be explained that's not obvious from the
simple explanations in the draft. The reader will see these terms
and think they know what they mean without that deeper understanding.
For example:
o applied configuration - this data represents the state that the
network element is actually in, i.e., that which is currently
being run by particular software modules (e.g., the BGP daemon),
or other systems within the device (e.g., a secondary control-
plane, or line card).
This says nothing about how the current state relates to the
configuration. The term "applied configuration" would imply that
this state is driven by configuration, but there's really nothing
here addressing that. Does config for interfaces that don't exist
appear in AC? Do implicit peers appear along side explicitly
configured ones?
Likewise:
o derived state - this data represents information which is
generated as part of the system's own interactions. For example,
derived state may consist of the results of protocol interactions
(the negotiated duplex state of an Ethernet link), statistics
(such as message queue depth), or counters (such as packet input
or output bytes).
There's nothing that clearly delineates DS from AC. The switch
from "state" to "information" doesn't really add anything concrete.
Why is AC state but DS information?
How does one decide which category any particular leaf belongs in?
Does "protocol interactions" include ospf peers, their status, and
learned routes? Is this the same for both explicitly configured
peers and unconfigured peers (set protocols ospf interface ge-0/0/0)?
I wouldn't have thought duplex as derived state, given that I can
configure a value for it.
Would it be better to think of these values in three sets?
A) values given explicitly by the user (== IC == running config)
B) current values which use organization identical to (A)
C) current values which are not organized identical to (A)
I think the real key is that values which _can_ be organized by the
data models used in (A) _should_ use identifical organization in (B).
When I read openconfig, that seems to be their real requirement.
So if (A) has duplex or OSPF peers or interfaces, then (B) will
list duplex state, peer state, and interface state using an identical
organization (in terms of parentage or containers, lists, and keys).
Once the concepts are clear, selecting terminology should be easier.
I'd actually prefer terms like "primary state" and "secondary state"
which force the reader to look up their meaning to terms like
"derived state" which the reader will likely assume they know the
meaning of. Clean terms really help with understanding and discussions
especially when the audience grows beyond the key players active
here.
Should a request for better terms be a new, distinct issue?
Andy B. writes:
>> I do not agree at all that the running datastore means anything other
>> than the intended confg. A new operation is needed to retrieve
>> the active config vs. the intended config.
Do we have a definition for "active config"? Is this running config
or the parts of AC that are fed by IC?
Robert Wilton writes:
>If the running datastore only ever means intended config, then I think
>that would imply:
>
> - existing NETCONF servers should reply immediately after the config
>has been semantically verified + written to the config subsystem before
>the configuration is applied.
The running datastore is definitely only intended config.
My question is what "the configuration change MUST also be applied
in the system" means in a world of a hundred FRUs with a zillion
chips. Does an "applied" MTU mean it hits the kernel, the embedded
FRU, or the final chip with enforces the MTU? Does an "applied"
BGP peer mean an open connection or full route exchange and FIB
update? There's a lot of gray space here.
The original NETCONF view is that when the config is atomically
accepted as the new, valid config, it's done. Are we really talking
about changing that?
You see the same issue with AC's used of "particular software
modules", where any piece of functionality might well be a distributed
set of software instances, often with differing code (kernel,
embedded, chip).
FWIW, in JUNOS we show configuration from the configuration database
and _most_ operational commands from the routing engine, either
from its kernel or the daemons running on it. We expect the kernel
to propagate an MTU as needed without asking the embedded FRU or
chips for their view of the MTU.
> - the existing NETCONF/RESTCONF protocols has no direct mechanism for
>indicating a failure to apply any configuration leaf, the only way such
>information could be deduced is through related operational state leaves
>or notifications.
True, and this is one of the thing I think openconfig hopes to
address, by allowing apps that fetch IC, fetch AC, and diff them
(with suitable diff logic), which stresses the importance of
reusing organization.
Thanks,
Phil
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
