Subject: Re: [Capwap] Insufficient description of WTPs during discovery

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 12 Sep 2006 12:43:17 -0700

> It appears that you might have misunderstood the first point, 
> and I was hoping for a lot more on the second point.
> 
> The first is not which entity establishes the DTLS sessionn 
> (but if you wish, we can revisit that discussion). The point 
> is how an WTP decides which AC to establish that session.
> And yes, as long as a WTP establishes the session, it must 
> ultimately decide. The issue is how it decides. 
> 
> The CAPWAP-02 has the WTP deciding based on some AC 
> utilization info. I believe where there is a split in the WP 
> is whether or not AC utilization is appropriate factor in a 
> WTP's decision, and whether or not providing AC utlitzation 
> and WTP capabilities in the clear durring discovery is appropriate.

Not really.

The decision was based on pre-configuration, DHCP, broadcast/mcast
discovery, DNS, etc. Once the WTP had a list of ACs to connect to, it
would then use the pre-configured priority list, and assuming none, it
would make use of AC utilization.

> 
> For the second point, I was hope that you would list 
> scenarios like initial enrolement, reboot after saved config, 
> referal by another AC, recover after redeployment, etc.

So the above is the general rule. Are you stating this is missing?
That's a separate topic that we could certainly look deeper into.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
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: Tue, 12 Sep 2006 13:40:09 -0700 (PDT)

HI,

> would make use of AC utilization.

You are decribing process that that has very skippy details in
the CAPWAP-02 doc. There are concerns about latency, non-determination,
recovery during short term network problems, and longer term
problems that are not there. That is always having the WTP
sending discovery requests, building a list, comparing the list
with existing configuration, trying the establish is NOT the
appropriate behavior in all situations. 

> That's a separate topic that we could certainly look deeper into.

The scenarios affect the desired outcomes. We need the
scenarios so that we can verify that the process yields
the desired outcomes.

I hope you have heard the term "ladder climb". This is
a visual reminder of the cost of having to "touch a WTP". With
network gear in a wiring closet, a "truck roll" is expensive,
but a "ladder climb" can be quite a bit more. Because of
the cost in touching a box to put it in a known state so
that recover can happen, it is VERY important that we
go through the scenarios and make sure the procedure for
all is appropriate.

Having a procedure that broadcasts AC and WTP information
in the clear is not desirable.

Having a proprietary way (such as via a CLI) to tell an AC
the mapping between WTP model number and capabilities is
not an unreasonable cost. (It's done by a a vendor at
compile time for their products. Extending this to support
config time is not that much. Been there, done that.)

> CTO, Wireless Networking Business Unit
Regards,
/david t. perkins