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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 26 Jan 2006 09:06:53 -0800

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

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 26 Jan 2006 11:50:53 -0800

It may be a minor change to the spec.  But, it dramatically changes the
work to implement the spec.  I still see no reason to add this
capability to the protocol.  The protocol does not need to provide a
mechanism to police the implementation of the protocol in a particular
instantiation.  The market will do that.

 -Bob
 
-----Original Message-----
From: Philip Rakity [mailto:[email-masked]] 
Sent: Thursday, January 26, 2006 10:57 AM
To: Pat Calhoun (pacalhou)
Cc: Bob O'Hara (boohara); [email-masked]
Subject: Re: [Capwap] Should be able to Read Back Information Set from
the AC

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

On Jan 26, 2006, at 9:09 AM, Pat Calhoun (pacalhou) wrote:

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

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.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

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

Confirmation exists, through an explicit ack message. Extending
the protocol to allow this then opens up the need for the AC to
periodically poll WTP configs (a la SNMP) to validate local config
store with WTP remote store.

Introduces significant complexity, and frankly, I think we should
just assume that people build systems that can remember basic
instructions.

Pat Calhoun

> Subject: Re: [Capwap] Should be able to Read Back Information 
> Set from the AC
> 
> 
> 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  
> 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
> 
> 
> > 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
> >
> >
> >

---

From: Michael Montemurro <[email-masked]>
Date: Thu, 26 Jan 2006 14:59:52 -0500

Incidentally, this is the reason why we decided to use SNMP payload inside
of our configuration messages when we defined our CTP protocol. 

Cheers,

	Mike

> From: Bob O'Hara (boohara) [mailto:[email-masked]] 
> Sent: January 26, 2006 2:51 PM
> To: [email-masked]
> It may be a minor change to the spec.  But, it dramatically 
> changes the work to implement the spec.  I still see no 
> reason to add this capability to the protocol.  The protocol 
> does not need to provide a mechanism to police the 
> implementation of the protocol in a particular instantiation. 
>  The market will do that.
> 
> 
>  -Bob
>  
> and they

---

From: zhaoyujin 31390 <[email-masked]>
Date: Fri, 27 Jan 2006 10:17:49 +0500

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

I aggree with above description.

Distributed configuration is difficult to maintain. Unfortunately, fit AP solution 
has this problem. So that I think WTP is only a logical part of AC. LWAPP should resolve the problem. When configure on AC, LWAPP should confirm configuration consistence on WTP and AC.

Current LWAPP configuration messages can realized normal configuration from AC to AP. And
if there are some errores, WTP can notify AC with "change event messge".

Best regards

Michael

> 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
> 
> On 1/26/06, David T. Perkins <[email-masked]> wrote:
> > 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
> > On Thu, 26 Jan 2006, Pat Calhoun (pacalhou) wrote:
> > > Further, when an AP comes up, it provides its configuration. 
> So I'm not
> > > > From: Philip Rakity [[email-masked]]
> > > > This makes debugging difficult and in general is not a good 
> idea.> > > For each mesage element