Subject: RE: [Capwap] CAPWAP evaluation draft complete

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Thu, 29 Sep 2005 13:54:25 -0400

Thanks, Darren and company, for the thorough evaluation work.
I have a few observation I'd like to pass along:

1. section 6.1. talks about setting logical groups, and SSID in
particular. I believe the message should be extended to include VLAN
(per Saravanan note in a different email chain), that's for the case
where DS is implemented at the WTP.
s
2. section 6.2. discuss the use of "C-bit" as a mean to distinguish data
vs. controller messages. Although the "C-bit" satisfies the requirement,
I think that 1 bit is too restrictive and allows no scalability (e.g.
segregate control vs. management, or future wireless technology, if
needed). It might be advisable to follow the recommendation sprit you
made in section 9.1.1 to extend the IE.

3. section 6.14. approves NAT traversal objective, however I would
challenge LWAPP in this case as it carries the IP address in the
payload. Although NAT devices can be statically configured, I would vote
against taking such approach, and a prove would be the need for an ALGs
for each protocol that carries IP address in body message.
I would think that adding a recommendation to avoid embedded IP address
in control messages would be advisable.
In addition it would improve the protocol "readiness" for IPv6.

Regards,
Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, September 21, 2005 9:34 PM
To: [email-masked]
Cc: Mani, Mahalingam (Mahalingam); [email-masked];
[email-masked]; [email-masked]
Subject: [Capwap] CAPWAP evaluation draft complete

After much hard work, the evaluation team has completed the CAPWAP
evaluation draft.  Its is available for review at:
http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and
also in the internet drafts directory.

The evaluation team concluded that LWAPP is the most complete proposal
and should be used as the basis for CAPWAP protocol moving forward.  In
addition, a number of recommendations were made which the evaluation
team believed should be addressed by the working group.

Over the next 2 weeks the evaluation team will address clarification
questions on the WG list.   The recommendation provided by the
evaluation team will not change, as this was intended to be an
independent activity supported by the WG.   This is essentially a WGLC
on the evaluation draft.  Please submit any clarification question to
the list by Friday, September 30th.

The next step will be to come to an agreement on the WG list to decide
to accept the recommended protocol.  Once we have established consensus,
we can further discuss the additional recommendations presented in the
draft.

We would like to thank the evaluation team on its thorough work and a
job well done.

Regards,
Dorothy and Mani

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 30 Sep 2005 12:58:32 -0400

Regards,
Emek

-----Original Message-----

Regards,
Dorothy and Mani

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sat, 1 Oct 2005 13:36:02 -0700

> 3. section 6.14. approves NAT traversal objective, however I 
> would challenge LWAPP in this case as it carries the IP 
> address in the payload. Although NAT devices can be 
> statically configured, I would vote against taking such 
> approach, and a prove would be the need for an ALGs for each 
> protocol that carries IP address in body message.
> I would think that adding a recommendation to avoid embedded 
> IP address in control messages would be advisable.

Actually, we NAT perfectly well today. The issues are with certain
enhanced features, such as the ability to send the data frames to a
separate IP address from the control frames. So in NAT scenarios, we
simply do not use those features.

Given that I participated in the design of PPTP, and was the person that
pushed for GRE, I am quite familiar with the protocol. One issue that
came about from the use of GRE was its inability to traverse NATs.
However, the saving grace was the fact that the PPTP protocol inserted
key values in the GRE protocol that allowed for NATs to be able to
support PPTP. However, in order for NATs to support PPTP, they needed to
implement enough of the PPTP protocol in order to extract information
that would allow it to identify information in the GRE header, which it
uses to create to correlation between the control and data frames. 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Darren Loher" <[email-masked]>
Date: Sun, 2 Oct 2005 13:09:16 -0700

LWAPP can accomodate VLAN assignment on a per STA basis through it's "Add Mobile" function [LWAPP 1.7.1.1].  While it's not a hard, BSSID - VLAN mapping, I think this is actually a bit more flexible.  I have seen scenarios where administrators would like to have multiple VLAN's on one SSID.  This allows creation of policies on a per VLAN basis, somewhere upstream of the WTP and possible AC too, that are independant of the SSID.  Often users don't know which SSID they are supposed to attach to.
 
Regarding the "c-bit", I agree, this would become a non-issue if control and data are encapsulated with different protocols.  If you have a strong case for an additional type of data (control vs. user) that might be used, that might be useful to know.
 
Regarding NAT traversal support via LWAPP, we the evaluation team does note that carrying the IP address is a potential weakness.  However, this is only in the control path for the purposes of configuring the location of the AC and Data termination points.  
 
Looking at all the proposals, it seems they all can only support NAT where the WTP is in the hidden address space without some kind of explicit compensation in the discovery process or configuration in a NAT device.  I'm not sure there's really a good way around this without a much more complicated discovery or middle-box proxy mechanism that can detect and/or work around NAT.  
 
-Darren

________________________________

From: [email-masked] on behalf of Sadot, Emek (Emek)
Sent: Thu 9/29/2005 11:54 AM
To: [email-masked]; [email-masked]
Cc: Mani, Mahalingam (Mahalingam); [email-masked]; [email-masked]
Subject: RE: [Capwap] CAPWAP evaluation draft complete

Regards,
Emek

-----Original Message-----

Regards,
Dorothy and Mani

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 5 Oct 2005 07:07:44 -0700

