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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Sep 2006 10:09:47 -0700

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

I disagree. I don't believe that it is the IETF's place to dictate
device behavior. We are here to provide a standards specification 
that ensures interoperability. However, the issues you list are 
how vendors differentiate, and implementations issues. We provide 
the tools - vendors create systems out of them.

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

I have multiple products that implement a derivative of CAPWAP,
and none of my customers require a truck roll/ladder climb. So I
don't believe the issue you describe exists.

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

Again disagree. The "in the clear" information allows the WTP to
connect to the AC, in an authenticated fashion, at which time the
same data that caused the connection to exist to be exchanged as an
authenticated confirmation. Yes, one could spoof Discovery Responses,
but the data will again be confirmed post authentication.

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

I don't understand how a vendor can compile what AC to connect to. The
developer has no idea what IP addresses, or devices, are available
at the customer site. Again, CLI can be an option, but MUST NOT be 
made mandatory. CAPWAP is *the* management interface.

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: Wed, 13 Sep 2006 12:07:55 -0700 (PDT)

HI,

Your response appears to confirm  the staring point that I made
in this discussion, which is there is a fundamental disagreement
between the approaches, and there is not an effective
way to resolve it. 

I don't know how to constructively respond to the following:
   "I don't believe that it is the IETF's place to dictate
   device behavior. We are here to provide a standards
   specification that ensures interoperability."
since IETF specifications are essentially definitions
of behaviors.

By the way, I've read some release notes from updates of
shipping products. And there have been problems with
some of the approaches that were specified in the earlier
versions of the CAPWAP proto, which have resulted in
fixes. So, I would say to use the gained operational
experience to "do it a better way" in the IETF CAPWAP
doc instead of repeating past undesirable results.

> CTO, Wireless Networking Business Unit

Regards,
/david t. perkins

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 13 Sep 2006 15:56:44 -0400

David T. Perkins writes...
 
> since IETF specifications are essentially definitions

I think you know that the IETF standardizes on-the-wire protocols, and
sometimes APIs (or ASIs).  Product behavior goes way beyond this scope.

It is true that certain "differentiators" that vendors add to their
products impact the on-the-wire protocol.  This class of features is
generally at tension with multi-vendor interoperability.  There is
another class of features that do not impact on-the-wire protocol
specifications, and these are where vendors can truly add
differentiation without breaking interoperability.

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 13 Sep 2006 14:54:21 -0700 (PDT)

HI,

David - yes I know the IETF process quite well.

Let me provide a small example related to this issue (discovery)
in CAPWAP.....

At time t(x) in the past, an WTP established a session
with an AC and transitioned to the run state. Due to
a short term network problem, the session between the
WTP and AC is lost (terminated). The CAPWAP-02 does not
factor this history into the discovery process. This
results in an increase in latency of the WTP reconnecting
to the AC, and the possibility of the WTP connecting
to a different AC, plus the WTP and AC leaking
information. I believe that the current behavior is
inapropriate, and a much better behavior that 
is derived from considering appropriate scenarios
should be specified in the CAPWAP protocol specification.

I was hoping that the WG would be using a process that
would work through these technical issues to make sure
all understood the situations and how the protocol
addressed each situation. It feels like gamesmanship
to keep the situations from being made visible and
understood. Without this, I can't see how WG members
can judge the CAPWAP spec and support it going forward.

Regards,
/david t. perkins