Subject: [Netconf] dynamic capabilities

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Apr 2009 22:28:33 +0200 (CEST)

Hi,

This is an issue that needs to be clarified in 4741bis, and it needs
to be resolved before the monitoring draft can be completed (as noted
at IETF74).

The question is if a server is allowed to dynamically change its
capability list, as advertised in the <hello> message, during the
lifetime of a session.

One solution is to say that a server MUST NOT change its capability
list in ongoing sessions.  This makes it very clear and easy for the
client.  The question is what to do with existing sessions if the
supported capabilities change.  They could be killed by the server, or
enter a state where commands related to changed capabilities would
fail.

An alternative is to say that servers are allowed to change its
capabilities on the fly.  But then the question is how a client can
tell that this happened?  Some people have suggested that a
notification can be used, but unless the :interleave capability is
supported, this would require each client to have a separate session
to monitor this.

Personally, I prefer the first alternative b/c it is simpler.  I think
it will be difficult to make the second alternative work.

Comments?  Other solutions?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Apr 2009 13:42:05 -0700

> Comments?  Other solutions?

I agree with you on solution 1.
Notifications may not be implemented or enabled.
Another option would be to put the affected session(s)
in a state where every RPC request fails with
a 'capabilities-changed' error-app-tag on an 'operation-failed'
error.  This at least lets the manager issue the close-session
knowing what happened.  Blowing up the session will lead
to debugging headaches for operators.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 06 Apr 2009 23:47:05 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> error.

Yes, that's what I had in mind when I wrote "enter a state".  Except
for 'close-session' :)  The easiest is probably to do this for all
active sessions when the new capabilities are installed.  A more
complex scheme could be to send this error only when an operation
related to a modified capability is given by the client.  But I don't
think it is worth the complexity.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Apr 2009 10:25:13 +0200 (CEST)

WashamFan <[email-masked]> wrote:
> Hi,
> 
> Capabilities DO shift during a ongoing session, right?

It is clear that the capabilities of a device change over time,
e.g. when a new software image is installed.  The question is how this
affects NETCONF sessions.

> So we should react to that whatever in a 
> complex or simple way insteading of just ignoring it.

Absolutely; this needs to be clarified in 4741bis.

> Do capabilities change affect all active sessions or 
> a subset ones? IMO, capabilities addition does not
> affect all active sessions much, but capabilities removal
> do affect relevant sessions to cause relevant operations
> to fail.

This very much depends on the capability itself.  For example, suppose
:partial-lock is added dynamically.  In this case it would be safe to
just continue all existing sessions.  But if a capability that defines
a data model is added, existing session might not be able to handle
this correctly.

IMO, the simple solution that Andy suggested is good enough.  This is
not something that we expect happen "often", and when it happens, the
manager just has to close and reopen the NETCONF session (which might
be as simple as close the channel and open a new one).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Apr 2009 10:52:45 +0200 (CEST)

WashamFan <[email-masked]> wrote:
> The added data model is not included in the "contract" agreed by manager
> and agent when <hello> exchange, how does it affect the existing session?

If they do a <get-config> or <copy-config> they might get data from
the new model.  Or if there are references between data models they
might get errors pointing out data from a data model that hasn't been
advertised.

Even more difficult to handle is if an existing data model has been
upgraded, i.e. the new capability is a new version of an existing
one.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 7 Apr 2009 08:09:51 -0400

>think it is worth the complexity.

My concern would be that a session would be put into this
"inoperable" state when something unimportant (or at least
unimportant to that session) changes.  If a PIC is inserted
that carries new config (and its capability), my session
that is simply draining notifications shouldn't be affected.

Another scenario to beware of is software installation.  If
the act of installing sw means capabilities change, then the
session I'm using to install the sw becomes inoperable.  If
I have a multiphase install mechanism (like a confirmation),
I won't be able to finish the install because my session is
now dead.

I think it's simpler and more normal to allow a client to
track capability change _if_ they care.  Most won't.  The
complexity isn't worthwhile on the client side either.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 7 Apr 2009 08:13:00 -0400

