Subject: RE: [Capwap] Additional Comments on LWAPP

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 20 Jan 2006 11:12:18 -0800

> General Comment:  Radio ID's are limited to be between 0 and 
> 7 inclusive. 
> The definition of Radio ID in the fields should show this 
> limited range -- one byte allocated but only 8 values allowed.

A previous comment of yours caught caused me to catch this one already.
It will be fixed in the first rev.

> 
> Page 35 -- 5.2.1 AC address
> I do not understand this.  It is not useful with a layer 3 
> transport.  If using a layer 2 transport then I would assume 
> the broadcast or multicast from the Discovery Message would 
> have been heard by any other AC's -- so rather than respond 
> -- would it not be best to stay silent?

I believe you are correct that this information element is not required
for layer 3, and can be removed. I've added this to tracker.

> 
> General Comment:  Is there a case where one has a simple 
> discovery agent running in dumb hardware -- its only purpose 
> is to redirect the WTP to the real AC?  There seems to be 
> hints of this possibility but it is not spelled out.

There are many things one can do with the protocol, but I think we 
should leave implementors determine what they can, and cannot, do.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, December 14, 2005 3:40 PM
> To: [email-masked]
> Subject: [Capwap] Additional Comments on LWAPP
> 
> 
> 
> 
> 
> Philip
> 
> 
> 
> _________________________________________________________________
> 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: Darren <[email-masked]>
Date: Tue, 24 Jan 2006 16:27:50 -0700

Regarding 5.2.1 AC Address,  I think there could still be use for this
information.  As Philip started to point out, it's possible that an AC
might want to refer a WTP to a different address than the WTP first
discovered.

I suppose there are other ways to direct WTP's to discover alternative
AC's, such as via multiple DNS A records or SRV records.  So perhaps
the AC address is not really needed even for a sort of redirection or
load balancing.

-Darren Loher

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 24 Jan 2006 16:37:02 -0800 (PST)

HI,

Let's backup here to understand the big picture before specifying
the details.

Currently, the CAPWAP architecture for which the protocol
is being standardized consists of
 1) a collection of WTPs
 2) a single AC
 3) an L2 or L3 interconnection cloud between the WTPs
    and single AC
 4) a protocol between the single AC and each WTP that
    allows the AC to configure(provision), control,
    monitor, and potentially tunnel wireless client
    stattion data frames between an WTP and AC

Thus, there is no concept of multiple ACs such as
for robustness using a "backup AC", or scaling with
load balancing WTPs amoung a set of cooperating ACs.

The LWAPP specification, unfortunately, has impurities that
suggests a richer architecture that contains multiple ACs.

It seems to me that the WG needs to determine the scope
of version 1.0 of the CAPWAP architecture and protocol.
If it is a single AC, then the impurities due to multiple
ACs should be removed. Otherwise, the architecture should
be extended to describe what features are to be addressed
by multiple ACs. Note that even in a single AC architecture,
the protocol must cope with rogue ACs (and WTPs).

> > CTO, Wireless Networking Business Unit

Regards,
/david t. perkins