Subject: RE: [Capwap] Should be able to Read Back Information Set from the AC

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Jan 2006 09:09:02 -0800

Further, when an AP comes up, it provides its configuration. So I'm not
sure how/why an AP would have a different config from what the AC told
it.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Bob O'Hara (boohara) 
> Sent: Thursday, January 26, 2006 9:07 AM
> To: Philip Rakity; [email-masked]
> Subject: RE: [Capwap] Should be able to Read Back Information 
> Set from the AC
> 
> I don't believe that debugging is one of the requirements 
> agreed to by the group.  I don't think that readback is 
> necessary to support the operational requirements.
> 
>  -Bob
>  
> -----Original Message-----
> From: Philip Rakity [mailto:[email-masked]]
> Sent: Wednesday, January 25, 2006 6:30 PM
> To: [email-masked]
> Subject: [Capwap] Should be able to Read Back Information Set 
> from the AC
> 
> There is a general problem that one cannot read information 
> that the AC sets from the AP.
> For example the SSID and perhaps other fields.
> 
> This makes debugging difficult and in general is not a good idea.   
> For each mesage element
> such as  IEEE 802.11 Add WLAN there should be a corresponding get.
> 
> 
> Philip Rakity
> [email-masked]
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 26 Jan 2006 10:30:35 -0800 (PST)

HI,

Another way to look at this is the following....

Does the CAPWAP architecture model and protocol support
only WTPs that have a single management interface for
configuration change, which is the CAPWAP protocol.
If so, then, yes, all config changes are applied
via the CAPWAP protocol, and thus there is only
a single reason for the CAPWAP protocol to support
an AC to retrieve config info from an WTP.
That reason would be if an AC was restarted,
and thus, it would have to recover the config
and status of operating WTPs. (When an AC
stops operation, then split MAC WTPs that
tunnel STA traffic to an AC would have to
drop or queue traffic until the AC restarted,
but could keep up the 802.11 session. However,
most likely new authenticated sessions could
not be started. I'm not sure what would be
the effect to local MAC WTPs.)
However, I don't believe the current CAPWAP 
architecture supports WTPs "holding" current
start and "graceful reconnect" with a restarted
AC.

I'm guessing that there may be strong proponents
of WTPs that allow a second management interface
to change config at the WTPs durring real-world
user deployments. If so, I suggest that these
proponents speak up and present a case.
Note that I don't consider developer debugging
as another management interface for applying
config changes, and worth the cost to extend
the CAPWAP architecture and protocol to support it.

Regards,
/david t. perkins

---

From: Philip Rakity <[email-masked]>
Date: Thu, 26 Jan 2006 10:57:04 -0800

It is not unreasonable to be able to confirm that a request one has  
made has been performed.  I can set the SSID but cannot read it back.

  I went a few months ago to the Intel Developers Conference and they  
mentioned they needed to re-architect their chip because they could  
not get read information that was set once the chip came up.   It is  
true that I cannot think of a great reason to be able to do this BUT  
this seems a minor change to the spec.

Philip

Philip Rakity
[email-masked]

This message is hereby marked U4EA CONFIDENTIAL, is intended only for  
the use of the individual or individuals to which it is addressed and  
shall notbe disclose or made available to any other party except with  
the prior written consent of the sender. If the reader of this  
message is not the intended recipient, you are hereby notified that  
any dissemination, distribution or copying of this message is  
strictly prohibited. If you have received this communication in  
error, please notify us immediately by replying to the sender of this  
E-Mail.

---

From: Darren <[email-masked]>
Date: Thu, 26 Jan 2006 13:39:12 -0700

I am strongly in favor of a strict and exclusive, master/slave
relationship between the WTP and AC.  This is especially important to
maintain configuration consistency, one of the main reasons to even
have a CAPWAP protocol.  Having more than one configuration master
creates many complexities.  In my experience, that just doesn't work
in production network environments.

I agree with Pat that the WTP Configuration Request (7.2) and WTP
Configuration Update Response (7.5) should be sufficient to report the
WTP configuration and confirm that a configuration update was applied.

-Darren