Subject: [Netconf] #15: <rpc> interleaving during notification delivery mode

From: "Netconf" <[email-masked]>
Date: Wed, 01 Aug 2007 17:01:49 -0000

#15: <rpc> interleaving during notification delivery mode
---------------------------------------------+------------------------------
 Reporter:  [email-masked]             |       Owner:     
     Type:  defect                           |      Status:  new
 Priority:  major                            |   Milestone:     
Component:  draft-ietf-netconf-notification  |     Version:     
 Keywords:  notification-08                  |  
---------------------------------------------+------------------------------
 There are some interoperability issues related
 to interleaving of <rpc> requests.  This means
 that the agent has already processed the <create-subscription>
 operation, and is delivering notifications.

 This notification delivery mode continues until
 either a stopTime is reached or the session is terminated.
 If the stopTime is reached, the session reverts back to
 the normal mode (accepting <rpc> requests).

 Issue a) what MUST, SHOULD, MAY an agent do with input
 received on the session, after the <create-subscription> RPC,
 when it transitions back to normal mode?

 ------

 The current proposal is that the text will say
 the manager SHOULD NOT send <rpc> after requesting
 notifications, and the agent MAY NOT process <rpc>
 after it starts sending notifications.

 ------

 comments:

 First, what are the choices?

   1) require interleaving MUST be supported by the agent
   2) allow interleaving to be supported by the agent,
      but just warn that the manager SHOULD NOT interleave
      and the agent MAY NOT accept interleaved requests.
   3) allow interleaving to be supported by the agent,
      based on the '#interleave' capability,
      and also warn that the manager SHOULD NOT interleave
      and the agent MAY NOT accept interleaved requests.
   4) require interleaving MUST NOT be supported by the agent
      - what happens when the manager sends an <rpc> anyway?
        a) close session
        b) ignore request
        c) send operation-failed response

 What are the benefits?

 There obvious benefit from allowing interleaving,
 if you believe sessions are expensive -- it saves an extra session
 on both the manager and the agent.

 The real benefit is that <close-session> is a the cleanest way
 to terminate sessions, and it should be used in all modes.
 The <kill-session> and drop connection methods are both bad ideas.

 It would also be a HUGE CLR to forbid interleaving completely.
 In the future, some new feature will come up that will make it
 clear the agent should never be in a mode it MUST stop listening
 to all input from the client.  It will be clear then (if not now)
 that this is a really bad idea.

 So what are the benefits of forbidding interleaving completely,
 and what happens if the manager sends an <rpc> anyway?

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/netconf/trac/ticket/15>
Netconf <http://tools.ietf.org/wg/netconf/trac/>
Issue tracker for the NETCONF Working Group������r��zǧu���Ơz�'z�(��ު笶�l��_��0��m��(�ۧ���r��z)ڲ)���b�欶�z���^���w&�r�zm���Ȟ��+��b��?��\�w�

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Aug 2007 21:34:22 +0200 (CEST)

> #15: <rpc> interleaving during notification delivery mode

I agree to this.  And another benefit is that we would have one single
way all agents will behave, no extra capabilities or anything.  A
manager will know how things work.

So, if I recall correctly, it was Andy and Phil that were most vocal
against interleaving in Monteral.  But I might remember wrong.  Andy
now seems to think interleaving is ok.  We also know that there are at
least two implementations that support interleaving currently.  So can
the WG agree to make interleaving the only option?

/martin

--
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: Andy Bierman <[email-masked]>
Date: Wed, 01 Aug 2007 13:18:13 -0700

Hi Martin,

I do not want to forbid interleaving, but I
also want a capability to control it in an
inter-operable manner.  I want the <close-session> RPC
to be an exception that must be supported by every agent.

We need a couple pictures to clear things up
in our discussions:

Use Case 1)
   No replay mode (interval (B) is zero)
   Replay mode, with no stopTime

       t(0)        t(1)           t(2)                  t(3)
         |    (A)    |    (B)      |   (C)               |
  -------+-----------+-------------+---------------------+
  normal |           | replay mode |  live mode          |
   mode

At time t(0) the <create-subscription> is received.
At time t(1) notification delivery starts.
There may be replay notifications to deliver first,
which ceases at time t(2),
when live notification delivery starts,
and continues to time t(3) when the session is terminated.

  --> Issue: An agent could possibly receive new <rpc> requests
      any time during time intervals (A), (B), and (C).
      What MUST, SHOULD, MAY be done with them

===============================================

Use Case 2)
   Replay mode, with a stopTime

       t(0)        t(1)          t(2)                 t(3)
         |    (A)    |    (B)      |   (C)             |
  -------+-----------+-------------+-------------------+
  normal |           | replay mode | normal mode       |
   mode

At time t(0) the <create-subscription> is received.
At time t(1) notification delivery starts.
The replay notifications are delivered during time interval (B).
When the replay is complete at time t(2), the agent reverts
to normal mode, and continues accepting <rpc> requests until
the session is terminated at time t(3).

  --> Issue: An agent could possibly receive new <rpc> requests
      any time during time intervals (A) and (B).
      What MUST, SHOULD, MAY be done with them during interval (B)?
      What MUST, SHOULD, MAY be done with them at time t(2)?

  --> Issue: Should the agent automatically terminate the session
      for use case 2 at time t(2)?   What MUST, SHOULD, MAY
      language is needed?

> the WG agree to make interleaving the only option?

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 07 Aug 2007 10:23:36 +0200

Hello,
As I remember Phil also complained about that now we have two "modes" of the Netconf session: 
normal mode and notification mode, when something special happens with incoming requests (e.g. 
discard them).

A big benefit of an interleaving-only solution would be that we do not have this modality. The 
manager application can still dedicate the session to notifications simply by not sending any RPC.
Balazs

PS. I wanted interleaving in Montreal.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]