Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)

[Radek Krejčí <[e-mail]>]

Dne 29.5.2014 17:35, Andy Bierman napsal(a):
>
>
>
> On Thu, May 29, 2014 at 6:16 AM, Ladislav Lhotka <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>     On 29 May 2014, at 14:31, Andy Bierman <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>     >
>     >
>     >
>     > On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     > Hi,
>     >
>     > I am moving this discussion to the NETCONF mailing list.
>     >
>     > Andy Bierman <[e-mail] <mailto:[e-mail]>>
>     writes:
>     > ...
>     > >
>     > > I don't agree NETCONF/YANG persistence is ill-defined.
>     > > It is not uniform. There are a few variants, identified by
>     > > capability URIs.
>     >
>     > I'd say persistence is at least under-defined. For example, it
>     doesn't seem to be clear from 6241 whether candidate is persistent.
>     >
>     >
>     > OK
>     >
>     > sec 8.3.5.2 says:
>     >
>     >    When a client fails with outstanding changes to the candidate
>     >    configuration, recovery can be difficult.  To facilitate easy
>     >    recovery, any outstanding changes are discarded when the lock is
>     >    released, whether explicitly with the <unlock> operation or
>     >
>     >  implicitly from session failure.
>     > IMO it is odd that candidate is cleaned up only if it was locked.
>     > If a client edits candidate and then closes the session somehow
>     the changes are left behind.
>     > The RFC is silent about the contents of candidate at boot-time.
>     Our server always boots
>     > with the candidate and running having the same contents.
>      Otherwise the candidate is
>     > dirty at boot-time and cannot be locked by any session until a
>     discard-changes is invoked.
>     > There is also no explicit requirement to boot with any
>     particular candidate contents, so
>     > booting with the contents of running is compliant.
>
>     I think an alternative interpretation of the 6241 text is that
>     candidate is a persistent staging area that survives reboots and
>     is only reverted to running after discard-changes. So a client can
>     close a session, then later open a new one and start editing where
>     he left off.
>
>
>
> There is no text that says anything about the initial state of candidate.
> Does any known implementation behave this way?
> (Note that the shared candidate is a horrible place to toss some edits
> and come back later to finish up.  The shared candidate is not really
> intended to left unlocked so partial edits from various clients can
> accumulate.)
>
>

libnetconf/netopeer server does. Since RFC doesn't say anything about
initial state of the candidate, we don't do anything with its content.
So initially, it is empty and any change is persistent. The only thing
that libnetconf do automatically with candidate content is copy-config
from running (discarding the changes) on unlock.

I think that it's better to be consistent in "candidate is dirty" than
the approach "it may be consistent with running datastore at some time
.... or not". Therefore I don't think, that come back later and continue
in editing is a good idea - in our implementation, candidate is always
considered to be dirty and if you want to work with it, you are supposed
to lock it and (or at least) initiate its content.

Radek

