Subject: [Capwap] The MUX header Flux

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Sat, 24 Jun 2006 18:58:21 -0600

All

http://home.comcast.net/~mmani/muxflux.pdf presents a summary of
discussions that  have been in progress so far on the proposal to use a
mux-header for multiplexing control and data flows. Apologies for late
summary. The attached also includes a proposed set of questions for
consulting other SME (subject-matter-experts) as suggested by ADs.

Some of them could be framed better; some more could be framed.

In the final analysis, we are positioned best to determine the best way
to go based on inputs that may need clarifying not only from SMEs but
also the current practices in the industry (enterprises, provider
environments of various hues). We may not be able to get them all; if we
do get a large subset that is goodness.

Else, it is inevitable that additional field deployment experiences of
the CAPWAP standard alone can help us refine it (a -bis, perhaps).

Preamble:

More than a year ago, around when the WG was being rechartered to work
on the protocol; it was suggested to treat the data-path independent of
control path and leave it out of the CAPWAP protocol definition itself.
However, architectural taxonomy indicated trends that found usefulness
of split-MAC with tunneled forwarding of data to a centralized AC
already having found some acceptance in many deployments also merited
inclusion. Hence we are ending up classifying three modes - two in
split-MAC and one in local-MAC. The Split-MAC treatment of data-traffic
has led to questions about its protection, encapsulation and
multiplexing with control stream.

Since then there has been a lot that happened including succeeding in
getting a -00 version of the WG CAPWAP draft protocol out for review and
a -01 following it.

A member of the WG, Scott Kelly, has proposed use of mux header citing
several reasons.

It also appears that - given the nature and intensity of discussions; as
well as the stated/claimed deployment practices in enterprise and
provider environments to enforce local policies - it becomes imperative
to validate them over a broader network equipment vendor and customer
space.

It also becomes apparent that a best-practices (applicability) document
may be useful to guide operators (enterprise and provider) with best
choices for given topologies.

While the presented approach of tables may not be the best way to
summarize - this is captured in chronological order showing the
progression of topics; it is interesting what has caused what looks to
be a simple issue to resolve technically to take this magnitude of
debate.

We would like not to linger long on debating the questions; simply send
in your additions/changes and we (chairs) will recompile them once
(hopefully to general agreement) and send it on to the ADs.

Regards,

-mani

PS:

The technical merits of the reasons have been debated. Also in question
is the concern about compatibility with existing implementations and
behaviors on intermediate switches and routers processing along the way
leading to performance inefficiencies. The discussions are not citing
any correctness issues, however, mux-header or not. We will try to
summarize them all and see why we gauge consensus in favor of
mux-header. For those more used to other SDOs: That does not mean the
perceived consensus cannot be opposed (as it happens ever so many times
in other SDOs based on respective process mechanisms and influences of
varied hues) or argued against/for - on technical merits and pitfalls.

It is customary, both thinly contended to closely contended issues
(technical and otherwise) there is a need to call for consensus by
stating a conclusion and calling the question. This may happen at many
layers - not always requiring the chairs to intervene - as happens with
many cases in the issue-tracker. However, in the event of strong dissent
the chairs are required to/called upon to assess, gauge, state and
validate "rough" consensus. This is what is happening.

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 26 Jun 2006 09:21:55 -0700

Many, I would like to include the thread I started today, called
"Keepalive of data channel", and also ask that the Internet Area
Directors also be engaged in the activity.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
	Sent: Saturday, June 24, 2006 5:58 PM
	To: [email-masked]
	Subject: [Capwap] The MUX header Flux
	Importance: High

	All

	In the final analysis, we are positioned best to determine the
best way to go based on inputs that may need clarifying not only from
SMEs but also the current practices in the industry (enterprises,
provider environments of various hues). We may not be able to get them
all; if we do get a large subset that is goodness.

	Else, it is inevitable that additional field deployment
experiences of the CAPWAP standard alone can help us refine it (a -bis,
perhaps).

	Preamble:

	More than a year ago, around when the WG was being rechartered
to work on the protocol; it was suggested to treat the data-path
independent of control path and leave it out of the CAPWAP protocol
definition itself. However, architectural taxonomy indicated trends that
found usefulness of split-MAC with tunneled forwarding of data to a
centralized AC already having found some acceptance in many deployments
also merited inclusion. Hence we are ending up classifying three modes -
two in split-MAC and one in local-MAC. The Split-MAC treatment of
data-traffic has led to questions about its protection, encapsulation
and multiplexing with control stream.

	Since then there has been a lot that happened including
succeeding in getting a -00 version of the WG CAPWAP draft protocol out
for review and a -01 following it.

	A member of the WG, Scott Kelly, has proposed use of mux header
citing several reasons.

	It also appears that - given the nature and intensity of
discussions; as well as the stated/claimed deployment practices in
enterprise and provider environments to enforce local policies - it
becomes imperative to validate them over a broader network equipment
vendor and customer space.

	It also becomes apparent that a best-practices (applicability)
document may be useful to guide operators (enterprise and provider) with
best choices for given topologies.

	While the presented approach of tables may not be the best way
to summarize - this is captured in chronological order showing the
progression of topics; it is interesting what has caused what looks to
be a simple issue to resolve technically to take this magnitude of
debate.

	We would like not to linger long on debating the questions;
simply send in your additions/changes and we (chairs) will recompile
them once (hopefully to general agreement) and send it on to the ADs.

	Regards,

	-mani

	PS:

	The technical merits of the reasons have been debated. Also in
question is the concern about compatibility with existing
implementations and behaviors on intermediate switches and routers
processing along the way leading to performance inefficiencies. The
discussions are not citing any correctness issues, however, mux-header
or not. We will try to summarize them all and see why we gauge consensus
in favor of mux-header. For those more used to other SDOs: That does not
mean the perceived consensus cannot be opposed (as it happens ever so
many times in other SDOs based on respective process mechanisms and
influences of varied hues) or argued against/for - on technical merits
and pitfalls.

	It is customary, both thinly contended to closely contended
issues (technical and otherwise) there is a need to call for consensus
by stating a conclusion and calling the question. This may happen at
many layers - not always requiring the chairs to intervene - as happens
with many cases in the issue-tracker. However, in the event of strong
dissent the chairs are required to/called upon to assess, gauge, state
and validate "rough" consensus. This is what is happening.

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Mon, 26 Jun 2006 18:12:25 -0600

I have changed the file from muxflux.pdf to muxflux.htm

Hence http://home.comcast.net/~mmani/muxflux.htm is the one to refer to.

-mani

  _____  

From: Mani, Mahalingam (Mani) 
Sent: Saturday, June 24, 2006 5:58 PM
To: [email-masked]
Subject: [Capwap] The MUX header Flux
Importance: High

All

Preamble:

Regards,

-mani

PS:

---

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Mon, 26 Jun 2006 18:13:09 -0600

Some,Done.

-mani

  _____  

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 9:22 AM
To: Mani, Mahalingam (Mani); [email-masked]
Subject: RE: [Capwap] The MUX header Flux

Pat Calhoun

  _____  

	All

	Preamble:

	Regards,

	-mani

	PS: