interesting application problems

[Wes Hardaker <wjhns1@hardakers.net>]

The interesting thing with configuration of a device when a tcp based
transport is in use is that the transport can die in the middle due to
changes in the configuration themselves.  This leaves things in an odd
state sometimes.

I have not fully thought out all possible scenarios, but here are some
quick examples:

EG 1:
  <edit-config>
    <target><running/></target>
    <error-option>stop-on-error</error-option>
    <config>
        ...  #1
        Change IP addr on interface with netconf session traffic.
        ...  #2
    </config>
  </edit-config>

  In this case, the management app will never see the response and
  whether or not things were successful.  Specifically, it won't know
  definitively if the changes contained in "... #2" were successful or
  not since the server would have tried to send a response from the
  new interface address, which would kill the tcp session from the
  server's side (and eventually the client's).

EG 2:
  <lock>
    <target>
     <running>
    </target>
  </lock>

  <!-- similar edit operation as above -->

  Now, the problem is compounded by the loss of the lock when the
  session is broken.  The server would get a RST after the address
  changed, stop the session, and kill the lock.  Hopefully the
  management app was done otherwise it'll have to re-compete for the
  lock.  (and it, of course, still won't know what the state of the
  <running> config is).

EG 3
  <lock>
    <target>
     <candidate>
    </target>
  </lock>
  <lock>
    <target>
     <running>
    </target>
  </lock>

  <!-- similar edit operation as above -->

  <commit>

  Now, the lock has been lost on both.  The result of the commit is
  unknown (what happens in the commit when not everything could be
  completed isn't well defined in the draft, I just noticed...  I
  don't think it says anywhere if it is all or nothing.  edit-config
  has options for what to do, but commit does not).  Additionally, if
  the commit wasn't 100% successful then no one can obtain a lock on
  the <candidate> store until a rollback is done, a copy from running
  to candidate, or whatever to release the uncommitted changes.      


-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
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/>