>a data model is added, existing session might not be able to handle

My guess is that the large and important changes (adding :candidate or
:partial) won't be happening once the box is deployed, so these are
less of an issue.

If the issue is the data model, what will happen when "features"
change?  Will the session also become inoperable?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Apr 2009 15:41:30 +0200 (CEST)

> I won't be able to finish the install because my session is

It seems we have three variations on the same theme; sessions must
behave as if the advertised capabilities do not change.  The three
variations would be:

  1) kill all sessions

  2) let all sessions enter a state where they get a
     'capabilities-changed' error for any operation but close-session

  3) let sessions continue, and "some" operations will continue to
     work, but some other will fail with an 'capabilities-changed'
     error.

Can we let this be an implementation choice?  I.e. the general idea
must be supported, but implementations can choose to do this in any
of the three ways (or other ways).

> track capability change _if_ they care.

I'm not sure I understand.  Are you suggesting that some kind of
change notification should be generated so that clients can track
them?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Apr 2009 15:43:30 +0200 (CEST)

> change?  Will the session also become inoperable?

This is a capability change, and it will be treated as the other
capability changes.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2009 15:45:22 +0200

>      work, but some other will fail with an 'capabilities-changed'

A variation of 2) could be to return a 'capabilities-changed' error
until the client has resynchronized the capabilites. Unfortunately,
the hello message is not a normal RPC, otherwise invoking the hello
rpc could simply have cleared the 'capabilities-changed' error without
having to close the session...

/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, 07 Apr 2009 07:05:25 -0700

> change notification should be generated so that clients can track

I prefer (2).
It is simple and the cost for the manager to
restart a session is very low.
There is no way for the agent to know what
changed just because a capability URI is added/deleted/changed.
Capability semantics are located in the description-stmt.
The agent will not likely know which exact operations
or data have changed for each open session.

Another option is to do nothing and let the open sessions
flail and fail, or work fine, depending on the exact changes.
No special error would be returned -- just the normal errors
that would occur if the manager and agent are not using
the same schema.  This is implementable.  Switching to a
special capabilities-changed error for certain operations
may not be implementable by the agent.  In this case,
the manager will not be given a 'capability-changed' error.
Is it important that this error be reliable?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 7 Apr 2009 10:30:39 -0400

>of the three ways (or other ways).

Define the error and say that servers MAY return the error, leaving
it up to the implementation to decide if it needs/wants to.

>change notification should be generated so that clients can track

My client may be brainless and uncaring about capability changes.
Making it care adds complexity on the client side.  For example, I
have a script that does six RPCs that fetch data from the box, and
I can currently build a file with the hello and those six RPCs and
run "ssh -s router netconf < file" and things will work.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 07 Apr 2009 07:54:11 -0700

> it up to the implementation to decide if it needs/wants to.

good idea -- I was going to say,
if the agent knows for sure the RPC is OK
for a particular session to use, then
let it run.  Otherwise, return 'capabilities-changed' error-app-tag
on operation-failed error.  Always allow <close-session>
to run.

> run "ssh -s router netconf < file" and things will work.

this is fragile in any context, not just this one.
Ignore the <rpc-reply> at your own risk ;-)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2009 19:05:49 +0200

> run "ssh -s router netconf < file" and things will work.

I heard you talking about robustness before and now you say we should
optimizing for scripts that can fail in arbitrary ways because they
assume there is never ever going to be a NETCONF processing error...

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. 

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

/js

---

From: WashamFan <[email-masked]>
Date: Tue, 07 Apr 2009 16:43:13 +0800

washam

---

From: Phil Shafer <[email-masked]>
Date: Tue, 7 Apr 2009 15:14:52 -0400

>assume there is never ever going to be a NETCONF processing error...

Sure, because I see a wide spectrum of potential clients.  I want
smart clients to be able to do smart things in a robust and
breath-takingly amazing way, but I also want stupid shell
script clients to be able to work.

>the answer is to let the client tell the server which behaviour the

