Subject: [Capwap] mux redux

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 15 May 2006 18:01:23 -0400 (EDT)

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