> 2. section 6.2. discuss the use of "C-bit" as a mean to 
> distinguish data vs. controller messages. Although the 
> "C-bit" satisfies the requirement, I think that 1 bit is too 
> restrictive and allows no scalability (e.g.
> segregate control vs. management, or future wireless 
> technology, if needed). It might be advisable to follow the 
> recommendation sprit you made in section 9.1.1 to extend the IE.
> 

I do not believe that the objectives listed here are sufficient. I
believe that in order to fully support the objective, a protocol must be
capable of not only identifying a control frame from a data frame, but
it must also allow for either to be sent to a separate IP Address (isn't
that really the reason for separation of both control/data frames?).
This would address the scaling issues discussed in this objective,
allowing a system to comprise of multiple separate network nodes.

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 5 Oct 2005 07:07:44 -0700

> Looking at all the proposals, it seems they all can only 
> support NAT where the WTP is in the hidden address space 
> without some kind of explicit compensation in the discovery 
> process or configuration in a NAT device.  I'm not sure 
> there's really a good way around this without a much more 
> complicated discovery or middle-box proxy mechanism that can 
> detect and/or work around NAT.  

Please see my other e-mail regarding NAT traversal. I would argue that
any GRE based protocol is not NAT'able today without significant changes
to a NAT system. PPTP uses GRE, and NAT boxes had to implement the
necessary ALG to handle it.

Pat Calhoun

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Darren Loher
> Sent: Sunday, October 02, 2005 1:09 PM
> To: Sadot, Emek (Emek); [email-masked]; [email-masked]
> [email-masked]
> LWAPP can accomodate VLAN assignment on a per STA basis 
> through it's "Add Mobile" function [LWAPP 1.7.1.1].  While 
> it's not a hard, BSSID - VLAN mapping, I think this is 
> actually a bit more flexible.  I have seen scenarios where 
> administrators would like to have multiple VLAN's on one 
> SSID.  This allows creation of policies on a per VLAN basis, 
> somewhere upstream of the WTP and possible AC too, that are 
> independant of the SSID.  Often users don't know which SSID 
> they are supposed to attach to.
>  
> Regarding the "c-bit", I agree, this would become a non-issue 
> if control and data are encapsulated with different 
> protocols.  If you have a strong case for an additional type 
> of data (control vs. user) that might be used, that might be 
> useful to know.
>  
> Regarding NAT traversal support via LWAPP, we the evaluation 
> team does note that carrying the IP address is a potential 
> weakness.  However, this is only in the control path for the 
> purposes of configuring the location of the AC and Data 
> termination points.  
>  
>  
> -Darren
> 
> [email-masked]
> 1. section 6.1. talks about setting logical groups, and SSID 
> in particular. I believe the message should be extended to 
> include VLAN (per Saravanan note in a different email chain), 
> that's for the case where DS is implemented at the WTP.
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> After much hard work, the evaluation team has completed the 
> CAPWAP evaluation draft.  Its is available for review at:
> http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.
> txt and also in the internet drafts directory.
> 
> The evaluation team concluded that LWAPP is the most complete 
> proposal and should be used as the basis for CAPWAP protocol 
> moving forward.  In addition, a number of recommendations 
> were made which the evaluation team believed should be 
> addressed by the working group.
> 
> on the evaluation draft.  Please submit any clarification 
> question to the list by Friday, September 30th.
> 
> The next step will be to come to an agreement on the WG list 
> to decide to accept the recommended protocol.  Once we have 
> established consensus, we can further discuss the additional 
> recommendations presented in the draft.
> 
> We would like to thank the evaluation team on its thorough 
> work and a job well done.
> 
> Regards,
> Dorothy and Mani
> 
>

---

From: Michael Montemurro <[email-masked]>
Date: Wed, 12 Oct 2005 14:05:49 -0400

Dorothy and Mani,

I just wanted to state that I accept the CAPWAP evaluation draft and its
recommendations. I think we can work with the recommendations of the
evaluation team and move towards completing the protocol specification.

However, I believe that there are a number of issues that need to be
addressed in order to arrive at a completed protocol. Some of these issues
include:
	- mandatory/optional protocol components
	- local MAC/split MAC negotiation
	- data frame format for tunneling in local MAC mode
	- application of 802.11e EDCA and admission control (I think there
are still some issues)
	- firmware update

Cheers,

	Mike 

> Sent: September 21, 2005 9:34 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];

---

From: <[email-masked]>
Date: Wed, 12 Oct 2005 12:41:53 -0700

Hi Mike-

Thanks for the vote of confidence!  Mani and I have been talking to
first gain concensus within the WG on the protocol, and then work
through the issues and apply them to the accepted protocol.   It seems
with the controversy on the list this may be the best way forward.

Thanks,
Dorothy

-----Original Message-----
From: ext Michael Montemurro [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2005 11:06 AM
To: Gellert Dorothy (Nokia-ES/MtView); [email-masked]
Cc: [email-masked]; [email-masked]; Kessens David
(Nokia-NET/MtView)

Dorothy and Mani,

However, I believe that there are a number of issues that need to be
addressed in order to arrive at a completed protocol. Some of these
issues
include:
	- mandatory/optional protocol components
	- local MAC/split MAC negotiation
	- data frame format for tunneling in local MAC mode
	- application of 802.11e EDCA and admission control (I think
there are still some issues)
	- firmware update

Cheers,

	Mike 

> Cc: [email-masked]; [email-masked]; [email-masked]; 

> and should be used as the basis for CAPWAP protocol moving forward.  
> In addition, a number of recommendations were made which the 
> evaluation team believed should be addressed by the working group.
> 

> to accept the recommended protocol.  Once we have established 
> consensus, we can further discuss the additional recommendations 
> presented in the draft.
>