Subject: Re: [Netconf] dynamic capabilities

From: "Mark Scott" <[email-masked]>
Date: Mon, 4 May 2009 12:54:55 -0400

Martin and Balazs,

Suggest we allow for an explicit client re-synch as an alternative to
forcing the session to be closed:

  The capabilities of a NETCONF server MAY change over time.  However,
  once a NETCONF server has announced its capabilities in the <hello>
  message, the capabilities for that session SHOULD NOT change unless 
  the server supports the change and the client has requested the
revised
  capabilities for that session.

  Once a server has modified its capabilities:

  A server MUST reply with a 'capabilities-changed' error if the client
  sends a request which is affected by a modified capability.

  A server MAY choose to send 'capabilities-changed' as the response
  to any request other than <close-session> if its capabilities has
  changed.

  A server MAY stop sending 'capabilities-changed' to a specific
  session after a <get-schema> response has been sent to that session.

This gives flexibility to preserve a session in cases where a dynamic
change (e.g. feature activation adds new model, hitless patch revs an
interface, etc) can be supported (or ignored) by both server and client.
Server can allow a specific client to continue if it explicitly requests
the revised capabilities.  Server can also force any session closure by
always replying 'capabilities-changed' even if the client requested
<get-schema>.

I think this approach would address the concerns raised on this issue
and allows for either simple implementations (force session close) or
more sophisticated (clear the error on synch).

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Martin Bjorklund
Sent: Wednesday, April 15, 2009 8:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] dynamic capabilities

Balazs Lengyel <[email-masked]> wrote:
> 
> 
> Martin Bjorklund wrote:
> > Juergen Schoenwaelder <[email-masked]> wrote:
> >> I believe it depends on the nature of a given capability change
> >> whether this should cause a reaction in terms or an error state or
can
> >> be ignored. And to keep implementation costs reasonable, I believe
the
> >> server wants to decided based on the semantics of the capability
> >> change whether it (a) does nothing or (b) signals the capability
> >> change by throwing capability change errors. Having only certain
> >> affected operations fail seems like a lot of complexity on the
server
> >> side which will likely no honored on the client side. 
> > Agreed.
> > 
> >> This actually sounds a little bit like the defaults debate; perhaps
> >> the answer is to let the client tell the server which behaviour the
> >> client wants...
> > I don't think we should use :with-default as a blueprint for other
> > capabilities, if we can avoid it... It adds complexity to the system
> > ("system" as in clients and servers).
> > In this particular case I hope we can find a simpler solution.  My
> > proposal is to specify the error 'capabilities-changed', but let the
> > server itself decide if it will issues it just for affected
> > operations, or for all operations.
> > 
> Sound nice to me. So is the following text what we are looking for:
> 
> The capabilities of a NETCONF server may change during a NETCONF
session. If
> capabilities change, the server MAY answer any RPC request with a
> 'capabilities-changed' error message; except the <close-session>
> request. Unless the server can assure that the capability change does
not
> affect a specific RPC request, it MUST answer the requests with a
> 'capabilities-changed' error message.

Hm.  IMO the point of sending 'capabilities-changed' error is because
we want to make sure that the announced capabilities does NOT change
in a session.  So I would rather see something like:

  The capabilities of a NETCONF server may change over time.  However,
  once a NETCONF server has announced its capabilities in the <hello>
  message, the capabilities for that session MUST NOT change.  A
  server MUST reply with a 'capabilities-changed' error if the client
  sends a request which is affected by a modified capability.

And maybe add:

  A server MAY choose to send 'capabilities-changed' as the response
  to any request other than <close-session> if its capabilities has
  changed.

/martin
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 May 2009 10:44:30 +0200 (CEST)

Hi,

> forcing the session to be closed:

This is also what Juergen suggested in
http://www.ietf.org/mail-archive/web/netconf/current/msg04471.html.

>   session after a <get-schema> response has been sent to that session.

I think re-synch is overkill (it's trivial to close and open a new
channel), but if we do re-synch, I don't think <get-schema> is the
right operation.  <get-schema> retrieves one complete schema, but what
is needed is a list of all new capability uris.

/martin

---

From: "Mark Scott" <[email-masked]>
Date: Tue, 5 May 2009 12:15:50 -0400

Thx Martin,

