RE: interesting application problems

["Frye, Robert J (US SSA)" <robert.frye@baesystems.com>]

Wes,

I think the key PDU of your sequences below is the "<commit>".  There
are some operations (eg "Change IP addr") that can't/shouldn't be done
on a live interface, particularly the one carrying the management
traffic.

If the <commit> is done separately (and possibly using UDP? Needs more
thought), and if the running config changes don't become effective until
<commit>, then I don't think you can shoot yourself in the foot as
easily.  There is still the problem about hung locks with lost TCP
sessions, but timers and/or received RSTs can be used to clear these.

Rob Frye
BAE SYSTEMS
CNIR
11487 Sunset Hills Road
Reston, VA 20190
(v)703-668-4520
(m)571-331-2846
(e)robert.frye@baesystems.com
 

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Wes Hardaker
Sent: Tuesday, November 23, 2004 4:51 PM
To: netconf@ops.ietf.org
Subject: interesting application problems


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

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