Subject: Re: [Capwap] mux redux

From: "Tal Anker" <[email-masked]>
Date: Tue, 16 May 2006 18:35:02 +0300

Hi Scott,
There are examples for both approaches - muxing using special mux header
or using UDP/TCP ports... For instance the BFD protocol suit
(Bidirectional failure detection) uses different udp ports for its
various protocols (Control, Echo), FTP uses different data and control
ports (TCP) etc. There is no clear cut here for the Mux approach... not
to mention the simplification for the HW engine that will reside in the
AC and will have to dispatch packets either to be processed at the
control plane (CPU) or to be switched/routed (data plane). The
simplification comes from the fact that most HW switching elements
already have engines that classify packets based on the famous five/six
tupple ... 

- Tal

-----Original Message-----
From: Scott G Kelly [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2006 3:43 PM
To: David Melman
Cc: capwap
Subject: Re: [Capwap] mux redux
Importance: Low

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