Subject: RE: interesting application problems

From: "Frye, Robert J (US SSA)" <[email-masked]>
Date: Wed, 24 Nov 2004 09:34:31 -0500

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)[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wes Hardaker
Sent: Tuesday, November 23, 2004 4:51 PM
To: [email-masked]
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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Nov 2004 17:12:45 -0800

>>>>> On Wed, 24 Nov 2004 09:34:31 -0500, "Frye, Robert J (US SSA)" <[email-masked]> said:

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

One of the dreams with netconf, I think, is that you'll be able to
change everything right?  That's one of the whole points: final an
interface other than CLI that will expose everything.  (Realistically,
we'll have to wait and see if this actually happens).

If you can't change the address on the management interface, then you
won't achieve this goal.

However, it's not just limited to addresses.  Masks, router addresses,
...  There is a list of things that could cause the same problem.
Certainly more than I can enumerate.

I don't think you can solve the issue.  I agree you simply need to be
careful.  I was merely bringing up the topic so the real netconf
experts could file it in the back of their head.  It might warrant
text, I don't know.  That's why we have authors ;-)

Robert> If the <commit> is done separately (and possibly using UDP? 
Robert> Needs more thought), and if the running config changes don't
Robert> become effective until <commit>, then I don't think you can
Robert> shoot yourself in the foot as easily. 

I agree it might be wise to separate out such things into separate
change sets.

(UDP isn't possible with netconf by design, so that isn't a solution.
The document requires a stream based protocol.)