Robert Wilton <rwil...@cisco.com> wrote:
> Hi Martin,
>
> One quick clarification:
>
> In your open config model example, should the operational state of the
> last line read 'full'?
yes!
> I.e
>
> running actual config operational state
> ------- ------------- -----------------
> t4 auto auto *full*
Here's the updated table:
running actual config operational state
------- ------------- -----------------
t0 half half half
t1 auto half half
t2 auto half (*) half
t3 auto auto half
t4 auto auto full
/martin
>
>
> 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
