Hi Martin,
One quick clarification:
In your open config model example, should the operational state of the
last line read 'full'?
I.e
running actual config operational state
------- ------------- -----------------
t4 auto auto *full*
Thanks,
Rob
On 24/06/2015 10:39, Martin Bjorklund wrote:
Kent Watsen <kwat...@juniper.net> wrote:
[As an individual contributor]
I think terminology is mostly converging, with the primary hangup
being if ephemeral/intended are "configuration" or "state". I'm
personally in favor of calling both "configuration", as they would
still contain values like "auto", that require actualization to obtain
an operational state value...so I think, if it's not state, it must be
config, right? Adding to this, we have a general understanding that
anything that can be configured persistently can also (in theory) be
configured ephemerally – so it behaves like config in this way too...
More importantly though, I believe that we're converging on a
conceptual model and have general agreement that "running + ephemeral
= intended" and "intended + <actualization> = operational state".
This seems obvious in hindsight, but it wasn't until the OpenConfig
folks brought the "intended" term that we wrote it down.
I don't think this covers what the open config people call "actual
config". Suppose we have (ignoring ephemeral for simplicitly):
running operational state
------- -----------------
t0 half half
t1 auto half
t4 auto full
I.e., at time t1, we set duplex to auto. After some time (t4) this is
reflected in the operational state.
In the open config model we'd have:
running actual config operational state
------- ------------- -----------------
t0 half half half
t1 auto half half
t2 auto half (*) half
t3 auto auto half
t4 auto auto auto
This illustrates that at time t2, the actual config is still half (*)
in an asynchrounous implementation. At time t3, the actual config is
in sync with the intended config, and at time t4 the operational state
has been affected.
I hope we can converge on the terminology and conceptual model in the
near term, and then use this new foundation for articulating I2RS and
OpenConfig solutions.
+1 This should be our focus.
/martin
_______________________________________________
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
