Subject: Re: [Capwap] Use of SESSION ID

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Mon, 5 Jun 2006 08:41:31 -0700

Scott, 

I believe you were the first to use the word "shim", not me.  If it is
pejorative, it is your word, not mine.

As to the need to be backward compatible with "a particular vendor's
legacy network gear", this is also your argument, not mine.  I am not
arguing for separate ports due to the fact that my LWAPP equipment uses
them.  I am arguing for the use of separate ports for exactly the reason
that I chose to use separate ports on my LWAPP equipment.  The reason is
that using separate ports requires NO CHANGE TO EXISTING NETWORK
INFRASTRUCTURE EQUIPMENT, while providing the capability to easily
classify data and control traffic separately on that existing equipment.

At the time I chose two ports for LWAPP, I was a competitor to every
other networking equipment vendor in the world.  As a matter of fact, so
were you.  I had no interest in making my competitors comfortable.  My
intention was exactly the opposite.

But, since you won't accept this argument from me, let me copy the
eloquent words of another poster to this list, who's message has been
conveniently forgotten:

On May 16, 2006, Chris Stradtman wrote:
from an service provider point of view I can think of 2 off the top of
my head.

1. A service provider may not choose to trustingly pass through the QOS
markings and may wish to rewrite the QOS markings
based on other policies internal to the service provider.
2. The service provider may wish to send the data and control channels
down different physical paths based on economic factors.

If the streams are muxed then the service provider need to have
equipment in the middle that understands the capwap protocol out of the
gate (although some gear can use explicity bitstrings and offsets into
the packet).  This is unlikely to happen and in my opinion would slow
down the adoption and implementation of the protocol in the "real
world".

</end quote>
 
What Chris has described above is a very common practice, not only in
service providers, but also in enterprise networks.  His "equipment in
the middle" is today's router or switch, neither of which understand the
CAPWAP header.  Granted, some of that equipment has the logo of my
employer on it.  But, much of it does not.  

Yes, that "equipment in the middle" may understand other protocols than
TCP and UDP, exactly because they are widely deployed.  But, requiring
that the "equipment in the middle" be upgraded by the customer to get
the same functionality they get on every other protocol will only serve
to delay the adoption of CAPWAP.  It may also guarantee that CAPWAP
never becomes widely deployed.

If you can't understand the reason to use separate ports or won't accept
my arguments, at least listen to the customers that might (or might not)
buy equipment that uses CAPWAP.

 -Bob
 
-----Original Message-----
From: Scott G Kelly [mailto:[email-masked]] 
Sent: Sunday, June 04, 2006 11:32 AM
To: Bob O'Hara (boohara)
Cc: [email-masked]
Subject: Re: [Capwap] Use of SESSION ID

Bob O'Hara (boohara) wrote:
> Abhijit,
> 
> I apologize if my original reply seemed to dismiss all of your
> proposals.  I was addressing only the first proposal that was to
replace
> the "shim" header with a CAPWAP header and still run over a single UDP
> port.

I think we need to correct a potential misperception, that being that 
what is being proposed is kludgy, a "shim", and therefore worthy of 
denigration.  This has no technical justification - and it's what I've 
been referring to as misdirection, because it tends to evoke a 
pejorative interpretation which is neither technically justified nor 
appropriate.

CAPWAP is a single protocol which currently supports three classes of 
protocol data unit (PDU): discovery, control, and data. The proposed 
de-multiplexing mechanism is simply a PDU type field. We have ample 
precedence for the use of such PDU type fields in other widely deployed 
protocols such as tls, snmp, l2tp, pptp, and yes, even lwapp (where the 
'c' bit serves this function). Layered protocols are quite common in the

Internet today.

Existing routers and switches have no difficulty in handling these 
widely deployed protocols, perhaps because they have no mandate other 
than to route and or switch the traffic. In particular, there has never 
been a general IETF protocol design requirement for routers and switches

to be able to perform economy packet classication via tcp/udp ports - if

there were, all protocols would be tcp/udp-based, and all of the various

protocols' PDU's would be similarly decomposed by port. But they aren't.

Reiterating my earlier observation, backward compatibility with a 
particular 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. It is not a requirement. And it's not in the 
common interest of the broader community - vendors *or* customers.

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

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

---

From: Scott G Kelly <[email-masked]>
Date: Tue, 06 Jun 2006 06:58:03 -0700

> pejorative, it is your word, not mine.

Okay - so it seems we agree that there is no reason to view protocol 
layering in a negative light.

> classify data and control traffic separately on that existing equipment.

I am not referring to airespace gear - I'm referring to legacy routers 
and non-wlan switches. And as a point of fact, a single capwap protocol 
also requires "NO CHANGE TO EXISTING NETWORK INFRASTRUCTURE EQUIPMENT". 
There is no requirement in our objectives, architectural taxonomy, or 
charter that we expose capwap protocol internals to existing routers and 
switches. If we want to manipulate the ways in which they make 
forwarding decisions, we can accomplish this with vlan and QoS tagging.

As for the balance of this post, I didn't respond to Chris' email 
because there's nothing material to our discussion there. Can you name 
some compelling QoS applications that entail encapsulating ostensibly 
important and latency sensitive traffic in CAPWAP, forwarding it over a 
WAN link to a controller, and risking re-marking by the ISP on the way? 
Speculating on generalized woulda/coulda/mighta applications cannot 
provide our motivation for making such a dramatic design decision, and 
it's a waste of our energy to be addressing such speculation.

We've seen what a mess we'll get into if we split these streams into per 
PDU-type datagram channels. It's happened before (h.323, ipsec, early 
attempts at pptp, etc). It creates firewall configuration and 
operational problems, we have to devise a reliable channel binding 
scheme, NATs have to implement ALGs, the state machines on both sides 
become significantly more complex, and we have to run coordinated, 
dual-channel keep-alive schemes. The decision brings very real 
implementation, deployment, and operational pain. I provided a very 
detailed analysis of the technical trade-offs, and the conclusions of 
that analysis have not been disputed (but they do seem to have been 
forgotten).

Partha also made a number of important points, not the least of which is 
that if we try to design a swiss-army-knife-style protocol that solves 
every corner case someone can dream up, we will never produce anything 
useful. Rather, we should be designing a minimal necessary and 
sufficient protocol which meets the needs of the broad community as the 
base. Then, as we gain deployment experience, everyone is free to 
propose worthwhile extensions.

Scott