Actually, this is an issue with multiple sub-issues. I would
like to
discuss each sub-issue:
1) Config changes can fail (even when they are "not
suppose to").
This may be due to
a) resource deletion
b) semantic constraints
c) hardware failures
d) software failures
e) lack of authorization
In the "configure request/response" (sections
7.2/7.3) , the
"response" message specifies configuration
settings. As
described, there is no mechanism for the WTP to
communicate
to the AC that some (or part) of the config sent by the
AC
to WTP failed. Thus, I suggest that the response
contain
no configuration.
<PRC> This is a duplicate of issue 73, which I believe
we have
satisfied.
2) I'm not sure that all of the configuration info can fit
into one CAPWAP control message. However, a WTP needs
to
be able to indicate to a AC the "classes" of
config info
that it supports. SNMP uses the GETNEXT operation to
iterate through both all classes and instances of
management info (which includes config info). I suggest
for CAPWAP that a WTP specify in the "configure
request" the classes of configuration info and
then
allow an AC to use one or more "Update config
request"
messages to change the WTP config.
<PRC> I believe Michael and I responded to this via
another email
thread that neither one of us understood why the existing
fragmentation
mechanism supported by CAPWAP does not resolve this issue.
3) When an AC changes the WTP config with an "Update
config
request", the request can fail. The response
message needs
to indicate which config message element(s) had an
error
and what was the error. Currently, this is not the
case.
(The error code in the result, as currently defined
makes no sense to me!) Also, I didn't see if a config
request was "all or nothing". That is, do the
OK
config values get applied and the error one not,
or none get applied on any failure.
<PRC> This is a duplicate of issue 73, which I believe
we have
satisfied.
4) There are a lot of stange (too me) and not well defined
config elements. I believe that all need to be
reviewed,
but this is really a separate issue.
<PRC> As mentioned, this is a separate issue, and is
therefore not
germane to issue 108.
5) A get config operation is needed that specifies at
least a class of configuration info, and possibly
additionally the instance of config info. (Again,
this is because not all config info will be able to
fit in a single CAPWAP message.)
<PRC> I do not understand the request here. Is this a
duplicate of issue 72, which is a request to have the AC
pull the WTPs configuration?
6) I've ignored what should be done when an WTP has
config info that is not supported by an AC, or
when an AC tries to modify config info (class or
specific values) that is not supported by the WTP.
(CAPWAP is suppose to support WTPs and ACs from
different vendors, and, thus, there can be no
"tight version synchonization" as found in
current
products.
<PRC> I believe this is already addressed via the
proposed text
for issue 73, which is done by including the Result Code set
to
10 Failure (Unable to Apply Requested Configuration -
Service
Provided Anyhow), and including the Returned Message
Element, included
here as well:
<text>
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Message Element...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason: The reason why the configuration in the
offending message
element could not be applied by the WTP
1 - Unknown Message Element
2 - Unsupported Message Element
3 - Unknown Message Element Value
4 - Unsupported Message Element Value
Message Element: The Message Element field encapsulates
the message
element sent by the AC in the Configuration Status
Response
message that caused the error.
</text>
So it appears that there are two sub-issues that have not
been addressed
already,
sub-issues 2 and 5. Michael and I questioned whether 2 is a
real problem
or not,
and I believe sub-issue 5 is not specified sufficiently for
me to
understand. I
therefore do not believe that we are have sufficiently
addressed this
issue, but
should reject this issue.
Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
> -----Original Message-----
> From: Michael Montemurro [mailto:montemurro.michael gmail.com]
> Sent: Tuesday, January 16, 2007 3:39 AM
> To: capwap
> Subject: [Capwap] Proposed resolution to issue 108
>
> This issue deals with configuration failure processing
>
> The process would work in the following manner:
>
> 1) The AC retrieves the WTP configuration when the WTP
> connects to the AC.
> 2) The WTP request configuration from the AC; the AC
responds
> with a configuration.
> 3) The capability has been added for the WTP to return
a
> failure result code in the State Change Event message
to
> indicate that the configuration has not been applied.
> 4) The AC has the capability to update the
configuration of
> the WTP while it is connected.
>
____________________________________________________________
_____
> To unsubscribe or modify your subscription options,
please visit:
> htt
p://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lis
ts.frascone.com/pipermail/capwap
>
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
htt
p://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lis
ts.frascone.com/pipermail/capwap
|