Re: More confirmed-commit issues

[Andy Bierman <ietf@andybierman.com>]

Wes Hardaker wrote:

> Andy> T0 - boot with baseline config
> Andy> Tc -  Manager A issues a confirmed commit, w/ revert to baseline at Tc+i
> Andy> Tc+1 - Manager A loses its connection and session
> Andy> Tc+10 - Manager B has no idea Manager A did this, comes along, gets the 
> Andy> lock,
> Andy> and starts writing to the <candidate> config, which  
> Andy> starts with  the contents
> Andy> of <running> at time Tc
> Andy> Tc+20 - Then Manager A comes back and can't get a lock
> Andy> Tc+i   - Manager A's revert timer pops before Manager B is done
> Andy> The agent reverts the state of <running> to T0.  (But B 
> Andy> thinks the
> Andy> state of <running> is Tc).
>
> It's even more interesting when you think about A doing things like
> that intentionally.  Since the lock has been dropped, you're down to
> auditing to figure out who the bad guy was that reverted changes out
> from under you.
>
>  
I would be more worried about security-related config that gets reverted
by mistake.  There is no way or Mgr B to know a confirmed commit is in
progress.  We can fix this part by adding a "confirmed-commit-in-progress"
warning (rpc-error response) that is generated if an rpc request which
would alter the <running> config is received by the agent while a 2nd
commit operation or revert-timeout is pending.

Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>