Hi,
Perhaps the operational requirements are not that clear, so
the terminology is also not that clear?
Is there really a requirement to know detailed info about the
differences between intended and applied config?
It seems like the general requirement is that the client
needs to know when it can start using the network resource
that has been added or modified in the intended config.
There are 2 modes that fall out from this requirement:
1) synchronous: do not return from this RPC until resources are ready
2) asynchronous: return right away from this RPC, and inform the client
when the resources are ready (could indicate ready in the RPC
response)
Andy
On Tue, Sep 29, 2015 at 11:37 AM, Phil Shafer <[email protected]> wrote:
> 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
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
