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

[Andy Bierman <ietf@andybierman.com>]

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?




> "Netconf" <trac@tools.ietf.org> wrote:
> > #15: <rpc> interleaving during notification delivery mode
> > ---------------------------------------------+------------------------------
> >  Reporter:  ietf@andybierman.com             |       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.
>
> 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

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