Subject: [Capwap] Comments on today's meeting

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 1 Aug 2005 23:25:52 -0700

All,
 
I wanted to provide some of my observations on some comments stated
during today's face to face meeting, and specifically how these relate
to the LWAPP protocol.
 
1. There is no way that CAPWAP can create a protocol that can satisfy
upcoming standards work, and therefore CAPWAP shouldn't bother to create
a control protocol.

	This statement is actually completely untrue. If one looks at
the work currently going on in 802.11k, 802,11r, 802.11v and 802.11w,
none of these will actually require any changes to the LWAPP protocol.
In fact, all of these extensions to the base protocol simply make use of
MAC management messages, and with the LWAPP protocol all that is needed
is to simply forward these frames to/from the AC and WTP.
	 
	The authors do agree that the introduction of 802.11e and
802.11i required changes to the WTP/AC interface, but both of these are
already handled in the LWAPP protocol.
	 
	While we cannot state that this will be true of all 802.11
extensions moving forward, one or more of the LWAPP authors are involved
in nearly all of the ongoing 802.11 activities and we are not aware of
any extension that would require any changes to the CAPWAP protocol.

2. It would be much better to simply design a protocol that allows an AC
vendor to download code for WTPs and not standardize the control
protocol.

	We've been down this path before, and frankly I was surprised
that the SLAPP authors opted to focus on this aspect of their protocol,
but I can re-state my issues with this proposal. 

	The whole goal of standards is to get guaranteed
interoperability. I believe that coming up with a proposal that allows a
vendor to claim compatibility with a "CAPWAP RFC", which does not
interoperate with the customer's existing deployment will create
confusion in the market. While I understand the motivations of the SLAPP
team, I believe that this strategy is a slippery slope that could give
the IETF (and the general WLAN market) a huge black eye. We *must*
create a protocol that guarantees interoperability.
	 
	If the AC vendor ports their code to WTPs without the WTP
vendor's knowledge (or consent), as proposed today, then who would the
end customer call if there were issues with their gear? The AC or the
WTP vendor? What happens to the warranty? Is it invalidated if one loads
foreign code to the hardware? The response from the SLAPP team was that
the end customer could re-load the standard code prior to calling
support, but this seems like a burden that most customers would not even
want to deal with. I realize we want to focus on technical, and not
business issues, on this list, but the protocol created by the CAPWAP WG
must be one that customers would be willing to deploy.
	 
	There is more than a single 802.11 MAC in the market. The
comments made during the SLAPP preso is that APs have become a commodity
and that code can easily be ported to. The reality is that there are
many 802.11 MACs in the market today, and none of them have an identical
interface.  The consequence of this proposal would require the AC vendor
to port their code to multiple platforms. I can't speak for the rest of
the protocol authors, but I for one know that my company would much
prefer to reserve its engineering resources to deal with innovation vs.
porting to different WTP hardware.
	 
	Not all reference designs are identical. While there are some
ODMs that simply take a reference design, there are some that add value
and as a consequence the hardware layout (and components or even
antennas) are different. Therefore it is not fair to state that porting
code for one 802.11 MAC manufacturer is a one time process.

	WTP manufacturers frequently make design changes to their