My rationale for avoiding the new session is that in our case this
triggers client initialization/data synch which would be unnecessary in
many cases.  So I would like the client to have the ability to preserve
the session if both the server and client can handle the change and
explicitly choose to do so.  (I'm assuming this was Juergen's rationale
as well).

On the <get-schema> point I may have misinterpreted that servers are
expected to know the specific impacts of the capabilities change - i.e.
they would selectively choose to send 'capabilities-changed' to any (not
'all') messages other than <close-session>.  Meaning that they know
which specific schema(s) need to be synched since they know which
specific requests they would reply with that error (?).

If that wasn't the intent then suggest we change these two qualifiers to
be:

   A server MAY choose to send 'capabilities-changed' as the response
   to ALL requests other than <close-session> if its capabilities has
   changed.

   A server MAY stop sending 'capabilities-changed' to a specific
   session after the /netconf-state/capabilities subtree has been
   queried by that session.

OR if it was then (my personal preference):

   A server MAY choose to send 'capabilities-changed' as the response
   to any requests other than <close-session> if its capabilities has
   changed.

   A server MAY stop sending 'capabilities-changed' to a specific
   session after a <get-schema> response has been sent to that session
   for the specific responses which were impacted by the change.
 
Again, for servers and/or clients that want to handle this more simply
they both have control.  A server could send the 'capabilities-changed'
error to all requests that any client makes existing sessions (incl.
attempts to query the schemas).  Any client can trigger new session on
first instance of the 'capabilities-changed' error independent of
whether the server allows the resynch or not.

cheers,
Mark

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 4:45 AM
To: Scott, Mark (CAR:2N00)
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] dynamic capabilities

Hi,

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 May 2009 10:57:08 -0700

> explicitly choose to do so.  (I'm assuming this was Juergen's rationale

This proposal doesn't make a lot of sense.
If a mechanism to turn off the capability-changed
error is needed, then add it explicitly.
I agree with Martin that starting a new session is good enough.

I don't see how the manager is helped by all the optional
agent behavior.  I prefer a more deterministic agent design, i.e.,
The agent MUST return the capability-changed error (except safe RPCs ***)
unless the session has invoked the <turn-off-capability-changed-error/>
operation.

*** close-session, kill-session, get-schema,
     turn-off-capability-changed-error, lock, unlock,
     partial-lock, partial-unlock, discard-changes

Andy

---

From: "Mark Scott" <[email-masked]>
Date: Tue, 5 May 2009 14:12:38 -0400

Andy,

I'm not sure what specifically doesn't make sense about wanting to
preserve the session but the proposed alternative (explicit command to
turn off capabilities-changed error) achieves the same goal.  So I'm
fine with that as well.

I would be interested if others have opinions on which approach is
desirable?

I also like the explicit list of 'safe' RPCs when in changed
capabilities state and will include these in next update to the draft.

Mark

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 1:57 PM
To: Scott, Mark (CAR:2N00)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] dynamic capabilities

I don't see how the manager is helped by all the optional
agent behavior.  I prefer a more deterministic agent design, i.e.,
The agent MUST return the capability-changed error (except safe RPCs
***)
unless the session has invoked the <turn-off-capability-changed-error/>
operation.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 May 2009 22:11:27 +0200 (CEST)

Hi,

> specific requests they would reply with that error (?).

I just meant that another rpc operation is needed for capability
re-sync, if we decide to do that.  Maybe <get-capabilities/> which
would return the capability list as defined in the <hello> msg.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 May 2009 22:23:27 +0200 (CEST)

Hi,

> capabilities state and will include these in next update to the draft.

Should this go into the monitoring draft, or should parts of it
(everything?) go into 4741bis?  I think 4741bis needs to spell out
if/how capabilities are allowed to changed.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 05 May 2009 13:44:17 -0700

> if/how capabilities are allowed to changed.

I agree.  I was wondering what 'next update of the draft' meant.
Capabilities are part of the protocol, not specific or
constrained to monitoring.

Andy

---

From: "Mark Scott" <[email-masked]>
Date: Wed, 6 May 2009 10:45:31 -0400

I think it belongs in 4741bis.

Mark

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 4:23 PM
To: Scott, Mark (CAR:2N00)
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] dynamic capabilities

Hi,

/martin