Subject: Re: [Capwap] mux redux

From: "Nafea Bshara" <[email-masked]>
Date: Tue, 16 May 2006 08:17:18 -0700

hi Scott
 
there will be multiple entities in the network between the WTP and the AC that may need to inspect, prioritize or re-direct control and data separately, whether for security, differential treatment or redirection
 
as very simple, yet realistic example, is the hardware makeup of the AC itself - typically made of control plane and data plane engine and a unit infront, which is typically a multi-port MAC or Switch that is responsible on splitting the traffic
 
most, if not all, of these network elements deployed knows how to do QoS/ACL based on UDP ports, not sure whether they can handle undefined headers yet
 
let me ask you the opposite question - why not to have different UDP ports ?
 
-Nafea

________________________________

From: Scott G Kelly [mailto:[email-masked]]
Sent: Tue 5/16/2006 5:42 AM
To: David Melman
Cc: capwap
Subject: Re: [Capwap] mux redux

Hi David,

David Melman wrote:
> I support keeping the separation of data and control based on the
> standard UDP header port, rather than adding a CAPWAP specific mux
> header after the UDP header.
>
> As already been stated, classification engines today typically support
> the standard UDP header fields.  By keeping the separation of data and
> control in the standard UDP header, it allows standard based
> classification, and independent policy to be applied to each type of
> traffic.  QoS is just one type of policy, but of course, many other
> policies can be applied independently to data and control traffic.
> There is definitely value in *not* making the mux CAPWAP specific.

We've seen that QoS policy is properly applied using standard QoS
markings, and not UDP headers. Can you give any explicit use cases and
justification for other forms of differential treatment of the
tightly-bound capwap control and data channels?

Thanks,

Scott

>
> David
>
> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]]
> Sent: Tuesday, May 16, 2006 1:01 AM
> To: capwap
> Subject: [Capwap] mux redux
> Importance: Low
>
> We've been going around in circles on this mux header discussion, and we
> need to close on it. Many of us are working on implementations right
> now, and we need this decided in order to to get on with it.
>
> This is becoming tiresome, but we must reach a conclusion.
>
> The only ones to object to using a single UDP channel here have been
> Pat, Bob, and Nancy. The technical benefits of mux'ing over one UDP
> channel have been clearly established, and are not in dispute. The only
> arguments still standing against this approach have all been based on
> the following assertions:
>
> (1) middleboxes must be able to alter capwap QoS markings in transit
>
> (2) these middleboxes must alter capwap data packet markings differently
> than capwap control packet markings
>
> (3) these middleboxes cannot see beyond the UDP header, and must make
> their decisions based on UDP header ACLs
>
> It seems clear that this whole QoS discussion is a red herring, because
> the assertions above, taken together, are simply not accurate. While it
> has been convincingly argued that control and data traffic should be
> treated differently, we have yet to hear why the current QoS standards
> are not up to this task. When this question is asked, it is met with
> silence.
>
> We have widely implemented standards in place for providing QoS
> functionality, and these standards do not include the use of UDP header
> ACLs. Rather, they include L2 and L3 packet markings. Nobody has made a
> convincing argument as to why these standards fall short of our needs.
> Absent persuasive arguments, contrary claims are simply not compelling.
>
> So far, a number of us have posted to the list in support of the mux
> header, and a few people who coincidentally all work together have
> argued forcefully, though unconvincingly, against this approach. Of
> course, ideally we are all here as independent, individual contributors,
> but it nevertheless does not serve us well to ignore the realities.
>
> I think, based on the discussion we've seen here, that we have rough
> consensus, with representatives of one product approach (and vendor) not
> agreeing, and representatives of various other product approaches (and
> vendors) roughly agreeing. It's not unanimous, but I think we have more
> yeas than nays - and I think that constitutes "rough" consensus. I think
> we should note the objections, accept the mux header, and move on.
>
>
> --Scott
>
> _________________________________________________________________
> 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
>
_________________________________________________________________
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