hardware, in some cases just for cost savings reasons and in other cases
due to parts being obsoleted. These changes generally require software
modifications (e.g., new flash), and these types of dynamic environments
create an interesting challenge for the AC vendors. This places the
burden on the AC vendors to have to track the wide variety of WTPs, and
in many cases these issues would be raised by customers attempting to
load new firmware, which could lead the WTP to become a brick in the
ceiling (unless the AC vendor has a very close relationship with all WTP
vendor's manufacturing group). This is a challenge within an
organization, let alone across companies.

3. All protocols are the nearly the same, so making changes to a
protocol is simple. 

	I respectfully disagree with this statement. I believe that one
of the value of the LWAPP specification is that it has been implemented
in two separate products (Airespace and Cisco), and that the lessons
learned from those implementations were added to the specification. It
isn't fair to state that one can "simply add information" to a spec that
easily - one needs to ensure that adding this information is consistent
with the flow of the document, is sufficiently specified, and more
importantly, works. 
	 
	I think that one of the advantages of the LWAPP specification is
the fact that it has undergone a significant amount of peer review over
the past 18+ months, which is evidenced in the maturity of the current
specification. Products implementing the specification have been
shipping for over 2 years, and have gained WiFi certification. Such
trivialities as system behavior are the types of things that are
generally only added once implementations exist, but are important in
ensuring that the working group start with a solid reference document.
	 
	One of my biggest concerns with the SLAPP document is the fact
that the control protocol was "invented" between -00 and -01 in a very
short amount of time, has had no implementations proving that it is
complete and works. In the end it's not only about "rough consensus",
but also about "running code". 

4. Compliance to the "Logical Groups" objective

	While I recognize that this point was raised at the last minute,
and therefore was not included in the evaluation team's review. This
recent comments raised by Richard Gee make it clear that not all
implementations comply with this objective. Specifically, most
implementations do not specify how to map locally bridged traffic on a
Local MAC approach to a specific VLAN. WiCop includes the basic
capabilities, but does not allow for "Identity Based Networking", which
is typical in most products today (meaning a user is mapped to a
specific VLAN based on its authorization information, not as a default
BSSID policy). LWAPP includes this information and is therefore in
complete compliance with the objectives.

5. Separation of Control and Data Path.

	While I recognize that the objective may be vague in this
specific area, the original intent (I thought) was to allow the control
and data path to be individually recognized, as well as to allow for
both to be sent to separate systems - allowing for a higher level of
scalability. The LWAPP protocol defines the mechanisms that allow the
control traffic to be sent to one system (CAPWAP Control System), while
the data plane would be sent to a forwarding engine (CAPWAP Data
Forwarding Engine). Imagine a chassis based system with a control and
one or more data blades.

So in the end I want to point out once more that the LWAPP
specification, while lengthy, is in fact complete. We believe that
adopting the LWAPP spec as the starting point would allow the working
group to start from a complete (and proven) working base - hopefully
minimizing the process of creating a standard.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

---

From: Dan Harkins <[email-masked]>
Date: Wed, 03 Aug 2005 02:44:50 -0700

Pat,

On Mon, 01 Aug 2005 23:25:52 PDT you wrote
> upcoming standards work, and therefore CAPWAP shouldn't bother to create

Wow, I don't know what meeting you attended. I don't recall anyone
saying that "CAPWAP shouldn't bother to create a control protocol." In
fact, all the candidate proposals include a control protocol.

> is to simply forward these frames to/from the AC and WTP.

I'm sorry Pat but that just isn't true. How can an AC instruct a WTP
to request a noise histogram report from a STA without any changes
to LWAPP? Even if there was a generic "MAC management message" in which
you could stuff such a thing how would the WTP parse it? How would it
send a response back to the AC? How could a WTP produce a reasonable
neighbor report for a requesting STA without sending it up to the AC
and getting a response. There just is no way to do that in LWAPP!

11r is going to stuff more cruft in the beacons. There is an explicit
LWAPP message to add the 11i cruft to the beacons. If LWAPP had some
meaningful generic way to send a "MAC management message" to add 11r
cruft to the beacon then why don't you use it to add the 11i cruft
to the beacon? Simple, because you can't do that in LWAPP.

And while I'm there, why are you adding 49 bytes of emptyness to
that IEEE 802.11 Add WLAN message? That seems really pointless and
wasteful.

> already handled in the LWAPP protocol.

See my comment above.

> vendor to download code for WTPs and not standardize the control

Again, I don't recall that ever being said in the meeting and since I was
the only one to bring up a protocol for image download I have to think
you're misquoting me.

What I said was that it is extremely important to have an image download
capability in the resulting CAPWAP protocol. It allows for innovation
in the dynamic WLAN market. Without such a capability we will be locked
into a protocol with limited capability to configure new and/or innovative
features.

> but I can re-state my issues with this proposal.

Frankly I'm surprised that you feel that if you merely respond to it on the
list that it somehow puts the issue behind the entire WG.

I brought up the subject because SLAPP is the only protocol with this very
important feature. It differentiates SLAPP from the others and I wanted
to highlight that.

> create a protocol that guarantees interoperability.

"A slippery slope" that gives "a huge black eye"? Ahhhhh! Metaphor alert!

No one is arguing against interoperability. I'm all in favor of it. I'm
also in favor of world peace and ending hunger. Yes, the whole goal of
standards is to get interoperability (although a "guarantee" is a bit
much, we can strive for it).

> must be one that customers would be willing to deploy.

If the failure was hardware I imagine it would be RMA'd to the manufacturer. 
If the failure was software I imagine the owner of the downloaded image
would be contacted.

Customers _ARE_ willing to deploy this. Many customers spent lots of money
buying standalone, fat APs. They are now realizing that managing them
doesn't scale and want a thin AP with a switch but they don't really
want to just turn all their existing fat APs into paperweights. This
allows them to get some more return on their investment. As the fat APs
that were turned into thin APs fail (as they eventually do) they are
replaced by thin APs from the switch vendor. This is a reality today Pat.

> porting to different WTP hardware.

No, the comments made during the SLAPP preso is that the justification
for needing CAPWAP was that APs _WOULD BECOME_ commodity-priced things. 
If that is not the case then we should just disband the WG and not waste
anyone's time.

Someone who used to just sign his email "PatC" wrote a couple of years
ago, "how about we go down the path of making the AP relatively simple
(aka light weight), and push all functionality that is not real-time specific
(meaning not 802.11 control) in the AR. This way, value add is provided in
the AR, not the AP. So you can use anyone's AP and get similar functionality
(granted some APs will work better than others)."

Some WTPs will work better than others with a particular AC? So my WTPs
will work better with my AC and your WTPs will work better with your AC,
etc. Not too surprising.

So what would motivate a customer to not go with a single vendor
solution? Cost! If WTPs do not become commodity-priced then there will
be little motivation in buying a mixed vendor solution using this
"standard". And then what's the point of a "standard"?

> code for one 802.11 MAC manufacturer is a one time process.

No one ever said it was a one-time process. But it has been done.

> organization, let alone across companies.

Hence the need for hardware versioning information in the SLAPP discovery
request.

> 3. All protocols are the nearly the same, so making changes to a

That is something of a non sequitur and, again, I don't recall ever
hearing that in the meeting.

I said that the 4 competing protocols all allow for control and
provisioning of WTPs by an AC. And while some may have features that
others don't, those features could be added to the protocols which
do not have them and make all the protocols essentially identical.

> with the flow of the document, is sufficiently specified, and more

"Two separate products"? That's hilarious Pat. It reminds me of that
scene from the Blues Brothers where the proprieter of a bar tells Elwood
that "we play both kinds of music, country and western." For years
Cisco had bad-mouthed LWAPP so I find it incredibly hard to believe that
anyone there would've implemented it prior to Cisco's acquisition of
Airespace. So after you went to Cisco they now support LWAPP. I used
to work at Cisco, I know how that stuff happens.

You seem to think that other WLAN switch vendors do not have proprietary
protocols to control and provision their switch. They do, just like you.

> but also about "running code".

Again, you're not the only one with a proprietary protocol running between
a switch and an AP. 

> complete compliance with the objectives.

In SLAPP a tag is included in the Unicast and Broadcast/Multicast
key configuration requests. That is how SLAPP allows for "Identity-based
Networking".

> Forwarding Engine). Imagine a chassis based system with a control and

As does SLAPP. In fact, I think SLAPP has a much better separation of
the two than LWAPP since in SLAPP control is UDP and data is encapsulated
in GRE. With LWAPP the difference is a single bit, on for one path, off
for the other.

SLAPP satisfies all the requirements in the CAPWAP objectives draft.
Some not completely according to the evaluation team (but then no single
protocol completely satisfies them all according to them) and I look forward
to finding out whether some of those are, as was mentioned, possibly
C- or P+. SLAPP also includes the important feature of image download
which will allow CAPWAP to keep up with innovations in the dynamic WLAN
environment. It's a complete protocol and I really would like to see it
adopted as a base protocol for CAPWAP.

  Dan.

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap