Subject: RE: [Capwap] a necessary and sufficient capwap base protocol

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 27 Mar 2006 14:56:57 -0800

Well, for instance, 802.11n supports MPDU aggregation, which
fundamentally changes the format of the user frames, and their length.
Further, the question of how many receivers/transmitters for MIMO
support needs to be factored in.
 
I'm not a fan of moving forward. Doing so will produce a protocol that
will have limited market traction - or worse, one where each vendor
implements a bunch of vendor proprietary extensions in order to meet
market demand. I'd much prefer to come out the gate with a protocol that
satisfies the known market requirements.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Monday, March 27, 2006 2:47 PM
	To: Pat Calhoun (pacalhou)
	Cc: Scott G Kelly; capwap
	Subject: Re: [Capwap] a necessary and sufficient capwap base
protocol

	Looking just at the a/b/g vs a/b/g/n question:
	We know the a/b/g impacts on the CAPWAP protocol now. The
unknown is when will we know the .11n
	impacts. July06? Jan 07? Sept 07 (.11n ratification)?  If .11n
impacts are not known until Sept 07, I
	would definitiely support getting a "sub-optimal" protocol out,
as we would learn alot from the
	intial deployments and implementation, and subsequent CAPWAP
.11n protocol work could track the .11n ratification work. 
	 
	One way to get resolution on the a/b/g vs a/b/g/n support
question is to answer the following questions
	- What is the scope of changes to the CAPWAP protocol to support
.11n. Is it just a few radio type changes?
	Fundamental control protocol changes?
	- When could we have changes needed for .11n integrated into the
CAPWAP protocol? 
	- Agree on a timeframe when it would be in/out. If our goal is
completion is July-September 06, we would need
	to have the scope and most changes identified by say end June
06.
	 
	Do we need a sub-team/set of volunteers to 
	go and look at this, and report back? It sounds like we need to
do some (home)work to be able to make an informed
	data-driven decision.
	 
	Dorothy Stanley

	On 3/27/06, Pat Calhoun (pacalhou) <[email-masked]> wrote: 

		I believe that rushing to provide a sub-optimal protocol
is not in the
		best interest of the Internet community. In fact, I've
been thinking 
		about the comment made at the IETF about perhaps not
waiting for
		802.11n, and get CAPWAP out the door. My recollection of
the reasoning
		was that we needed to address market need while it still
existed.
		However, I would claim that if we don't have a solution
that supports 
		802.11n, then all vendors will still end up with
proprietary solutions
		by the time the CAPWAP standard is ready - as 802.11n
will be mandatory
		for our customers. So if interoperability is the key
goal for CAPWAP, 
		then I propose we do it right.
		
		More on Scott's proposals...
		
		> - NAT traversal (IPsec working group did this as an
add-on,
		> and since not all vendors care about this, it makes
sense to
		> consider that approach here) 
		
		Plenty of protocols are NAT-able, and my belief is that
we are chasing a
		problem that doesn't need to be. The protocol, as it
stands, already is
		NAT'ed in various customer deployments.
		
		>
		> - AC/WTP load balancing; different vendors have
different 
		> approaches, and it's not clear that we should be
forcing one
		> vendor's view on everyone else.
		
		Going back to my comment above, it's all about
interoperability. If we
		can to design a protocol that scales, then this feature
is required. 
		
		> - split tunneling, where data channel terminates on a
		> different endpoint than the control channel; this has
		> definite security implications, and probably requires
a
		> secure inter-AC protocol, in addition to its own state

		> machine loop(s). It's a corner case that many won't
care about.
		
		Same as previous comment. This is mandatory for large
scale deployments
		and the protocol supports it already.
		
		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

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Dorothy Stanley" <[email-masked]>
Date: Mon, 27 Mar 2006 15:39:24 -0800

Comments inline...

On 3/27/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> Further, the question of how many receivers/transmitters for MIMO support
> needs to be factored in.
>

Agreed, these 2 and likely more - It's this detail that we need to get a
handle on, and determine when the
support can be integrated into the CAPWAP protocol. Depending on when we can
complete the
integration, we decide that it's in or out.

> implements a bunch of vendor proprietary extensions in order to meet market
> demand. I'd much prefer to come out the gate with a protocol that satisfies
> the known market requirements.
>
>

The knowm market requirements are a moving, growing target. If we wait to
include them all, we'll
never release a version of the CAPWAP protocol. So we as a WG have to make
some hard decisions and tradeoffs, to meet
enough of the market requirements to provide value, and then have a roadmap
for meeting additional requirements.

 Pat Calhoun
>   ------------------------------
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* Monday, March 27, 2006 2:47 PM
> *To:* Pat Calhoun (pacalhou)
> *Cc:* Scott G Kelly; capwap
> *Subject:* Re: [Capwap] a necessary and sufficient capwap base protocol
>
>
>
>
> We know the a/b/g impacts on the CAPWAP protocol now. The unknown is when
> will we know the .11n
> impacts. July06? Jan 07? Sept 07 (.11n ratification)?  If .11n impacts are
> not known until Sept 07, I
> would definitiely support getting a "sub-optimal" protocol out, as we
> would learn alot from the
> intial deployments and implementation, and subsequent CAPWAP  .11n
> protocol work could track the .11n ratification work.
>
> One way to get resolution on the a/b/g vs a/b/g/n support question is to
> answer the following questions
> - What is the scope of changes to the CAPWAP protocol to support  .11n. Is
> it just a few radio type changes?
> - When could we have changes needed for .11n integrated into the CAPWAP
> protocol?
> - Agree on a timeframe when it would be in/out. If our goal is completion
> is July-September 06, we would need
> to have the scope and most changes identified by say end June 06.
>
> Do we need a sub-team/set of volunteers to go and look at this, and report
> back? It sounds like we need to do some (home)work to be able to make an
> informed
> data-driven decision.
>
> Dorothy Stanley
>
>
>
> > I believe that rushing to provide a sub-optimal protocol is not in the
> > best interest of the Internet community. In fact, I've been thinking
> > about the comment made at the IETF about perhaps not waiting for
> > 802.11n, and get CAPWAP out the door. My recollection of the reasoning
> > was that we needed to address market need while it still existed.
> > However, I would claim that if we don't have a solution that supports
> > 802.11n, then all vendors will still end up with proprietary solutions
> > by the time the CAPWAP standard is ready - as 802.11n will be mandatory
> > for our customers. So if interoperability is the key goal for CAPWAP,
> > > - NAT traversal (IPsec working group did this as an add-on,
> > > and since not all vendors care about this, it makes sense to
> > Plenty of protocols are NAT-able, and my belief is that we are chasing a
> > problem that doesn't need to be. The protocol, as it stands, already is
> > > - AC/WTP load balancing; different vendors have different
> > > approaches, and it's not clear that we should be forcing one
> > Going back to my comment above, it's all about interoperability. If we
> > can to design a protocol that scales, then this feature is required.
> >
> > > definite security implications, and probably requires a
> > > machine loop(s). It's a corner case that many won't care about.
> >
> > Same as previous comment. This is mandatory for large scale deployments