Hi Martin, The table you have is consistent with the proposal that we laid out in the last interim. Now that we understand the problem, it’d be great to move on to solutions :)
Cheers, r. On 24 June 2015 at 10:39:53, Martin Bjorklund (m...@tail-f.com) 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
