Subject: [Capwap] Proposed resolution to issue 108

From: "Michael Montemurro" <[email-masked]>
Date: Tue, 16 Jan 2007 06:39:03 -0500

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:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 17 Jan 2007 06:41:25 -0800

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:[email-masked]] 
> Sent: Tuesday, January 16, 2007 3:39 AM
> To: capwap
> Subject: [Capwap] Proposed resolution to issue 108
> 
> 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.

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 25 Jan 2007 20:56:10 -0800

During the interim meeting, we discussed this issue and agreed this is a
duplicate of 
issues 72, 73 and 173. The only exception is issue 4, which is not
considered actionable.

The issue will be closed as a duplicate of the above issues.

Pat Calhoun

> From: Pat Calhoun (pacalhou) 
> Sent: Wednesday, January 17, 2007 6:41 AM
> To: Michael Montemurro; capwap
> Subject: Re: [Capwap] Proposed resolution to issue 108
> 
> Actually, this is an issue with multiple sub-issues. I would 
> like to discuss each sub-issue:
> 
> <PRC> This is a duplicate of issue 73, which I believe we 
> have satisfied.
> 
> <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.
> 
> <PRC> This is a duplicate of issue 73, which I believe we 
> have satisfied.
> 
> <PRC> As mentioned, this is a separate issue, and is 
> therefore not germane to issue 108.
> 
> duplicate of issue 72, which is a request to have the AC pull 
> the WTPs configuration?
> 
> <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
> 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
> > 1) The AC retrieves the WTP configuration when the WTP 
> connects to the 
> > AC.