Capwap Mailing List: Re: Use of SESSION ID

[Bob O'Hara (boohara) (boohara]

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:scott [at] hyperthought.com] 
Sent: Sunday, June 04, 2006 11:32 AM
To: Bob O'Hara (boohara)
Cc: capwap [at] frascone.com
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