Re: Use of SESSION ID
From: Bob O'Hara (boohara) (booharacisco.com)
Date: Fri, 2 Jun 2006 16:56:49 -0700 (PDT)
Scott,

Misdirection, or maybe it is truly not understanding what is in your own
networking closet, is not justification for this ad hominem attack.
Your clever switch of terminology to substitute "switch" for "AC" does
not change the way the world's networking equipment works today.

What I said below, and have said earlier, and have had supported by
several others on this list is that the devices in the network
infrastructure, the world's switches and routers, do not understand
CAPWAP (or LWAPP for that matter) and likely never will.  This battle is
over, regardless of your claim of misdirection.  Putting any kind of
custom header behind UDP and expecting the world's network
infrastructure to adapt to it, simply because you like it, is a pipe
dream.  

If we want CAPWAP to be widely adopted, we need to ensure it is going to
work in the infrastructure that it lands in.  Any expectation that the
Internet will adapt to CAPWAP will doom CAPWAP to the dust bin of "nice
idea, but stupid implementation".


 -Bob
 
-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com] 
Sent: Friday, June 02, 2006 4:21 PM
To: Bob O'Hara (boohara); capwap [at] frascone.com
Subject: Re: [Capwap] Use of SESSION ID

-----Original Message-----
>From: "Bob O'Hara (boohara)" <boohara [at] cisco.com>
>Sent: Jun 2, 2006 12:02 PM
>To: capwap [at] frascone.com
>Subject: Re: [Capwap] Use of SESSION ID
>
>Abhijit,
>
>The use of the CAPWAP header to distinguish between control and data
>suffers from all the same problems that using a custom shim for that
>purpose, i.e., there is not a router or switch in the world that
>understands either one.
>

Ummm... that's definitely not right. The *airespace* switch has no
problem understanding this, nor do other vendors *wlan* switches, if
they want to update their firmware and/or microcode accordingly. This
talk about "custom shims" is misdirection. What's custom here is what
you guys are proposing.

Backward compatibility with a particluar vendor's legacy network gear in
terms of identifying capwap internals is not a stated goal of this
working group, nor should it be. It's not in the objectives draft, the
architectural taxonomy, or the working group charter. And it's not in
the interest of the broader community - vendors *or* customers.

--Scott

Results generated by Tiger Technologies using MHonArc.