>     Lada
>
>
> Andy
>  
>
>     >
>     >
>     > Lada
>     >
>     > Andy
>     >
>     >
>     > >
>     > > The XMLCONF design team (pre-4741) tried very hard to
>     > > get the router vendors to agree on a single transaction model
>     > > but it was way too big a change, and (of course) each vendor
>     > > thought their way was better, so the standard should use that.
>     > > We ended up with 3 configuration datastores (candidate,
>     running, startup).
>     > > The transaction models that can be used with these datastores
>     > > are compatible with specific router CLI architectures.
>     > >
>     > > Two particular vendors do not agree on how to recover
>     > > from the "unreachable" problem.  If the operator makes
>     > > config changes that break the connectivity to the device,
>     > > then the device has to recover somehow.
>     > >
>     > >   M1: do not persist the changes until they are proven to
>     > >         be correct.  Force the device to reboot with the saved
>     > >         (known good) config if things go bad.
>     > >
>     > >   M2: persist the changes right away.  Pick some timeout
>     > >         and if the client does not follow up with a confirmation
>     > >         before the timeout, automatically revert to the version
>     > >         that was running before the transaction started.
>     > >
>     > > RFC 6241 could be more clear on the motivation for the
>     > > capabilities and operations that support various transaction
>     models.
>     > > Maybe that is what you meant by 'ill-defined'.
>     > >
>     > >
>     > > Andy
>     > >
>     > > So the two objects controlling Notifications seem clearly
>     configuration,
>     > >> whether or not the setting of them persists or is lost on
>     reboot.  You
>     > >> could create a YANG module which controls the setting of
>     these two
>     > >> objects for SNMP usage but I think that even the IESG might
>     see that
>     > >> that is an unusual approach, as opposed to making them
>     read-write in
>     > >> SMI!
>     > >>
>     > >> When I first read the draft IESG statement, it was unclear to
>     me whether
>     > >> or not the authors fully understood what they had written.
>     > >>
>     > >> Tom Petch
>     > >>
>     > >> > (*1)
>     http://www.ietf.org/iesg/statement/writable-mib-module.html
>     > >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
>     > >> >
>     > >> > Hirochika
>     > >> >
>     > >> >
>     > >> > On May 27, 2014, at 3:55 AM, joel jaeggli <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     > >> >
>     > >> > > yeah if you want to discuss it with the ops/management
>     ADs and the
>     > >> > > chairs that's fine.
>     > >> > >
>     > >> > > I don't think there's a reason to involve the whole iesg.
>     > >> > >
>     > >> > > Thanks
>     > >> > > joel
>     > >> > >
>     > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
>     > >> > >> js and Joel,
>     > >> > >>
>     > >> > >> Thank you for your comments.
>     > >> > >>
>     > >> > >> I agree that the IESG statement seems to be talking about
>     > >> configuration,
>     > >> > >> but I cannot definitely say that the objects I listed in my
>     > >> previous E-mail
>     > >> > >> are out of the IESG statement's scope.
>     > >> > >>
>     > >> > >> I think it would be better to move this issue to the
>     IESG, but I
>     > >> don't keep
>     > >> > >> up the procedure.  May I, as an author of the draft,
>     send an E-mail
>     > >> > >> stating this issue to [e-mail]
>     <mailto:[e-mail]>, CCing WG? Or ask WG chairs to
>     > >> > >> handle it?
>     > >> > >>
>     > >> > >> Thank you.
>     > >> > >> Hirochika
>     > >> > >>
>     > >> > >>
>     > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     > >> > >>
>     > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
>     > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
>     wrote:
>     > >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
>     > >> > >>>>>> Asai,
>     > >> > >>>>>>
>     > >> > >>>>>> the IESG statement is here:
>     > >> > >>>>>>
>     > >> > >>>>>>
>     http://www.ietf.org/iesg/statement/writable-mib-module.html
>     > >> > >>>>>>
>     > >> > >>>>>> My reading is that it specifically talks about
>     configuration.
>     > >> While
>     > >> > >>>>>> the discussion started with "lets ban all write
>     access", it may
>     > >> be
>     > >> > >>>>>> important to note that the final statement does not
>     say this.
>     > >> Hence,
>     > >> > >>>>>> I am not sure we have to remove the MAX-ACCESS
>     read-write.
>     > >> > >>>>>
>     > >> > >>>>> some of the vm options do cause me existential peril. The
>     > >> remaining
>     > >> > >>>>> one's however do not. so I think Juergen's assessment
>      is a
>     > >> correct one.
>     > >> > >>>>> The statement seems to be serving it's purpose!
>     > >> >>>>
>     > >> > >>>> Joel, can you please decrypt your message so that it
>     becomes
>     > >> perhaps
>     > >> > >>>> actionable?
>     > >> > >>>
>     > >> > >>> I'm agreeing with you.
>     > >> > >>>
>     > >> > >>>> /js
>     > >> > --
>     > >> > Hirochika Asai <[e-mail]
>     <mailto:[e-mail]>>, The University of Tokyo
>     > >> >
>     > >> > _______________________________________________
>     > >> > OPSAWG mailing list
>     > >> > [e-mail] <mailto:[e-mail]>
>     > >> > https://www.ietf.org/mailman/listinfo/opsawg
>     > >>
>     > >> _______________________________________________
>     > >> OPSAWG mailing list
>     > >> [e-mail] <mailto:[e-mail]>
>     > >> https://www.ietf.org/mailman/listinfo/opsawg
>     > >>
>     > > _______________________________________________
>     > > OPSAWG mailing list
>     > > [e-mail] <mailto:[e-mail]>
>     > > https://www.ietf.org/mailman/listinfo/opsawg
>     >
>     > --
>     > Ladislav Lhotka, CZ.NIC Labs
>     > PGP Key ID: E74E8C0C
>     >
>     > _______________________________________________
>     > Netconf mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/netconf
>     >
>
>     --
>     Ladislav Lhotka, CZ.NIC Labs
>     PGP Key ID: E74E8C0C
>
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Radek Krejci
mobile: [phone]
office: [phone]
e-mail: [e-mail]

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic