Subject: [Netconf] 4741bis, issue 14, capabilities changed error

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Dec 2009 13:46:56 -0800

Hi,

There is an open issue related to the server behavior
for the current sessions if and when the set of available
capabilities is changed.

There seems to be some consensus for requiring the server
to send an operation-failed error with an error-app-tag
of 'capabilities-changed', in response to any <rpc>
received after the capability change.

This would force a client to close the session and open a
new one instead, in order to get the updated capabilities.

Some people thought the server MAY send this error,
instead of MUST/SHOULD send this error.
There is no real way within the standard to
specify how a server would know it is safe
to continue.

An important concern is how this new behavior is
identified by the client.  A 4741 server is
not required to do anything special when a capability
changes, so it must remain OK for a 4741 server to
do whatever it is doing now, wrt/ this issue.

There are no proposed edits at this time.
The WG needs to decide on a basic solution
approach first:

  A) server MUST send error; client needs to
     start a new session; increment protocol version
     so 4741 servers remain compliant.

  B) server MAY send error; client may need to
     start a new session

  C) server MUST send error; add additional mechanisms
     such as a clear-capability-changed-error() RPC
     and a capability-changed notification;
     increment protocol version

  D) do nothing; wait until NETCONF 1.1 to address this issue

  E) ???

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Dec 2009 23:11:59 +0100

>   B) server MAY send error; client may need to

B) is not very helpful for clients since they can't rely on MAY
behaviour. If the number of real deployments where capabilities
changes is large enough that we can't do A), we should not do B)
instead.

>      increment protocol version

And / or add a hello() operation that can be invoked to synchronize a
client to the capabilities of a server by essentially doing another
hello exchange with proper RPC framing.

>   D) do nothing; wait until NETCONF 1.1 to address this issue

As long as our goal for the RFC4741 update is to not to bump the
protocol version number, I suggest we do D) by adding explicit text
that the behaviour in this case is undefined and adding an item to a
"things to consider for 1.1" appendix so we can track this issue and
people are warned that something might change here in NETCONF 1.1.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Dec 2009 14:20:26 -0800

> people are warned that something might change here in NETCONF 1.1.

(D) seems OK to me.
I prefer to get 4741bis done ASAP, without any new capabilities.
Then later, bundle a lot of new features/improvements into a 1.1
version released in late 2011. When YANG is published and used a bit,
it will be more clear how NETCONF needs to evolve to support it.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 9 Dec 2009 08:31:41 -0500

>changes is large enough that we can't do A), we should not do B)

But it is helpful, since the server can look at the RPC before
sending an error.  Clients would not be forced to redo a connection
just to issue a "reboot" operation after a software install.

I also lean towards (D) since I can't see adding this error in a
backwards-compatible way.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Dec 2009 22:14:52 +0100 (CET)

> do whatever it is doing now, wrt/ this issue.

The problem is that 4741 doesn't say if the capabilities can change
during a session or not.  This is what we need to clarify.

If we do alternative D - do nothing - this will remain unclear, and
interoperability will suffer.

If a server is allowed to change capabilities without letting the
client know, what good is the hello message anyway?  In the extreme
case, I can let my server advertise all known capabilites, and then
claim that 1 millisecond later my capabilites changed into "base:1.0"
only.

I think it is clear from 4741 that the advertisement of capabilites is
to let the client know what to expect from the server - it is the
definition of the contract between the client and server.  Without a
resync mechanism, I think the only way to handle this is to not allow
capabilites to change.

This is why I proposed the following text in 
http://www.ietf.org/mail-archive/web/netconf/current/msg04512.html:

  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.

Provided that 'capabilities-changed' is an error-app-tag, this is
backwards compatible.

If we want to create a new fancy mechanism to resync modified
capabilities, I agree we can do that in netconf 1.1.

/martin

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Dec 2009 13:28:16 -0800

>   to any request other than <close-session> if its capabilities has

I agree with Phil that this is a vendor-specific
detail, and there are many mechanisms that might be used
to deal with changing capabilities, or the specific operation
may not be affected by the capability change at all.

> capabilities, I agree we can do that in netconf 1.1.

Why bother doing anything now?
We are lumping all capabilities together,
including unknown vendor capabilities,
and declaring a very harsh CLR for no apparent reason.

If you want to say that those rules apply only
to standard capabilities, and not vendor or YANG module
capabilities, then that is OK.

I have mechanisms implemented that automatically keep the
modules in synch on the client, so why should I lock down all sessions
just because a module was loaded into the system?  That is
an operationally-unfriendly side effect of the <load> operation.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 Dec 2009 23:02:05 +0100 (CET)

> may not be affected by the capability change at all.

The last issue is covered by the text I proposed.

> an operationally-unfriendly side effect of the <load> operation.

First of all, if you read my proposal you will see that I did not
suggest that you lock down all sessions just because a module is
loaded into the system.

Second - the reason for doing anything at all is interoperability.
Maybe my client does not understand your vendor specific mechanisms
for keeping capabilities in synch.  By using a standardized error, it
can still handle the situation.

If the WG does not want to solve the problem, I still think D is a bad
choice.  We should at least say that it is implementation specific if
capabilites can change during the session or not.

/martin