That should be fine.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 07 Apr 2009 13:26:31 -0700

> script clients to be able to work.

NETCONF was never intended to be used in a way
where the <rpc-reply> could be ignored by the manager.
This is not a valid use-case.

> _____

Andy

---

From: WashamFan <[email-masked]>
Date: Wed, 08 Apr 2009 12:03:53 +0800

>       work, but some other will fail with an 'capabilities-changed'

I suggest a variant of 2)

2*) let all sessions enter a state where they get a
      'capabilities-changed' warning for any operation but close-session

Why block all operations even those didn't get affected? If manager
can't understand the rpc-reply due to new data model added, for
example, it can reference the warnig info, otherwise ignore the warning.
I.e., when there are something error or I do not understand happen, I 
will refer to the warning info, otherwise I could ignore the warning info.

washam

---

From: WashamFan <[email-masked]>
Date: Tue, 07 Apr 2009 10:26:56 +0800

Hi,

Do capabilities change affect all active sessions or 
a subset ones? IMO, capabilities addition does not
affect all active sessions much, but capabilities removal
do affect relevant sessions to cause relevant operations
to fail. So, not all capabilities changes but only capabilities
removal affect not all active sessions but only relevant
sessions much(Yes, relevant sessions could equal to all sessions).

Monitoring should reflect capabilities change. But the current
text only monitors the entire set of  capabilites supported in 
a device, maybe capabilites change per session should be 
specified.

Notification should reflect capabilities change. And the content
includes the capabilities changes in the session should be 
specified further.

In request/response process, there are some suggestions:
(1) just say a session MUST NOT do the change, <kill-session>
is expected by server when some changes happen.
(2) every rpc in affected session fails with error info indicating
the change. (<kill-session> is expected by client)
(3) every rpc in affected session fails with error info indicating
the change. (<kill-session> is expected by client)
(4) just affected rpcs in affected sessions fail with error info indicating
the change. 

I prefer (4), close sessions just when it is needed. And is there
any indicator to capabilities change in (1)?

Comments?

washam

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 14 Apr 2009 08:04:28 +0200 (CEST)

WashamFan <[email-masked]> wrote:
> Why block all operations even those didn't get affected?

That's what 3) above takes care of - the server knows which operations
are affected, and accepts them.  The other, affected operations, fail
with the 'capabilities-changed' error code.

The problem with issuing a warning is that the behaviour of warnings
are a bit unclear in 4741.  This is something we need to dicsuss for
4741bis.

> If manager

This seems fragile to me.  If an operation returns an error and an
'capabilities-changed' error, how can the client tell if the error was
due to the changed capability or something else?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 14 Apr 2009 08:15:08 +0200 (CEST)

> side which will likely no honored on the client side. 

Agreed.

> the answer is to let the client tell the server which behaviour the

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.

/martin

---

From: WashamFan <[email-masked]>
Date: Tue, 14 Apr 2009 15:14:16 +0800

>  due to the changed capability or something else?

I don't think 'capabilities-changed' is a direct answer to why an operation
failed or why agent can't understand requested data? For example: 
a manger issues an operation to a agent, but the capability supporting 
the operation has been deleted. Then 'operation-not-supported' (maybe followed
by 'capabilities-changed') error should be returned. For the same token,
'data-missing' error(maybe followed by 'capabilities-changed') should be 
returned if relevant data model is deleted.That is why I consider 
'capabilities-changed' as a warning more than an error. But as you mentiond, 
use of warning is unclear now.

You suggest let agent decide whether 'capabilities-changed' error is returned to
1) affected operations or 2) all operations. With 1), a manager can not know
capabilities changed until it issues an affected operation, with 2), unaffected
operation is affected eventually. I just want to give even affected operations a
*warning* to help manager determine whether continue or terminate the session.

washam

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 14 Apr 2009 10:11:33 +0200

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

It would also be nice to define a standard 'capabilities-changed' notification, that might be 
used by manager SW.

Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Apr 2009 14:12:17 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> 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

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