From diameter-admin@frascone.com Thu Jul 1 05:27:26 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08024 for ; Thu, 1 Jul 2004 05:27:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CDFE22147B for ; Thu, 1 Jul 2004 05:11:58 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E98F7214D5 for ; Thu, 1 Jul 2004 05:09:32 -0400 (EDT) Date: Thu, 01 Jul 2004 05:09:32 -0400 Message-ID: <20040701090932.4435.69786.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: capwap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, capwap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com xakour http://mail.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From capwap-admin@frascone.com Fri Jul 9 10:51:16 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03672 for ; Fri, 9 Jul 2004 10:51:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B66C1212A9; Fri, 9 Jul 2004 10:25:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2CF5B21354; Fri, 9 Jul 2004 10:25:08 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5132821082 for ; Thu, 8 Jul 2004 13:51:18 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 33CA720DC2 for ; Thu, 8 Jul 2004 13:51:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46516.78D1551E" Message-ID: <55749BC69138654EBBC4C50BA4F55610020C3FDB@AIREMAIL.airespace.com> Thread-Topic: Comments on draft-ietf-capwap-arch-03.txt Thread-Index: AcRlFnioUmajvm3FSbiqICHTxvFYCA== From: "Pat R. Calhoun" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 8 Jul 2004 11:07:46 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C46516.78D1551E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First, I'd like to applaud the authors on a job well done. It is clear = in reading this spec that there was a significant amount of data to work = with... I am very impressed with the document.=20 1. Section 1.3. "Typically ," -> "Typically, " 2. This section defines the AP as terminating the 802.11 PHY, but it = should be noted that this device also terminates the=20 802.11 MAC mgmt layer, which is not specified. 3. The definition of Split MAC implies that all MAC mgmt is handled in = the AC, but in certain implementations this is not true. The MAC mgmt = packets that have very tight timing requirements can be handled in the = WTP. 4. Page 14. The text reads 14 contributions, yet above 16 is mentioned. 5. Section 3.2. Another security issue is the very fact that this device = is most likely not under lock and key, but does contain secret = information in order to communicate with the backend systems, such as = AAA, SNMP, etc. Due to the common management method used by IT personel = of pushing a "template" to all similar devices, theft of such a device = would compromise the wired network. 5. A Network Management Station (NMS) should not be considered as part = of the Access Controller. While most controllers will provide one or = more management interfaces, a system that is used to scale a global = network generally resides on a separate system. 6. Page 25. The list of real-time features should probably include Power = Save handling. 7. Section 4.5. Could the authors please explain how they came to the = conclusion that Remote MAC "improves WTP manageability"? 8. Page 30. The term "Integration Service" is used as a substitute to = bringing function. However, the terminology section called this function = "portal". We should stick to a single term throughout the document. 9. Page 33, second to last paragraph, there is a non traditional = character in the line that starts with "every mesh node..." 10. Section 5.1. If stations (or non-trusted equipment) are allowed to = become part of the mesh backbone, end to end security is required = otherwise users traffic will be compromised. 11. Page 45. The URL for the LWAPP draft has changed and the one listed = has expired. Does it make sense to update it? 12. General comment. I understand that there was a desire to mask the = vendor in the appendices, but I wonder whether this makes sense. The = primary issue moving forward is that this is (and will) be known to = people on the list (or reading he archives) 13. Appendix C. We really should discourage baseless marketing claims = like "secure, scalable, large scale WLAN deployments" unless one intends = to back this up with facts. I'm quite certain that no submittal was = intended for the home user. 14. Appendix D, Page 52. Seems like spelling rogue as "rouge" is a = common mistake. May want to search/replace. 15. Appendix D, question 4. Could the submitter be a tad more specific = than "IP Tunnel". For instance, is there a control protocol to setup the = tunnels, etc. 16. Appendix D, question 5. Probably too late now, but I really question = how these claims can be made given the rather brief data - so we just = have to assume the claims are true. 17. Appendix E. Good write-up! 18. Appendix F. I have a question for the author, but this is purely = asked due to curiosity. In a home environment, you seem to imply that = there is a single set top box, and that you can provide dynamic power = assignment, but I wonder how you can do that with a single antenna - you = need a clear view of the whole space that needs to be covered. 19. Appendix F, section 9. The paragraph states that the PHY and MAC = association services are handled in the STB, and other MAC services are = in the controller. Is it possible to get a breakdown or at least an = understanding of what the other services being provided are? 20. Appendix L. I am curious about the fact that this architecture is = completely agnostic of the PHY, yet it can provide such functions as = centralized RF management (which cannot be performed if one has no idea = what they are dealing with). PatC ------_=_NextPart_001_01C46516.78D1551E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-capwap-arch-03.txt

First, I'd like to applaud the authors on a job well = done. It is clear in reading this spec that there was a significant = amount of data to work with... I am very impressed with the = document.

1. Section 1.3. "Typically ," -> "Typically, = "

2. This section defines the AP as terminating the 802.11 PHY, but it = should be noted that this device also terminates the
802.11 MAC mgmt layer, which is not specified.

3. The definition of Split MAC implies that all MAC mgmt is handled in = the AC, but in certain implementations this is not true. The MAC mgmt = packets that have very tight timing requirements can be handled in the = WTP.

4. Page 14. The text reads 14 contributions, yet above 16 is = mentioned.

5. Section 3.2. Another security issue is the very fact that this device = is most likely not under lock and key, but does contain secret = information in order to communicate with the backend systems, such as = AAA, SNMP, etc. Due to the common management method used by IT personel = of pushing a "template" to all similar devices, theft of such = a device would compromise the wired network.

5. A Network Management Station (NMS) should not be considered as part = of the Access Controller. While most controllers will provide one or = more management interfaces, a system that is used to scale a global = network generally resides on a separate system.

6. Page 25. The list of real-time features should probably include Power = Save handling.

7. Section 4.5. Could the authors please explain how they came to the = conclusion that Remote MAC "improves WTP manageability"?

8. Page 30. The term "Integration Service" is used as a = substitute to bringing function. However, the terminology section called = this function "portal". We should stick to a single term = throughout the document.

9. Page 33, second to last paragraph, there is a non traditional = character in the line that starts with "every mesh = node..."

10. Section 5.1. If stations (or non-trusted equipment) are allowed to = become part of the mesh backbone, end to end security is required = otherwise users traffic will be compromised.

11. Page 45. The URL for the LWAPP draft has changed and the one listed = has expired. Does it make sense to update it?

12. General comment. I understand that there was a desire to mask the = vendor in the appendices, but I wonder whether this makes sense. The = primary issue moving forward is that this is (and will) be known to = people on the list (or reading he archives)

13. Appendix C. We really should discourage baseless marketing claims = like "secure, scalable, large scale WLAN deployments" unless = one intends to back this up with facts. I'm quite certain that no = submittal was intended for the home user.

14. Appendix D, Page 52. Seems like spelling rogue as "rouge" = is a common mistake. May want to search/replace.

15. Appendix D, question 4. Could the submitter be a tad more specific = than "IP Tunnel". For instance, is there a control protocol to = setup the tunnels, etc.

16. Appendix D, question 5. Probably too late now, but I really question = how these claims can be made given the rather brief data - so we just = have to assume the claims are true.

17. Appendix E. Good write-up!

18. Appendix F. I have a question for the author, but this is purely = asked due to curiosity. In a home environment, you seem to imply that = there is a single set top box, and that you can provide dynamic power = assignment, but I wonder how you can do that with a single antenna - you = need a clear view of the whole space that needs to be covered.

19. Appendix F, section 9. The paragraph states that the PHY and MAC = association services are handled in the STB, and other MAC services are = in the controller. Is it possible to get a breakdown or at least an = understanding of what the other services being provided are?

20. Appendix L. I am curious about the fact that this architecture is = completely agnostic of the PHY, yet it can provide such functions as = centralized RF management (which cannot be performed if one has no idea = what they are dealing with).

PatC

------_=_NextPart_001_01C46516.78D1551E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 9 10:59:23 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04105 for ; Fri, 9 Jul 2004 10:59:23 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71AED213E6; Fri, 9 Jul 2004 10:30:00 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CFC221405; Fri, 9 Jul 2004 10:29:53 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4429020482 for ; Fri, 9 Jul 2004 09:59:57 -0400 (EDT) Received: from gw.frascone.com (adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by mail.frascone.com (Postfix) with ESMTP id BA04E1FD65 for ; Fri, 9 Jul 2004 09:59:55 -0400 (EDT) Received: by gw.frascone.com (Postfix, from userid 500) id B5D0858058B; Fri, 9 Jul 2004 09:13:52 -0500 (CDT) From: David Frascone To: capwap@frascone.com Message-ID: <20040709141352.GE9186@wolverine.frascone.com> Mail-Followup-To: capwap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] testing Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 9 Jul 2004 09:13:52 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Testing, please ignore -- David Frascone You are only young once, but you can be immature forever. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 9 13:17:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12332 for ; Fri, 9 Jul 2004 13:17:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27B682027E; Fri, 9 Jul 2004 13:03:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A10020731; Fri, 9 Jul 2004 13:03:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2DC7020731 for ; Fri, 9 Jul 2004 13:02:47 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 166572027E for ; Fri, 9 Jul 2004 13:02:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C465D8.E2BFFA30" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C400E@AIREMAIL.airespace.com> Thread-Topic: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Thread-Index: AcRlzo+GbgrkNQQpREKddX7lapm/FAACjqOh From: "Pat R. Calhoun" To: "Matt Holdrege" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 9 Jul 2004 10:18:45 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C465D8.E2BFFA30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think my question was whether a station can become a mesh node - or = whether trusted nodes are only used in the mesh network. If so, then = hop-by-hop encryption would not be sufficient, right? =20 PatC ________________________________ From: Matt Holdrege [mailto:Matt.Holdrege@strixsystems.com] Sent: Fri 7/9/2004 9:05 AM To: capwap@frascone.com; Pat R. Calhoun Subject: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt At 08:07 PM 7/8/2004, Pat R. Calhoun wrote: > 10. Section 5.1. If stations (or non-trusted equipment) are allowed to = become part of the mesh backbone, end to end security is required = otherwise users traffic will be compromised. =20 I don't see the problem? We say that mesh nodes must authenticate each = other within the same admin domain and data transmission must be secure. = We also say every mesh link must be encrypted in order to prevent user = traffic from becoming encrypted within the mesh backbone. Is there other = language missing from section 5.1 that would cover your problem?=20 =20 -Matt =20 ------_=_NextPart_001_01C465D8.E2BFFA30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
I think my = question was =0A= whether a station can become a mesh node - or whether trusted nodes are = only =0A= used in the mesh network. If so, then hop-by-hop encryption would not be =0A= sufficient, right?
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: Matt Holdrege =0A= [mailto:Matt.Holdrege@strixsystems.com]
Sent: Fri 7/9/2004 = 9:05 =0A= AM
To: capwap@frascone.com; Pat R. Calhoun
Subject: = Re: =0A= [Capwap] Comments on draft-ietf-capwap-arch-03.txt

=0A=
=0A=
=0A=

At 08:07 PM 7/8/2004, Pat R. Calhoun =0A= wrote:

=0A=

> 10. Section 5.1. If stations (or = non-trusted =0A= equipment) are allowed to become part of the mesh backbone, end to end = security =0A= is required otherwise users traffic will be = compromised.

=0A=

 

=0A=

I don’t see the = problem? We say that =0A= mesh nodes must authenticate each other within the same admin domain and = data =0A= transmission must be secure. We also say every mesh link must be = encrypted in =0A= order to prevent user traffic from becoming encrypted within the mesh = backbone. =0A= Is there other language missing from section 5.1 that would cover your = problem? =0A=

=0A=

 

=0A=

-Matt

=0A=

 

=0A= =0A= =0A= =0A= ------_=_NextPart_001_01C465D8.E2BFFA30-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 9 13:55:05 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15206 for ; Fri, 9 Jul 2004 13:55:04 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 755B520731; Fri, 9 Jul 2004 13:41:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 59A982132A; Fri, 9 Jul 2004 13:41:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F1A22132A for ; Fri, 9 Jul 2004 13:40:45 -0400 (EDT) Received: from out012.verizon.net (out012pub.verizon.net [206.46.170.137]) by mail.frascone.com (Postfix) with ESMTP id 865E720731 for ; Fri, 9 Jul 2004 13:40:43 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([208.179.69.254]) by out012.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040709175440.LDRK2198.out012.verizon.net@Matt-Holdrege.verizon.net>; Fri, 9 Jul 2004 12:54:40 -0500 Message-Id: <6.1.0.6.2.20040709195005.020fa380@incoming.verizon.net> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: "Pat R. Calhoun" , "Matt Holdrege" , From: Matt Holdrege Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C400E@AIREMAIL.airespac e.com> References: <55749BC69138654EBBC4C50BA4F55610020C400E@AIREMAIL.airespace.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [208.179.69.254] at Fri, 9 Jul 2004 12:54:36 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 09 Jul 2004 19:54:24 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Maybe more language is necessary, but I think it is kinda redundant to say you don't include stations in backbones. And it may also be redundant to say trusted nodes only since we already say you must do mutual authentication which should prevent un-trusted nodes, right? But anyhow, message to the Editor: Include after the authentication sentence in 5.1 "Each node that is part of the Mesh must be fully trusted for the mesh to be secure". At 07:18 PM 7/9/2004, Pat R. Calhoun wrote: >I think my question was whether a station can become a mesh node - or >whether trusted nodes are only used in the mesh network. If so, then >hop-by-hop encryption would not be sufficient, right? > >PatC > > >---------- >From: Matt Holdrege [mailto:Matt.Holdrege@strixsystems.com] >Sent: Fri 7/9/2004 9:05 AM >To: capwap@frascone.com; Pat R. Calhoun >Subject: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > >At 08:07 PM 7/8/2004, Pat R. Calhoun wrote: > > 10. Section 5.1. If stations (or non-trusted equipment) are allowed to > become part of the mesh backbone, end to end security is required > otherwise users traffic will be compromised. > >I don't see the problem? We say that mesh nodes must authenticate each >other within the same admin domain and data transmission must be secure. >We also say every mesh link must be encrypted in order to prevent user >traffic from becoming encrypted within the mesh backbone. Is there other >language missing from section 5.1 that would cover your problem? > >-Matt > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 9 16:36:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28502 for ; Fri, 9 Jul 2004 16:36:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E4AFB202D8; Fri, 9 Jul 2004 16:22:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B695820A48; Fri, 9 Jul 2004 16:22:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9588A202D8 for ; Fri, 9 Jul 2004 16:21:49 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 5AA1B20A48 for ; Fri, 9 Jul 2004 16:21:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C465F4.A9C841AC" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C4014@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Thread-Index: AcRl3jLWhQVVngBxQmugc3uKzpbmYgAFklJE From: "Pat R. Calhoun" To: "Matt Holdrege" , "Matt Holdrege" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 9 Jul 2004 13:37:00 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C465F4.A9C841AC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Many people consider a meshed network to comprise of a auto-organizing = wireless network that includes stations. I'm ok if the change is not = added - it was mostly out of curiosity. =20 That said, I agree with everything you've said. =20 PatC ________________________________ From: Matt Holdrege [mailto:matt.holdrege@verizon.net] Sent: Fri 7/9/2004 10:54 AM To: Pat R. Calhoun; Matt Holdrege; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Maybe more language is necessary, but I think it is kinda redundant to = say you don't include stations in backbones. And it may also be redundant to say trusted nodes only since we already say you must do mutual authentication which should prevent un-trusted nodes, right? But anyhow, message to the Editor: Include after the authentication sentence in 5.1 "Each node that is part of the Mesh must be fully trusted for the mesh = to be secure". At 07:18 PM 7/9/2004, Pat R. Calhoun wrote: >I think my question was whether a station can become a mesh node - or >whether trusted nodes are only used in the mesh network. If so, then >hop-by-hop encryption would not be sufficient, right? > >PatC > > >---------- >From: Matt Holdrege [mailto:Matt.Holdrege@strixsystems.com] >Sent: Fri 7/9/2004 9:05 AM >To: capwap@frascone.com; Pat R. Calhoun >Subject: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > >At 08:07 PM 7/8/2004, Pat R. Calhoun wrote: > > 10. Section 5.1. If stations (or non-trusted equipment) are allowed = to > become part of the mesh backbone, end to end security is required > otherwise users traffic will be compromised. > >I don't see the problem? We say that mesh nodes must authenticate each >other within the same admin domain and data transmission must be = secure. >We also say every mesh link must be encrypted in order to prevent user >traffic from becoming encrypted within the mesh backbone. Is there = other >language missing from section 5.1 that would cover your problem? > >-Matt > ------_=_NextPart_001_01C465F4.A9C841AC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt=0A= =0A= =0A=
=0A=
Many people = consider a meshed =0A= network to comprise of a auto-organizing wireless network that includes =0A= stations. I'm ok if the change is not added - it was mostly out of =0A= curiosity.
=0A=
 
=0A=
That said, I agree with = everything you've =0A= said.
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: Matt Holdrege =0A= [mailto:matt.holdrege@verizon.net]
Sent: Fri 7/9/2004 10:54 =0A= AM
To: Pat R. Calhoun; Matt Holdrege; =0A= capwap@frascone.com
Subject: RE: [Capwap] Comments on =0A= draft-ietf-capwap-arch-03.txt

=0A=
=0A=

Maybe more language is necessary, but I think it is = kinda =0A= redundant to say
you don't include stations in backbones. And it may = also be =0A= redundant to
say trusted nodes only since we already say you must do =0A= mutual
authentication which should prevent un-trusted nodes, right? = But =0A= anyhow,
message to the Editor: Include after the authentication = sentence in =0A= 5.1
"Each node that is part of the Mesh must be fully trusted for the = mesh =0A= to
be secure".



At 07:18 PM 7/9/2004, Pat R. Calhoun =0A= wrote:
>I think my question was whether a station can become a = mesh node - =0A= or
>whether trusted nodes are only used in the mesh network. If = so, =0A= then
>hop-by-hop encryption would not be sufficient, =0A= right?
>
>PatC
>
>
>----------
>From:= Matt =0A= Holdrege [mailto:Matt.Holdrege@strix= systems.com]
>Sent: =0A= Fri 7/9/2004 9:05 AM
>To: capwap@frascone.com; Pat R. =0A= Calhoun
>Subject: Re: [Capwap] Comments on =0A= draft-ietf-capwap-arch-03.txt
>
>At 08:07 PM 7/8/2004, Pat = R. =0A= Calhoun wrote:
> > 10. Section 5.1. If stations (or non-trusted =0A= equipment) are allowed to
> become part of the mesh backbone, end = to end =0A= security is required
> otherwise users traffic will be =0A= compromised.
>
>I don't see the problem? We say that mesh = nodes must =0A= authenticate each
>other within the same admin domain and data =0A= transmission must be secure.
>We also say every mesh link must be =0A= encrypted in order to prevent user
>traffic from becoming = encrypted within =0A= the mesh backbone. Is there other
>language missing from section = 5.1 that =0A= would cover your =0A= problem?
>
>-Matt
>


=0A= =0A= =0A= ------_=_NextPart_001_01C465F4.A9C841AC-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 9 17:10:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00821 for ; Fri, 9 Jul 2004 17:10:02 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8829C2135B; Fri, 9 Jul 2004 16:56:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3421220D12; Fri, 9 Jul 2004 16:56:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 607FD20D12 for ; Fri, 9 Jul 2004 16:55:16 -0400 (EDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mail.frascone.com (Postfix) with ESMTP id A8500207AB for ; Fri, 9 Jul 2004 16:55:14 -0400 (EDT) Received: from Matt-Holdrege.verizon.net ([81.48.112.250]) by out005.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040709210911.XAJW3910.out005.verizon.net@Matt-Holdrege.verizon.net>; Fri, 9 Jul 2004 16:09:11 -0500 Message-Id: <6.1.0.6.2.20040709230605.021f1318@incoming.verizon.net> X-Sender: res06gzk@incoming.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: "Pat R. Calhoun" , "Matt Holdrege" , From: Matt Holdrege Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C4014@AIREMAIL.airespac e.com> References: <55749BC69138654EBBC4C50BA4F55610020C4014@AIREMAIL.airespace.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [81.48.112.250] at Fri, 9 Jul 2004 16:09:08 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 09 Jul 2004 23:08:55 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) A Mesh node may very well contain the functions of an 802.11 STA as it is pretty much required if you want to be standards compliant, but it's not as if it's a true end-user station. -Matt At 10:37 PM 7/9/2004, Pat R. Calhoun wrote: >Many people consider a meshed network to comprise of a auto-organizing >wireless network that includes stations. I'm ok if the change is not added >- it was mostly out of curiosity. > >That said, I agree with everything you've said. > >PatC > > >---------- >From: Matt Holdrege [mailto:matt.holdrege@verizon.net] >Sent: Fri 7/9/2004 10:54 AM >To: Pat R. Calhoun; Matt Holdrege; capwap@frascone.com >Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > >Maybe more language is necessary, but I think it is kinda redundant to say >you don't include stations in backbones. And it may also be redundant to >say trusted nodes only since we already say you must do mutual >authentication which should prevent un-trusted nodes, right? But anyhow, >message to the Editor: Include after the authentication sentence in 5.1 >"Each node that is part of the Mesh must be fully trusted for the mesh to >be secure". > > > >At 07:18 PM 7/9/2004, Pat R. Calhoun wrote: > >I think my question was whether a station can become a mesh node - or > >whether trusted nodes are only used in the mesh network. If so, then > >hop-by-hop encryption would not be sufficient, right? > > > >PatC > > > > > >---------- > >From: Matt Holdrege > [mailto:Matt.Holdrege@strixsystems.com] > >Sent: Fri 7/9/2004 9:05 AM > >To: capwap@frascone.com; Pat R. Calhoun > >Subject: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > >At 08:07 PM 7/8/2004, Pat R. Calhoun wrote: > > > 10. Section 5.1. If stations (or non-trusted equipment) are allowed to > > become part of the mesh backbone, end to end security is required > > otherwise users traffic will be compromised. > > > >I don't see the problem? We say that mesh nodes must authenticate each > >other within the same admin domain and data transmission must be secure. > >We also say every mesh link must be encrypted in order to prevent user > >traffic from becoming encrypted within the mesh backbone. Is there other > >language missing from section 5.1 that would cover your problem? > > > >-Matt > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 12 21:27:19 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09319 for ; Mon, 12 Jul 2004 21:27:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19E8A20821; Mon, 12 Jul 2004 21:05:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 951E220FA7; Mon, 12 Jul 2004 21:05:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 320F120FA7 for ; Mon, 12 Jul 2004 21:04:02 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id C1A2020821 for ; Mon, 12 Jul 2004 21:03:47 -0400 (EDT) Received: from jadefox ([10.81.113.120]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i6D1FhEm019449; Tue, 13 Jul 2004 09:15:43 +0800 (SGT) Reply-To: From: "Saravanan Govindan" To: "'Pat R. Calhoun'" , Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Organization: Panasonic Singapore Laboratories Message-ID: <001d01c46877$5068aa10$7871510a@jadefox> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C3FDB@AIREMAIL.airespace.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Jul 2004 09:18:32 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear Pat, Some responses to your questions; > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. > 18. Appendix F. I have a question for the author, but this is purely asked due to curiosity. In a home > environment, you seem to imply that there is a single set top box, and that you can provide dynamic power > assignment, but I wonder how you can do that with a single antenna - you need a clear view of the whole space > that needs to be covered. We see one set top box in each home and a residential community made up of a number of boxes. Dynamic power assignment refers to managing all the STBs - and thus all the antennas - within the community. So the controller sees the entire wireless channel and makes appropriate adjustments at the STBs. > 19. Appendix F, section 9. The paragraph states that the PHY and MAC association services are handled in the > STB, and other MAC services are in the controller. Is it possible to get a breakdown or at least an > understanding of what the other services being provided are? The controller handles services like 11i authentication and encryption. Cheers Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 09/07/2004 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 12 22:33:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16503 for ; Mon, 12 Jul 2004 22:33:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BDB1F1FF8E; Mon, 12 Jul 2004 22:16:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50486207F9; Mon, 12 Jul 2004 22:16:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCF07207F9 for ; Mon, 12 Jul 2004 22:15:58 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 0E6D11FF8E for ; Mon, 12 Jul 2004 22:15:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46881.A7F40B62" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C40A0@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt thread-index: AcRod5omHU2oDxIcRfq60d2JM5amOQACZ9Da From: "Pat R. Calhoun" To: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 12 Jul 2004 19:29:29 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C46881.A7F40B62 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves=20 > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices.=20 But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one = implements remote or split MAC does not really change how one would manage such a = network -=20 so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) = made in the document PatC ------_=_NextPart_001_01C46881.A7F40B62 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

> 7. Section 4.5. Could the authors please explain = how they came to the
conclusion that Remote MAC "improves
> WTP manageability"?

If I can proffer an explanation; the characteristics of Remote MAC
follow from those of the Split MAC architecture. The Split MAC = improves
manageability over basic autonomous WTPs by centralizing some = control
aspects; Remote MAC goes further by centralizing 'all' aspects of = the
MAC. So the entire MAC processing is consolidated while the WTPs = become
extremely light devices.

<PRC> But one of the "advantages" of a centralized = architecture, is that the
WTP look like "local interfaces", and are managed as such. = Whether one implements
remote or split MAC does not really change how one would manage such a = network -
so it's really down to implementation details.

<PRC> So as a consequence I disagree with the assumption (and = statement) made
in the document

PatC

------_=_NextPart_001_01C46881.A7F40B62-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 12 23:29:07 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20109 for ; Mon, 12 Jul 2004 23:29:06 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD2AF21658; Mon, 12 Jul 2004 23:15:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9ABCE21654; Mon, 12 Jul 2004 23:15:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 46E4E21653 for ; Mon, 12 Jul 2004 23:14:13 -0400 (EDT) Received: from hubble.802wirelessworld.com (unknown [209.95.39.68]) by mail.frascone.com (Postfix) with ESMTP id 95E4C21652 for ; Mon, 12 Jul 2004 23:14:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by 80211wirelessworld.com (Postfix) with ESMTP id 5C7BD13B6F7 for ; Mon, 12 Jul 2004 23:27:43 -0400 (EDT) Received: from hubble.802wirelessworld.com ([127.0.0.1]) by localhost (hubble [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30877-03 for ; Mon, 12 Jul 2004 23:27:43 -0400 (EDT) Received: from 10.0.13.218 (dhcp13-218.802wirelessworld.com [10.0.13.218]) by hubble.802wirelessworld.com (Postfix) with SMTP id C2D7813B88E for ; Mon, 12 Jul 2004 23:27:42 -0400 (EDT) From: "Cheng Hong" To: "'Pat R. Calhoun'" , , Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Organization: Panasonic Singapore Laboratories Message-ID: <000301c46889$6d598c90$da0d000a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C40A0@AIREMAIL.airespace.com> X-GCMulti: 1 X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at idealcorp.com X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Jul 2004 11:28:07 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 12 23:39:28 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20486 for ; Mon, 12 Jul 2004 23:39:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35D5820D9F; Mon, 12 Jul 2004 23:21:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC0E121652; Mon, 12 Jul 2004 23:21:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0799620D9F for ; Mon, 12 Jul 2004 23:20:46 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 3BA1820A07 for ; Mon, 12 Jul 2004 23:20:43 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4688A.BBE854A7" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C40A4@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt thread-index: AcRoidKvb9Wl1mnZQ/Oz3naVQYHuDwAAI11O From: "Pat R. Calhoun" To: "Cheng Hong" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 12 Jul 2004 20:35:00 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4688A.BBE854A7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I = do not agree with that sentence, and the document also does not provide = any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =20 Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC=20 ------_=_NextPart_001_01C4688A.BBE854A7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

I'm obviously not arguing that centralization is = better... my point was that the sentence that remote vs. split provides = better manageability. I do not agree with that sentence, and the = document also does not provide any supporting data to prove the = point.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point is that with a centralized arch. you have more = information
about the network, i.e. at the centralized controller you have a = overall
view of the network instead of just the AP point of view. Therefore, = more
"value added" service could be provided. One simple example is = that the SME
could make better decisions with info from several AP.


cheers

Cheng Hong




-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 AM
To: sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could the authors please explain how they came to = the
conclusion that Remote MAC "improves
> WTP manageability"?

If I can proffer an explanation; the characteristics of Remote MAC
follow from those of the Split MAC architecture. The Split MAC = improves
manageability over basic autonomous WTPs by centralizing some = control
aspects; Remote MAC goes further by centralizing 'all' aspects of = the
MAC. So the entire MAC processing is consolidated while the WTPs = become
extremely light devices.

<PRC> But one of the "advantages" of a centralized = architecture, is that the
WTP look like "local interfaces", and are managed as such. = Whether one
implements
remote or split MAC does not really change how one would manage such = a
network -
so it's really down to implementation details.

<PRC> So as a consequence I disagree with the assumption (and = statement)
made
in the document

PatC

------_=_NextPart_001_01C4688A.BBE854A7-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 12 23:55:11 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21166 for ; Mon, 12 Jul 2004 23:55:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7974A2021A; Mon, 12 Jul 2004 23:37:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1FF022034B; Mon, 12 Jul 2004 23:37:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6E1592034B for ; Mon, 12 Jul 2004 23:36:06 -0400 (EDT) Received: from hubble.802wirelessworld.com (unknown [209.95.39.68]) by mail.frascone.com (Postfix) with ESMTP id 4935A2021A for ; Mon, 12 Jul 2004 23:36:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by 80211wirelessworld.com (Postfix) with ESMTP id E616C13B6F7 for ; Mon, 12 Jul 2004 23:49:36 -0400 (EDT) Received: from hubble.802wirelessworld.com ([127.0.0.1]) by localhost (hubble [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31013-09 for ; Mon, 12 Jul 2004 23:49:36 -0400 (EDT) Received: from 10.0.13.218 (dhcp13-218.802wirelessworld.com [10.0.13.218]) by hubble.802wirelessworld.com (Postfix) with SMTP id D553513B88E for ; Mon, 12 Jul 2004 23:49:35 -0400 (EDT) From: "Cheng Hong" To: "'Pat R. Calhoun'" , , Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Organization: Panasonic Singapore Laboratories Message-ID: <000901c4688c$7bb38810$da0d000a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C468CF.89D6C810" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C40A4@AIREMAIL.airespace.com> X-GCMulti: 1 X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at idealcorp.com X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Jul 2004 11:50:00 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C468CF.89D6C810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the = AC. Thus, the manageability will be better.=20 =20 But, of course the centralization also brings other issues, and = therefore the degree of split should be a trade off result of different aspects. =20 cheers =20 Cheng Hong=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I do = not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------=_NextPart_000_000A_01C468CF.89D6C810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
As for=20 the remote vs split, when we apply the same logic here, when the degree = of=20 centralization increases, more info will be available at the AC. Thus, = the=20 manageability will be better.
 
But,=20 of course the centralization also brings other issues, and therefore the = degree=20 of split should be a trade off result of different = aspects.
 
cheers
 
Cheng=20 Hong
-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of=20 Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35=20 AM
To: Cheng Hong; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

I'm obviously not arguing that centralization is = better... my=20 point was that the sentence that remote vs. split provides better=20 manageability. I do not agree with that sentence, and the document = also does=20 not provide any supporting data to prove the=20 point.

PatC
-----Original Message-----
From: Cheng Hong = [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point = is that=20 with a centralized arch. you have more information
about the = network, i.e.=20 at the centralized controller you have a overall
view of the = network=20 instead of just the AP point of view. Therefore, more
"value added" = service=20 could be provided. One simple example is that the SME
could make = better=20 decisions with info from several AP.


cheers

Cheng=20 Hong




-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 = AM
To:=20 sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] = Comments on=20 draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could = the=20 authors please explain how they came to the
conclusion that Remote = MAC=20 "improves
> WTP manageability"?

If I can proffer an = explanation;=20 the characteristics of Remote MAC
follow from those of the Split = MAC=20 architecture. The Split MAC improves
manageability over basic = autonomous=20 WTPs by centralizing some control
aspects; Remote MAC goes further = by=20 centralizing 'all' aspects of the
MAC. So the entire MAC processing = is=20 consolidated while the WTPs become
extremely light=20 devices.

<PRC> But one of the "advantages" of a = centralized=20 architecture, is that the
WTP look like "local interfaces", and are = managed=20 as such. Whether one
implements
remote or split MAC does not = really=20 change how one would manage such a
network -
so it's really down = to=20 implementation details.

<PRC> So as a consequence I = disagree with=20 the assumption (and statement)
made
in the=20 = document

PatC





------=_NextPart_000_000A_01C468CF.89D6C810-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 12 23:56:52 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21245 for ; Mon, 12 Jul 2004 23:56:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10553204E9; Mon, 12 Jul 2004 23:41:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D051204EC; Mon, 12 Jul 2004 23:41:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 97205204EC for ; Mon, 12 Jul 2004 23:40:36 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 30FA1204E9 for ; Mon, 12 Jul 2004 23:40:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4688D.819F2572" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C40A5@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt thread-index: AcRojOipGUQTZxlrQ+mO8bJhPtzw/AAAElqh From: "Pat R. Calhoun" To: "Cheng Hong" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 12 Jul 2004 20:55:11 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4688D.819F2572 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Could I perhaps ask you to provide me with concrete data that proves = this is the case? I have plenty of data that proves that the centralized = approach provides much better manageability. However, there is nothing = in my data that shows that where some of the finer components of the MAC = terminate increase (or decrease) manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =20 As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the = AC. Thus, the manageability will be better.=20 =20 But, of course the centralization also brings other issues, and = therefore the degree of split should be a trade off result of different aspects. =20 cheers =20 Cheng Hong=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I do = not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------_=_NextPart_001_01C4688D.819F2572 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Could I perhaps ask you to provide me with concrete = data that proves this is the case? I have plenty of data that proves = that the centralized approach provides much better manageability. = However, there is nothing in my data that shows that where some of the = finer components of the MAC terminate increase (or decrease) = manageability.

PatC


-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

As for the remote vs split, when we apply the same logic here, when = the
degree of centralization increases, more info will be available at the = AC.
Thus, the manageability will be better.

But, of course the centralization also brings other issues, and = therefore
the degree of split should be a trade off result of different = aspects.

cheers

Cheng Hong

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 AM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



I'm obviously not arguing that centralization is better... my point was = that
the sentence that remote vs. split provides better manageability. I do = not
agree with that sentence, and the document also does not provide any
supporting data to prove the point.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point is that with a centralized arch. you have more = information
about the network, i.e. at the centralized controller you have a = overall
view of the network instead of just the AP point of view. Therefore, = more
"value added" service could be provided. One simple example is = that the SME
could make better decisions with info from several AP.


cheers

Cheng Hong




-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 AM
To: sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could the authors please explain how they came to = the
conclusion that Remote MAC "improves
> WTP manageability"?

If I can proffer an explanation; the characteristics of Remote MAC
follow from those of the Split MAC architecture. The Split MAC = improves
manageability over basic autonomous WTPs by centralizing some = control
aspects; Remote MAC goes further by centralizing 'all' aspects of = the
MAC. So the entire MAC processing is consolidated while the WTPs = become
extremely light devices.

<PRC> But one of the "advantages" of a centralized = architecture, is that the
WTP look like "local interfaces", and are managed as such. = Whether one
implements
remote or split MAC does not really change how one would manage such = a
network -
so it's really down to implementation details.

<PRC> So as a consequence I disagree with the assumption (and = statement)
made
in the document

PatC

------_=_NextPart_001_01C4688D.819F2572-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 13 00:01:10 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21527 for ; Tue, 13 Jul 2004 00:01:10 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA18E21663; Mon, 12 Jul 2004 23:47:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B234A21664; Mon, 12 Jul 2004 23:47:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9605D204EC for ; Mon, 12 Jul 2004 23:46:58 -0400 (EDT) Received: from hubble.802wirelessworld.com (unknown [209.95.39.68]) by mail.frascone.com (Postfix) with ESMTP id 9EA0E201F1 for ; Mon, 12 Jul 2004 23:46:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by 80211wirelessworld.com (Postfix) with ESMTP id D8E3613B897 for ; Tue, 13 Jul 2004 00:00:29 -0400 (EDT) Received: from hubble.802wirelessworld.com ([127.0.0.1]) by localhost (hubble [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31229-07 for ; Tue, 13 Jul 2004 00:00:29 -0400 (EDT) Received: from 10.0.13.218 (dhcp13-218.802wirelessworld.com [10.0.13.218]) by hubble.802wirelessworld.com (Postfix) with SMTP id 396FE13B88E for ; Tue, 13 Jul 2004 00:00:29 -0400 (EDT) From: "Cheng Hong" To: "'Pat R. Calhoun'" , , Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Organization: Panasonic Singapore Laboratories Message-ID: <001001c4688e$015ddd70$da0d000a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C468D1.0F811D70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C40A5@AIREMAIL.airespace.com> X-GCMulti: 1 X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at idealcorp.com X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Jul 2004 12:00:53 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C468D1.0F811D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This really depends on how you define MANAGEABILITY. If the decrease in signaling message is counted as increase in managemeability, it is = obivous that that moving the whole MAC to AC will simplify the protocol messages used between AC and AP (at least less messags).=20 =20 cheers =20 Cheng=20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Tuesday, July 13, 2004 11:55 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Could I perhaps ask you to provide me with concrete data that proves = this is the case? I have plenty of data that proves that the centralized = approach provides much better manageability. However, there is nothing in my data that shows that where some of the finer components of the MAC terminate increase (or decrease) manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the = AC. Thus, the manageability will be better. But, of course the centralization also brings other issues, and = therefore the degree of split should be a trade off result of different aspects. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I do = not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------=_NextPart_000_0011_01C468D1.0F811D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
This=20 really depends on how you define MANAGEABILITY. If the decrease in = signaling=20 message is counted as increase in managemeability, it is obivous that=20 that moving the whole MAC to AC will simplify the = protocol=20 messages used between AC and AP (at least less messags). =
 
cheers
 
Cheng=20
-----Original Message-----
From: Pat = R. Calhoun=20 [mailto:pcalhoun@airespace.com]
Sent: Tuesday, July 13, = 2004 11:55=20 AM
To: Cheng Hong; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Could I perhaps ask you to provide me with concrete = data that=20 proves this is the case? I have plenty of data that proves that the=20 centralized approach provides much better manageability. However, = there is=20 nothing in my data that shows that where some of the finer components = of the=20 MAC terminate increase (or decrease)=20 manageability.

PatC


-----Original = Message-----
From:=20 Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

As for the remote vs split, when = we apply=20 the same logic here, when the
degree of centralization increases, = more info=20 will be available at the AC.
Thus, the manageability will be=20 better.

But, of course the centralization also brings other = issues, and=20 therefore
the degree of split should be a trade off result of = different=20 aspects.

cheers

Cheng Hong

-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 = AM
To:=20 Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: = [Capwap]=20 Comments on draft-ietf-capwap-arch-03.txt



I'm obviously = not=20 arguing that centralization is better... my point was that
the = sentence=20 that remote vs. split provides better manageability. I do not
agree = with=20 that sentence, and the document also does not provide = any
supporting data=20 to prove the point.

PatC
-----Original Message-----
From: = Cheng=20 Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point = is that=20 with a centralized arch. you have more information
about the = network, i.e.=20 at the centralized controller you have a overall
view of the = network=20 instead of just the AP point of view. Therefore, more
"value added" = service=20 could be provided. One simple example is that the SME
could make = better=20 decisions with info from several AP.


cheers

Cheng=20 Hong




-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 = AM
To:=20 sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] = Comments on=20 draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could = the=20 authors please explain how they came to the
conclusion that Remote = MAC=20 "improves
> WTP manageability"?

If I can proffer an = explanation;=20 the characteristics of Remote MAC
follow from those of the Split = MAC=20 architecture. The Split MAC improves
manageability over basic = autonomous=20 WTPs by centralizing some control
aspects; Remote MAC goes further = by=20 centralizing 'all' aspects of the
MAC. So the entire MAC processing = is=20 consolidated while the WTPs become
extremely light=20 devices.

<PRC> But one of the "advantages" of a = centralized=20 architecture, is that the
WTP look like "local interfaces", and are = managed=20 as such. Whether one
implements
remote or split MAC does not = really=20 change how one would manage such a
network -
so it's really down = to=20 implementation details.

<PRC> So as a consequence I = disagree with=20 the assumption (and statement)
made
in the=20 = document

PatC









------=_NextPart_000_0011_01C468D1.0F811D70-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 13 00:15:08 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22609 for ; Tue, 13 Jul 2004 00:15:07 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 59A81201F1; Tue, 13 Jul 2004 00:01:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDE3B202E8; Tue, 13 Jul 2004 00:01:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09AB72080C for ; Tue, 13 Jul 2004 00:00:09 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 684E3202E8 for ; Tue, 13 Jul 2004 00:00:06 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46890.3C64BB57" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C40A7@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt thread-index: AcRojmaT4oXBD6JtSemWx8vO+FAKqQAAWdm0 From: "Pat R. Calhoun" To: "Cheng Hong" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 12 Jul 2004 21:13:51 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C46890.3C64BB57 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But I would equally argue that a remote MAC causes *all* traffic to = traverse the network from the AP to the AC (because the AP is really = dumb). One of the benefits of Split MAC is that you have the ability to = "protect" network resources by being able to apply specific filters at = the edge. For example, if you have an encrypted channel, and you are = capable of decrypting packets at the edge, you would further protect the = network by ensuring that only properly encrypted packets enter the wired = network. So if unnecessary burden of the wired network is considered a management = burden, then I would argue that Split MAC increases manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:00 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =20 This really depends on how you define MANAGEABILITY. If the decrease in signaling message is counted as increase in managemeability, it is = obivous that that moving the whole MAC to AC will simplify the protocol messages used between AC and AP (at least less messags).=20 =20 cheers =20 Cheng=20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Tuesday, July 13, 2004 11:55 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Could I perhaps ask you to provide me with concrete data that proves = this is the case? I have plenty of data that proves that the centralized = approach provides much better manageability. However, there is nothing in my data that shows that where some of the finer components of the MAC terminate increase (or decrease) manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the = AC. Thus, the manageability will be better. But, of course the centralization also brings other issues, and = therefore the degree of split should be a trade off result of different aspects. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I do = not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------_=_NextPart_001_01C46890.3C64BB57 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

But I would equally argue that a remote MAC causes = *all* traffic to traverse the network from the AP to the AC (because the = AP is really dumb). One of the benefits of Split MAC is that you have = the ability to "protect" network resources by being able to = apply specific filters at the edge. For example, if you have an = encrypted channel, and you are capable of decrypting packets at the = edge, you would further protect the network by ensuring that only = properly encrypted packets enter the wired network.

So if unnecessary burden of the wired network is considered a management = burden, then I would argue that Split MAC increases manageability.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 9:00 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

This really depends on how you define MANAGEABILITY. If the decrease = in
signaling message is counted as increase in managemeability, it is = obivous
that that moving the whole MAC to AC will simplify the protocol = messages
used between AC and AP (at least less messags).

cheers

Cheng

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent: Tuesday, July 13, 2004 11:55 AM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



Could I perhaps ask you to provide me with concrete data that proves = this is
the case? I have plenty of data that proves that the centralized = approach
provides much better manageability. However, there is nothing in my = data
that shows that where some of the finer components of the MAC = terminate
increase (or decrease) manageability.

PatC


-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

As for the remote vs split, when we apply the same logic here, when = the
degree of centralization increases, more info will be available at the = AC.
Thus, the manageability will be better.

But, of course the centralization also brings other issues, and = therefore
the degree of split should be a trade off result of different = aspects.

cheers

Cheng Hong

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 AM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



I'm obviously not arguing that centralization is better... my point was = that
the sentence that remote vs. split provides better manageability. I do = not
agree with that sentence, and the document also does not provide any
supporting data to prove the point.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point is that with a centralized arch. you have more = information
about the network, i.e. at the centralized controller you have a = overall
view of the network instead of just the AP point of view. Therefore, = more
"value added" service could be provided. One simple example is = that the SME
could make better decisions with info from several AP.


cheers

Cheng Hong




-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 AM
To: sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could the authors please explain how they came to = the
conclusion that Remote MAC "improves
> WTP manageability"?

If I can proffer an explanation; the characteristics of Remote MAC
follow from those of the Split MAC architecture. The Split MAC = improves
manageability over basic autonomous WTPs by centralizing some = control
aspects; Remote MAC goes further by centralizing 'all' aspects of = the
MAC. So the entire MAC processing is consolidated while the WTPs = become
extremely light devices.

<PRC> But one of the "advantages" of a centralized = architecture, is that the
WTP look like "local interfaces", and are managed as such. = Whether one
implements
remote or split MAC does not really change how one would manage such = a
network -
so it's really down to implementation details.

<PRC> So as a consequence I disagree with the assumption (and = statement)
made
in the document

PatC

------_=_NextPart_001_01C46890.3C64BB57-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 13 00:27:17 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24793 for ; Tue, 13 Jul 2004 00:27:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2EFC20FBF; Tue, 13 Jul 2004 00:11:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D6B820D80; Tue, 13 Jul 2004 00:11:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B59520D80 for ; Tue, 13 Jul 2004 00:10:38 -0400 (EDT) Received: from hubble.802wirelessworld.com (unknown [209.95.39.68]) by mail.frascone.com (Postfix) with ESMTP id E150C20C5A for ; Tue, 13 Jul 2004 00:10:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by 80211wirelessworld.com (Postfix) with ESMTP id 2CED713B89B for ; Tue, 13 Jul 2004 00:24:09 -0400 (EDT) Received: from hubble.802wirelessworld.com ([127.0.0.1]) by localhost (hubble [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31465-08 for ; Tue, 13 Jul 2004 00:24:08 -0400 (EDT) Received: from 10.0.13.218 (dhcp13-218.802wirelessworld.com [10.0.13.218]) by hubble.802wirelessworld.com (Postfix) with SMTP id 99F3813B897 for ; Tue, 13 Jul 2004 00:24:08 -0400 (EDT) From: "Cheng Hong" To: "'Pat R. Calhoun'" , , Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Organization: Panasonic Singapore Laboratories Message-ID: <002101c46891$4f591000$da0d000a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C468D4.5D7C5000" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C40A7@AIREMAIL.airespace.com> X-GCMulti: 1 X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at idealcorp.com X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Jul 2004 12:24:33 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C468D4.5D7C5000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well. That is a valid point. But would that be equally a burden with the split MAC where you need to put in extra efforts to manage the filter = and the encryption at the edge? And, with a proper network design (not management), we don't need to care about the "burden" of traffic = considering that the wireless has much lower bandwidth offered than the wired = network. =20 cheers =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Tuesday, July 13, 2004 12:14 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt But I would equally argue that a remote MAC causes *all* traffic to = traverse the network from the AP to the AC (because the AP is really dumb). One = of the benefits of Split MAC is that you have the ability to "protect" = network resources by being able to apply specific filters at the edge. For = example, if you have an encrypted channel, and you are capable of decrypting = packets at the edge, you would further protect the network by ensuring that only properly encrypted packets enter the wired network. So if unnecessary burden of the wired network is considered a management burden, then I would argue that Split MAC increases manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:00 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt This really depends on how you define MANAGEABILITY. If the decrease in signaling message is counted as increase in managemeability, it is = obivous that that moving the whole MAC to AC will simplify the protocol messages used between AC and AP (at least less messags). cheers Cheng -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 11:55 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Could I perhaps ask you to provide me with concrete data that proves = this is the case? I have plenty of data that proves that the centralized = approach provides much better manageability. However, there is nothing in my data that shows that where some of the finer components of the MAC terminate increase (or decrease) manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the = AC. Thus, the manageability will be better. But, of course the centralization also brings other issues, and = therefore the degree of split should be a trade off result of different aspects. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I do = not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------=_NextPart_000_0022_01C468D4.5D7C5000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Well.=20 That is a valid point. But would that be equally a burden with the = split=20 MAC where you need to put in extra efforts to manage the filter and the=20 encryption at the edge?  And, with a proper network design (not=20 management), we don't need to care about the "burden" of traffic = considering=20 that the wireless has much lower bandwidth offered than the wired=20 network.
 
cheers
 
-----Original Message-----
From: Pat = R. Calhoun=20 [mailto:pcalhoun@airespace.com]
Sent: Tuesday, July 13, = 2004 12:14=20 PM
To: Cheng Hong; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

But I would equally argue that a remote MAC causes = *all*=20 traffic to traverse the network from the AP to the AC (because the AP = is=20 really dumb). One of the benefits of Split MAC is that you have the = ability to=20 "protect" network resources by being able to apply specific filters at = the=20 edge. For example, if you have an encrypted channel, and you are = capable of=20 decrypting packets at the edge, you would further protect the network = by=20 ensuring that only properly encrypted packets enter the wired=20 network.

So if unnecessary burden of the wired network is = considered a=20 management burden, then I would argue that Split MAC increases=20 manageability.

PatC
-----Original Message-----
From: = Cheng Hong=20 [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 9:00 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

This really depends on how you = define=20 MANAGEABILITY. If the decrease in
signaling message is counted as = increase=20 in managemeability, it is obivous
that that moving the whole MAC to = AC will=20 simplify the protocol messages
used between AC and AP (at least = less=20 messags).

cheers

Cheng

-----Original=20 Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent:=20 Tuesday, July 13, 2004 11:55 AM
To: Cheng Hong; = sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt



Could I perhaps ask you = to=20 provide me with concrete data that proves this is
the case? I have = plenty=20 of data that proves that the centralized approach
provides much = better=20 manageability. However, there is nothing in my data
that shows that = where=20 some of the finer components of the MAC terminate
increase (or = decrease)=20 manageability.

PatC


-----Original = Message-----
From:=20 Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

As for the remote vs split, when = we apply=20 the same logic here, when the
degree of centralization increases, = more info=20 will be available at the AC.
Thus, the manageability will be=20 better.

But, of course the centralization also brings other = issues, and=20 therefore
the degree of split should be a trade off result of = different=20 aspects.

cheers

Cheng Hong

-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 = AM
To:=20 Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: = [Capwap]=20 Comments on draft-ietf-capwap-arch-03.txt



I'm obviously = not=20 arguing that centralization is better... my point was that
the = sentence=20 that remote vs. split provides better manageability. I do not
agree = with=20 that sentence, and the document also does not provide = any
supporting data=20 to prove the point.

PatC
-----Original Message-----
From: = Cheng=20 Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point = is that=20 with a centralized arch. you have more information
about the = network, i.e.=20 at the centralized controller you have a overall
view of the = network=20 instead of just the AP point of view. Therefore, more
"value added" = service=20 could be provided. One simple example is that the SME
could make = better=20 decisions with info from several AP.


cheers

Cheng=20 Hong




-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 = AM
To:=20 sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] = Comments on=20 draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could = the=20 authors please explain how they came to the
conclusion that Remote = MAC=20 "improves
> WTP manageability"?

If I can proffer an = explanation;=20 the characteristics of Remote MAC
follow from those of the Split = MAC=20 architecture. The Split MAC improves
manageability over basic = autonomous=20 WTPs by centralizing some control
aspects; Remote MAC goes further = by=20 centralizing 'all' aspects of the
MAC. So the entire MAC processing = is=20 consolidated while the WTPs become
extremely light=20 devices.

<PRC> But one of the "advantages" of a = centralized=20 architecture, is that the
WTP look like "local interfaces", and are = managed=20 as such. Whether one
implements
remote or split MAC does not = really=20 change how one would manage such a
network -
so it's really down = to=20 implementation details.

<PRC> So as a consequence I = disagree with=20 the assumption (and statement)
made
in the=20 = document

PatC












<= BR>

------=_NextPart_000_0022_01C468D4.5D7C5000-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 13 01:04:27 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27132 for ; Tue, 13 Jul 2004 01:04:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 527B320FCC; Tue, 13 Jul 2004 00:47:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E9F1B20FCD; Tue, 13 Jul 2004 00:47:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA43320FCD for ; Tue, 13 Jul 2004 00:46:53 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 5F3ED20FCC for ; Tue, 13 Jul 2004 00:46:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46896.C441FB06" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C40A8@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt thread-index: AcRokbb8mFWN6s8FTueCXJpnDAzvKAAA7Xrh From: "Pat R. Calhoun" To: "Cheng Hong" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 12 Jul 2004 22:03:42 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C46896.C441FB06 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The one round trip "burden" of pushing a rule dow to the AP is minuscule = in comparison with opening up the floodgates for all traffic to be sent = to the AC. I agree that wired networks have higher bandwidth than the wireless = network, but I would wonder how many IT managers would be pleased to = know that their wired network investment is being used to potentially = carry unauthorized traffic because their wireless solution's APs cannot = provide any form of traffic policing. The advantage of Split MAC is that the AP is being told what it should = and shouldn't allow onto the wired network, and if encryption is done on = the AP, it will even eliminate invalid (perhaps malicious) traffic from = cluttering the wired network. This enables the AP to protect the AC's = resources, further guaranteeing a well behaved wireless system. Anyhow, the original point behind this whole thread was that I disagreed = with the statement in the document that stated that remote MAC was more = manageable than split MAC. If we can kill that sentence (or at least = provide some concrete data proving this is true), then I will more than = gladly get off my soap box. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:24 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =20 Well. That is a valid point. But would that be equally a burden with the split MAC where you need to put in extra efforts to manage the filter = and the encryption at the edge? And, with a proper network design (not management), we don't need to care about the "burden" of traffic = considering that the wireless has much lower bandwidth offered than the wired = network. =20 cheers =20 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=20 Sent: Tuesday, July 13, 2004 12:14 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt But I would equally argue that a remote MAC causes *all* traffic to = traverse the network from the AP to the AC (because the AP is really dumb). One = of the benefits of Split MAC is that you have the ability to "protect" = network resources by being able to apply specific filters at the edge. For = example, if you have an encrypted channel, and you are capable of decrypting = packets at the edge, you would further protect the network by ensuring that only properly encrypted packets enter the wired network. So if unnecessary burden of the wired network is considered a management burden, then I would argue that Split MAC increases manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:00 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt This really depends on how you define MANAGEABILITY. If the decrease in signaling message is counted as increase in managemeability, it is = obivous that that moving the whole MAC to AC will simplify the protocol messages used between AC and AP (at least less messags). cheers Cheng -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 11:55 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Could I perhaps ask you to provide me with concrete data that proves = this is the case? I have plenty of data that proves that the centralized = approach provides much better manageability. However, there is nothing in my data that shows that where some of the finer components of the MAC terminate increase (or decrease) manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the = AC. Thus, the manageability will be better. But, of course the centralization also brings other issues, and = therefore the degree of split should be a trade off result of different aspects. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I do = not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------_=_NextPart_001_01C46896.C441FB06 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

The one round trip "burden" of pushing a = rule dow to the AP is minuscule in comparison with opening up the = floodgates for all traffic to be sent to the AC.

I agree that wired networks have higher bandwidth than the wireless = network, but I would wonder how many IT managers would be pleased to = know that their wired network investment is being used to potentially = carry unauthorized traffic because their wireless solution's APs cannot = provide any form of traffic policing.

The advantage of Split MAC is that the AP is being told what it should = and shouldn't allow onto the wired network, and if encryption is done on = the AP, it will even eliminate invalid (perhaps malicious) traffic from = cluttering the wired network. This enables the AP to protect the AC's = resources, further guaranteeing a well behaved wireless system.

Anyhow, the original point behind this whole thread was that I disagreed = with the statement in the document that stated that remote MAC was more = manageable than split MAC. If we can kill that sentence (or at least = provide some concrete data proving this is true), then I will more than = gladly get off my soap box.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 9:24 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Well. That is a valid point. But would that be equally a burden with = the
split MAC where you need to put in extra efforts to manage the filter = and
the encryption at the edge?  And, with a proper network design = (not
management), we don't need to care about the "burden" of = traffic considering
that the wireless has much lower bandwidth offered than the wired = network.

cheers


-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent: Tuesday, July 13, 2004 12:14 PM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



But I would equally argue that a remote MAC causes *all* traffic to = traverse
the network from the AP to the AC (because the AP is really dumb). One = of
the benefits of Split MAC is that you have the ability to = "protect" network
resources by being able to apply specific filters at the edge. For = example,
if you have an encrypted channel, and you are capable of decrypting = packets
at the edge, you would further protect the network by ensuring that = only
properly encrypted packets enter the wired network.

So if unnecessary burden of the wired network is considered a = management
burden, then I would argue that Split MAC increases manageability.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 9:00 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

This really depends on how you define MANAGEABILITY. If the decrease = in
signaling message is counted as increase in managemeability, it is = obivous
that that moving the whole MAC to AC will simplify the protocol = messages
used between AC and AP (at least less messags).

cheers

Cheng

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent: Tuesday, July 13, 2004 11:55 AM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



Could I perhaps ask you to provide me with concrete data that proves = this is
the case? I have plenty of data that proves that the centralized = approach
provides much better manageability. However, there is nothing in my = data
that shows that where some of the finer components of the MAC = terminate
increase (or decrease) manageability.

PatC


-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

As for the remote vs split, when we apply the same logic here, when = the
degree of centralization increases, more info will be available at the = AC.
Thus, the manageability will be better.

But, of course the centralization also brings other issues, and = therefore
the degree of split should be a trade off result of different = aspects.

cheers

Cheng Hong

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 AM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



I'm obviously not arguing that centralization is better... my point was = that
the sentence that remote vs. split provides better manageability. I do = not
agree with that sentence, and the document also does not provide any
supporting data to prove the point.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point is that with a centralized arch. you have more = information
about the network, i.e. at the centralized controller you have a = overall
view of the network instead of just the AP point of view. Therefore, = more
"value added" service could be provided. One simple example is = that the SME
could make better decisions with info from several AP.


cheers

Cheng Hong




-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 AM
To: sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could the authors please explain how they came to = the
conclusion that Remote MAC "improves
> WTP manageability"?

If I can proffer an explanation; the characteristics of Remote MAC
follow from those of the Split MAC architecture. The Split MAC = improves
manageability over basic autonomous WTPs by centralizing some = control
aspects; Remote MAC goes further by centralizing 'all' aspects of = the
MAC. So the entire MAC processing is consolidated while the WTPs = become
extremely light devices.

<PRC> But one of the "advantages" of a centralized = architecture, is that the
WTP look like "local interfaces", and are managed as such. = Whether one
implements
remote or split MAC does not really change how one would manage such = a
network -
so it's really down to implementation details.

<PRC> So as a consequence I disagree with the assumption (and = statement)
made
in the document

PatC

------_=_NextPart_001_01C46896.C441FB06-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 13 10:36:13 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14970 for ; Tue, 13 Jul 2004 10:36:12 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB280207EA; Tue, 13 Jul 2004 10:22:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53F5D216DD; Tue, 13 Jul 2004 10:22:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 457E4216DD for ; Tue, 13 Jul 2004 10:21:56 -0400 (EDT) Received: from hubble.802wirelessworld.com (unknown [209.95.39.68]) by mail.frascone.com (Postfix) with ESMTP id 28874207EA for ; Tue, 13 Jul 2004 10:21:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by 80211wirelessworld.com (Postfix) with ESMTP id 6958313B89C for ; Tue, 13 Jul 2004 10:35:27 -0400 (EDT) Received: from hubble.802wirelessworld.com ([127.0.0.1]) by localhost (hubble [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02844-06 for ; Tue, 13 Jul 2004 10:35:27 -0400 (EDT) Received: from 10.0.13.218 (dhcp13-218.802wirelessworld.com [10.0.13.218]) by hubble.802wirelessworld.com (Postfix) with SMTP id AA9C813B897 for ; Tue, 13 Jul 2004 10:35:26 -0400 (EDT) From: "Cheng Hong" To: "'Pat R. Calhoun'" , , Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Organization: Panasonic Singapore Laboratories Message-ID: <001401c468e6$b62ac6c0$da0d000a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C46929.C44E06C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C40A8@AIREMAIL.airespace.com> Importance: Normal X-GCMulti: 1 X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at idealcorp.com X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Jul 2004 22:35:53 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C46929.C44E06C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't object the idea of provide more explanation about the issue at = all. Your reasoning of the edge filtering might serve as the example there. =20 But also one point to note is the difference between the manageability = of the AP and the network. The filtering function to be place at the edge = (AP) could improve the network manageability, but may descrease the = manageability of the AP (function) itself. =20 cheers =20 Cheng Hong=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 1:04 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt The one round trip "burden" of pushing a rule dow to the AP is minuscule = in comparison with opening up the floodgates for all traffic to be sent to = the AC. I agree that wired networks have higher bandwidth than the wireless = network, but I would wonder how many IT managers would be pleased to know that = their wired network investment is being used to potentially carry unauthorized traffic because their wireless solution's APs cannot provide any form of traffic policing. The advantage of Split MAC is that the AP is being told what it should = and shouldn't allow onto the wired network, and if encryption is done on the = AP, it will even eliminate invalid (perhaps malicious) traffic from = cluttering the wired network. This enables the AP to protect the AC's resources, further guaranteeing a well behaved wireless system. Anyhow, the original point behind this whole thread was that I disagreed with the statement in the document that stated that remote MAC was more manageable than split MAC. If we can kill that sentence (or at least = provide some concrete data proving this is true), then I will more than gladly = get off my soap box. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:24 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Well. That is a valid point. But would that be equally a burden with the split MAC where you need to put in extra efforts to manage the filter = and the encryption at the edge? And, with a proper network design (not management), we don't need to care about the "burden" of traffic = considering that the wireless has much lower bandwidth offered than the wired = network. cheers -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 12:14 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt But I would equally argue that a remote MAC causes *all* traffic to = traverse the network from the AP to the AC (because the AP is really dumb). One = of the benefits of Split MAC is that you have the ability to "protect" = network resources by being able to apply specific filters at the edge. For = example, if you have an encrypted channel, and you are capable of decrypting = packets at the edge, you would further protect the network by ensuring that only properly encrypted packets enter the wired network. So if unnecessary burden of the wired network is considered a management burden, then I would argue that Split MAC increases manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:00 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt This really depends on how you define MANAGEABILITY. If the decrease in signaling message is counted as increase in managemeability, it is = obivous that that moving the whole MAC to AC will simplify the protocol messages used between AC and AP (at least less messags). cheers Cheng -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 11:55 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Could I perhaps ask you to provide me with concrete data that proves = this is the case? I have plenty of data that proves that the centralized = approach provides much better manageability. However, there is nothing in my data that shows that where some of the finer components of the MAC terminate increase (or decrease) manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the = AC. Thus, the manageability will be better. But, of course the centralization also brings other issues, and = therefore the degree of split should be a trade off result of different aspects. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I do = not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------=_NextPart_000_0015_01C46929.C44E06C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 don't object the idea of provide more explanation about the issue at = all. Your=20 reasoning of the edge filtering might serve as the example=20 there.
 
But=20 also one point to note is the difference between the manageability of = the AP and=20 the network. The filtering function to be place at the edge (AP) could = improve=20 the network manageability, but may descrease the manageability of the AP = (function) itself.
 
cheers
 
Cheng=20 Hong
-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of=20 Pat R. Calhoun
Sent: Tuesday, July 13, 2004 1:04=20 PM
To: Cheng Hong; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

The one round trip "burden" of pushing a rule dow to = the AP is=20 minuscule in comparison with opening up the floodgates for all traffic = to be=20 sent to the AC.

I agree that wired networks have higher = bandwidth than=20 the wireless network, but I would wonder how many IT managers would be = pleased=20 to know that their wired network investment is being used to = potentially carry=20 unauthorized traffic because their wireless solution's APs cannot = provide any=20 form of traffic policing.

The advantage of Split MAC is that = the AP is=20 being told what it should and shouldn't allow onto the wired network, = and if=20 encryption is done on the AP, it will even eliminate invalid (perhaps=20 malicious) traffic from cluttering the wired network. This enables the = AP to=20 protect the AC's resources, further guaranteeing a well behaved = wireless=20 system.

Anyhow, the original point behind this whole thread was = that I=20 disagreed with the statement in the document that stated that remote = MAC was=20 more manageable than split MAC. If we can kill that sentence (or at = least=20 provide some concrete data proving this is true), then I will more = than gladly=20 get off my soap box.

PatC
-----Original = Message-----
From: Cheng=20 Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 9:24 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Well. That is a valid point. But = would=20 that be equally a burden with the
split MAC where you need to put = in extra=20 efforts to manage the filter and
the encryption at the edge?  = And,=20 with a proper network design (not
management), we don't need to = care about=20 the "burden" of traffic considering
that the wireless has much = lower=20 bandwidth offered than the wired=20 network.

cheers


-----Original Message-----
From: = Pat R.=20 Calhoun [mailto:pcalhoun@airespace.com]=
Sent:=20 Tuesday, July 13, 2004 12:14 PM
To: Cheng Hong; = sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt



But I would equally argue = that a=20 remote MAC causes *all* traffic to traverse
the network from the AP = to the=20 AC (because the AP is really dumb). One of
the benefits of Split = MAC is=20 that you have the ability to "protect" network
resources by being = able to=20 apply specific filters at the edge. For example,
if you have an = encrypted=20 channel, and you are capable of decrypting packets
at the edge, you = would=20 further protect the network by ensuring that only
properly = encrypted=20 packets enter the wired network.

So if unnecessary burden of = the wired=20 network is considered a management
burden, then I would argue that = Split=20 MAC increases manageability.

PatC
-----Original=20 Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 9:00 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

This really depends on how you = define=20 MANAGEABILITY. If the decrease in
signaling message is counted as = increase=20 in managemeability, it is obivous
that that moving the whole MAC to = AC will=20 simplify the protocol messages
used between AC and AP (at least = less=20 messags).

cheers

Cheng

-----Original=20 Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent:=20 Tuesday, July 13, 2004 11:55 AM
To: Cheng Hong; = sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt



Could I perhaps ask you = to=20 provide me with concrete data that proves this is
the case? I have = plenty=20 of data that proves that the centralized approach
provides much = better=20 manageability. However, there is nothing in my data
that shows that = where=20 some of the finer components of the MAC terminate
increase (or = decrease)=20 manageability.

PatC


-----Original = Message-----
From:=20 Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

As for the remote vs split, when = we apply=20 the same logic here, when the
degree of centralization increases, = more info=20 will be available at the AC.
Thus, the manageability will be=20 better.

But, of course the centralization also brings other = issues, and=20 therefore
the degree of split should be a trade off result of = different=20 aspects.

cheers

Cheng Hong

-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 = AM
To:=20 Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: = [Capwap]=20 Comments on draft-ietf-capwap-arch-03.txt



I'm obviously = not=20 arguing that centralization is better... my point was that
the = sentence=20 that remote vs. split provides better manageability. I do not
agree = with=20 that sentence, and the document also does not provide = any
supporting data=20 to prove the point.

PatC
-----Original Message-----
From: = Cheng=20 Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point = is that=20 with a centralized arch. you have more information
about the = network, i.e.=20 at the centralized controller you have a overall
view of the = network=20 instead of just the AP point of view. Therefore, more
"value added" = service=20 could be provided. One simple example is that the SME
could make = better=20 decisions with info from several AP.


cheers

Cheng=20 Hong




-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 = AM
To:=20 sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] = Comments on=20 draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could = the=20 authors please explain how they came to the
conclusion that Remote = MAC=20 "improves
> WTP manageability"?

If I can proffer an = explanation;=20 the characteristics of Remote MAC
follow from those of the Split = MAC=20 architecture. The Split MAC improves
manageability over basic = autonomous=20 WTPs by centralizing some control
aspects; Remote MAC goes further = by=20 centralizing 'all' aspects of the
MAC. So the entire MAC processing = is=20 consolidated while the WTPs become
extremely light=20 devices.

<PRC> But one of the "advantages" of a = centralized=20 architecture, is that the
WTP look like "local interfaces", and are = managed=20 as such. Whether one
implements
remote or split MAC does not = really=20 change how one would manage such a
network -
so it's really down = to=20 implementation details.

<PRC> So as a consequence I = disagree with=20 the assumption (and statement)
made
in the=20 = document

PatC












<= BR>



------=_NextPart_000_0015_01C46929.C44E06C0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 13 12:22:15 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21651 for ; Tue, 13 Jul 2004 12:22:14 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 372A121052; Tue, 13 Jul 2004 12:07:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B3AA920538; Tue, 13 Jul 2004 12:07:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D62732077D for ; Tue, 13 Jul 2004 12:06:34 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 8ECC920525 for ; Tue, 13 Jul 2004 12:06:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C468F5.B85CF4AD" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C40C0@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt thread-index: AcRo5xrJUxPtdpYVTGSADnJyUp2NFQADar1A From: "Pat R. Calhoun" To: "Cheng Hong" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 13 Jul 2004 09:23:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C468F5.B85CF4AD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So I think what this thread validates is that there is no clear data to = prove that the sentence stating that remote MAC is more manageable - so I'd like to kill this = thread and ask the authors=20 of the document to remove the sentence. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Tue 7/13/2004 7:35 AM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =20 I don't object the idea of provide more explanation about the issue at = all. Your reasoning of the edge filtering might serve as the example there. =20 But also one point to note is the difference between the manageability = of the AP and the network. The filtering function to be place at the edge = (AP) could improve the network manageability, but may descrease the = manageability of the AP (function) itself. =20 cheers =20 Cheng Hong=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 1:04 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt The one round trip "burden" of pushing a rule dow to the AP is minuscule = in comparison with opening up the floodgates for all traffic to be sent to = the AC. I agree that wired networks have higher bandwidth than the wireless = network, but I would wonder how many IT managers would be pleased to know that = their wired network investment is being used to potentially carry unauthorized traffic because their wireless solution's APs cannot provide any form of traffic policing. The advantage of Split MAC is that the AP is being told what it should = and shouldn't allow onto the wired network, and if encryption is done on the = AP, it will even eliminate invalid (perhaps malicious) traffic from = cluttering the wired network. This enables the AP to protect the AC's resources, further guaranteeing a well behaved wireless system. Anyhow, the original point behind this whole thread was that I disagreed with the statement in the document that stated that remote MAC was more manageable than split MAC. If we can kill that sentence (or at least = provide some concrete data proving this is true), then I will more than gladly = get off my soap box. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:24 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Well. That is a valid point. But would that be equally a burden with the split MAC where you need to put in extra efforts to manage the filter = and the encryption at the edge? And, with a proper network design (not management), we don't need to care about the "burden" of traffic = considering that the wireless has much lower bandwidth offered than the wired = network. cheers -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 12:14 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt But I would equally argue that a remote MAC causes *all* traffic to = traverse the network from the AP to the AC (because the AP is really dumb). One = of the benefits of Split MAC is that you have the ability to "protect" = network resources by being able to apply specific filters at the edge. For = example, if you have an encrypted channel, and you are capable of decrypting = packets at the edge, you would further protect the network by ensuring that only properly encrypted packets enter the wired network. So if unnecessary burden of the wired network is considered a management burden, then I would argue that Split MAC increases manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:00 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt This really depends on how you define MANAGEABILITY. If the decrease in signaling message is counted as increase in managemeability, it is = obivous that that moving the whole MAC to AC will simplify the protocol messages used between AC and AP (at least less messags). cheers Cheng -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 11:55 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Could I perhaps ask you to provide me with concrete data that proves = this is the case? I have plenty of data that proves that the centralized = approach provides much better manageability. However, there is nothing in my data that shows that where some of the finer components of the MAC terminate increase (or decrease) manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the = AC. Thus, the manageability will be better. But, of course the centralization also brings other issues, and = therefore the degree of split should be a trade off result of different aspects. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was = that the sentence that remote vs. split provides better manageability. I do = not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more = information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, = more "value added" service could be provided. One simple example is that the = SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that = the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------_=_NextPart_001_01C468F5.B85CF4AD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

So I think what this thread validates is that there is = no clear data to prove that the sentence
stating that remote MAC is more manageable - so I'd like to kill this = thread and ask the authors
of the document to remove the sentence.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Tue 7/13/2004 7:35 AM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

I don't object the idea of provide more explanation about the issue at = all.
Your reasoning of the edge filtering might serve as the example = there.

But also one point to note is the difference between the manageability = of
the AP and the network. The filtering function to be place at the edge = (AP)
could improve the network manageability, but may descrease the = manageability
of the AP (function) itself.

cheers

Cheng Hong

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 1:04 PM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



The one round trip "burden" of pushing a rule dow to the AP is = minuscule in
comparison with opening up the floodgates for all traffic to be sent to = the
AC.

I agree that wired networks have higher bandwidth than the wireless = network,
but I would wonder how many IT managers would be pleased to know that = their
wired network investment is being used to potentially carry = unauthorized
traffic because their wireless solution's APs cannot provide any form = of
traffic policing.

The advantage of Split MAC is that the AP is being told what it should = and
shouldn't allow onto the wired network, and if encryption is done on the = AP,
it will even eliminate invalid (perhaps malicious) traffic from = cluttering
the wired network. This enables the AP to protect the AC's = resources,
further guaranteeing a well behaved wireless system.

Anyhow, the original point behind this whole thread was that I = disagreed
with the statement in the document that stated that remote MAC was = more
manageable than split MAC. If we can kill that sentence (or at least = provide
some concrete data proving this is true), then I will more than gladly = get
off my soap box.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 9:24 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Well. That is a valid point. But would that be equally a burden with = the
split MAC where you need to put in extra efforts to manage the filter = and
the encryption at the edge?  And, with a proper network design = (not
management), we don't need to care about the "burden" of = traffic considering
that the wireless has much lower bandwidth offered than the wired = network.

cheers


-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent: Tuesday, July 13, 2004 12:14 PM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



But I would equally argue that a remote MAC causes *all* traffic to = traverse
the network from the AP to the AC (because the AP is really dumb). One = of
the benefits of Split MAC is that you have the ability to = "protect" network
resources by being able to apply specific filters at the edge. For = example,
if you have an encrypted channel, and you are capable of decrypting = packets
at the edge, you would further protect the network by ensuring that = only
properly encrypted packets enter the wired network.

So if unnecessary burden of the wired network is considered a = management
burden, then I would argue that Split MAC increases manageability.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 9:00 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

This really depends on how you define MANAGEABILITY. If the decrease = in
signaling message is counted as increase in managemeability, it is = obivous
that that moving the whole MAC to AC will simplify the protocol = messages
used between AC and AP (at least less messags).

cheers

Cheng

-----Original Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent: Tuesday, July 13, 2004 11:55 AM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



Could I perhaps ask you to provide me with concrete data that proves = this is
the case? I have plenty of data that proves that the centralized = approach
provides much better manageability. However, there is nothing in my = data
that shows that where some of the finer components of the MAC = terminate
increase (or decrease) manageability.

PatC


-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

As for the remote vs split, when we apply the same logic here, when = the
degree of centralization increases, more info will be available at the = AC.
Thus, the manageability will be better.

But, of course the centralization also brings other issues, and = therefore
the degree of split should be a trade off result of different = aspects.

cheers

Cheng Hong

-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 AM
To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt



I'm obviously not arguing that centralization is better... my point was = that
the sentence that remote vs. split provides better manageability. I do = not
agree with that sentence, and the document also does not provide any
supporting data to prove the point.

PatC
-----Original Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: Mon 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point is that with a centralized arch. you have more = information
about the network, i.e. at the centralized controller you have a = overall
view of the network instead of just the AP point of view. Therefore, = more
"value added" service could be provided. One simple example is = that the SME
could make better decisions with info from several AP.


cheers

Cheng Hong




-----Original Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 AM
To: sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could the authors please explain how they came to = the
conclusion that Remote MAC "improves
> WTP manageability"?

If I can proffer an explanation; the characteristics of Remote MAC
follow from those of the Split MAC architecture. The Split MAC = improves
manageability over basic autonomous WTPs by centralizing some = control
aspects; Remote MAC goes further by centralizing 'all' aspects of = the
MAC. So the entire MAC processing is consolidated while the WTPs = become
extremely light devices.

<PRC> But one of the "advantages" of a centralized = architecture, is that the
WTP look like "local interfaces", and are managed as such. = Whether one
implements
remote or split MAC does not really change how one would manage such = a
network -
so it's really down to implementation details.

<PRC> So as a consequence I disagree with the assumption (and = statement)
made
in the document

PatC

------_=_NextPart_001_01C468F5.B85CF4AD-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 16 21:44:18 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26427 for ; Fri, 16 Jul 2004 21:44:17 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9ABD31FEFB; Fri, 16 Jul 2004 21:30:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 199D3214AB; Fri, 16 Jul 2004 21:30:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D6A6214AB for ; Fri, 16 Jul 2004 21:29:54 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id BA4B81FEFB for ; Fri, 16 Jul 2004 21:29:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46B9F.85AC1396" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Thread-Index: AcRo5xrJUxPtdpYVTGSADnJyUp2NFQADar1AAKm8MNAAAATHwA== From: "Randy Chou" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 16 Jul 2004 18:43:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C46B9F.85AC1396 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, jumping into the thread a bit late. Some comments to add to the discussion...I don't believe there's justification of removal of a manageability statement based on its security implication. If there is a flaw in the security, then the flaw needs to be fixed. In this case however, the security implication itself has not gone through thorough analysis either and I don't agree with some of the conclusions implied. =20 First, the manageability side...Clearly the less state there is to transmit between different devices, the easier it is to manage. So the statement in current draft is correct IMO. =20 Now moving to the security implications which I believe should be a different discussion... =20 > I agree that wired networks have higher bandwidth than the wireless network, but I would wonder how many IT managers would be pleased to know that their wired network investment is being used to potentially carry unauthorized traffic because their wireless solution's APs cannot provide any form of traffic policing. >The advantage of Split MAC is that the AP is being told what it should and shouldn't allow onto the wired network, and if encryption is done on the AP, it will even eliminate invalid (perhaps malicious) traffic from cluttering the wired network. This enables the AP to protect the AC's resources, further guaranteeing a well behaved wireless system. =20 Traffic policing can be done in many ways. In this case, even if the AP can do encryption, it cannot firewall everything as it will not have all the possible keys for all the types of authentication and encryption in a wireless network. There's also a security weakness in keeping the keys at the AP itself, but I'll leave that discussion for another day. =20 =20 WEP for example has no replay counters and hence the AP does not have enough information and the wired network can be flooded with or without the encryption being done on the AP itself. So the AP wouldn't be able to protect even simple data. With more sophisticated encryption such as AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by the backend radius and so the AP does not have enough information to protect either. In other networks, VPN over wireless is required and so unless the AP is doing L3 encryption, this wouldn't work either. I'm sure I've left other possible flood attacks out. So with strong or weak encryption, flooding is possible and needs to be addressed in a different way (firewall'd). But we're going off on a different tangent and I'd also be advertising a feature rather than discussing the merits of the draft itself ;). =20 Regards, =20 -- Randy =20 =20 =20 =20 =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 9:23 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =20 So I think what this thread validates is that there is no clear data to prove that the sentence stating that remote MAC is more manageable - so I'd like to kill this thread and ask the authors of the document to remove the sentence. =09 PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Tue 7/13/2004 7:35 AM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 I don't object the idea of provide more explanation about the issue at all. Your reasoning of the edge filtering might serve as the example there. =09 But also one point to note is the difference between the manageability of the AP and the network. The filtering function to be place at the edge (AP) could improve the network manageability, but may descrease the manageability of the AP (function) itself. =09 cheers =09 Cheng Hong =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 1:04 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 =09 =09 The one round trip "burden" of pushing a rule dow to the AP is minuscule in comparison with opening up the floodgates for all traffic to be sent to the AC. =09 I agree that wired networks have higher bandwidth than the wireless network, but I would wonder how many IT managers would be pleased to know that their wired network investment is being used to potentially carry unauthorized traffic because their wireless solution's APs cannot provide any form of traffic policing. =09 The advantage of Split MAC is that the AP is being told what it should and shouldn't allow onto the wired network, and if encryption is done on the AP, it will even eliminate invalid (perhaps malicious) traffic from cluttering the wired network. This enables the AP to protect the AC's resources, further guaranteeing a well behaved wireless system. =09 Anyhow, the original point behind this whole thread was that I disagreed with the statement in the document that stated that remote MAC was more manageable than split MAC. If we can kill that sentence (or at least provide some concrete data proving this is true), then I will more than gladly get off my soap box. =09 PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:24 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 Well. That is a valid point. But would that be equally a burden with the split MAC where you need to put in extra efforts to manage the filter and the encryption at the edge? And, with a proper network design (not management), we don't need to care about the "burden" of traffic considering that the wireless has much lower bandwidth offered than the wired network. =09 cheers =09 =09 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 12:14 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 =09 =09 But I would equally argue that a remote MAC causes *all* traffic to traverse the network from the AP to the AC (because the AP is really dumb). One of the benefits of Split MAC is that you have the ability to "protect" network resources by being able to apply specific filters at the edge. For example, if you have an encrypted channel, and you are capable of decrypting packets at the edge, you would further protect the network by ensuring that only properly encrypted packets enter the wired network. =09 So if unnecessary burden of the wired network is considered a management burden, then I would argue that Split MAC increases manageability. =09 PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:00 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 This really depends on how you define MANAGEABILITY. If the decrease in signaling message is counted as increase in managemeability, it is obivous that that moving the whole MAC to AC will simplify the protocol messages used between AC and AP (at least less messags). =09 cheers =09 Cheng =09 -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 11:55 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 =09 =09 Could I perhaps ask you to provide me with concrete data that proves this is the case? I have plenty of data that proves that the centralized approach provides much better manageability. However, there is nothing in my data that shows that where some of the finer components of the MAC terminate increase (or decrease) manageability. =09 PatC =09 =09 -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the AC. Thus, the manageability will be better. =09 But, of course the centralization also brings other issues, and therefore the degree of split should be a trade off result of different aspects. =09 cheers =09 Cheng Hong =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 =09 =09 I'm obviously not arguing that centralization is better... my point was that the sentence that remote vs. split provides better manageability. I do not agree with that sentence, and the document also does not provide any supporting data to prove the point. =09 PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 Hi Pat, =09 I think the point is that with a centralized arch. you have more information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, more "value added" service could be provided. One simple example is that the SME could make better decisions with info from several AP. =09 =09 cheers =09 Cheng Hong =09 =09 =09 =09 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =09 =09 > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? =09 If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. =09 But one of the "advantages" of a centralized architecture, is that the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. =09 So as a consequence I disagree with the assumption (and statement) made in the document =09 PatC =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01C46B9F.85AC1396 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Sorry, jumping into the = thread a=20 bit late.  Some comments to add to the discussion...I don't believe = there's=20 justification of removal of a manageability statement based on its = security=20 implication.  If there is a flaw in the security, then the flaw = needs to be=20 fixed.  In this case however, the security implication itself has = not gone=20 through thorough analysis either and I don't agree with some of the=20 conclusions implied.
 
First, the = manageability=20 side...Clearly the less state there is to transmit between different = devices,=20 the easier it is to manage.  So the statement in current draft is = correct=20 IMO.
 
Now moving to the = security=20 implications which I believe should be a different=20 discussion...
 
> I agree=20 that wired networks have higher bandwidth than the wireless = network,
but I=20 would wonder how many IT managers would be pleased to know that = their
wired=20 network investment is being used to potentially carry = unauthorized
traffic=20 because their wireless solution's APs cannot provide any form = of
traffic=20 policing.
>The=20 advantage of Split MAC is that the AP is being told what it should=20 and
shouldn't allow onto the wired network, and if encryption is done = on the=20 AP,
it will even eliminate invalid (perhaps malicious) traffic from=20 cluttering
the wired network. This enables the AP to protect the AC's = resources,
further guaranteeing a well behaved wireless=20 system.
 
Traffic policing can be = done in=20 many ways.  In this case, even if the AP can do encryption, it=20 cannot firewall everything as it will not have all the = possible keys=20 for all the types of authentication and encryption in a wireless = network. =20 There's also a security weakness in keeping the keys at the AP itself, = but I'll=20 leave that discussion for another day. 
 
WEP for example has no = replay=20 counters and hence the AP does not have enough information and the wired = network=20 can be flooded with or without the encryption being done on the AP = itself. =20 So the AP wouldn't be able to protect even simple data.  With more=20 sophisticated encryption such as AES-CCMP (802.11i) and assuming dot1x, = EAP=20 packets are authenticated by the backend radius and so the AP does not = have=20 enough information to protect either.   In other networks, VPN = over=20 wireless is required and so unless the AP is doing L3 encryption, this = wouldn't=20 work either.  I'm sure I've left other possible flood attacks = out.  So=20 with strong or weak encryption, flooding is possible and needs to be = addressed=20 in a different way (firewall'd).  But we're going off on a = different=20 tangent and I'd also be advertising a feature rather than discussing the = merits=20 of the draft itself ;).
 
Regards,
 
--
Randy
 
 
 
 

 

-----Original=20 Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. = Calhoun
Sent: Tuesday, July 13, 2004 = 9:23=20 AM
To: Cheng Hong;=20 sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] Comments = on=20 draft-ietf-capwap-arch-03.txt

 

So I think what this thread validates is = that there is=20 no clear data to prove that the sentence
stating that remote MAC is = more=20 manageable - so I'd like to kill this thread and ask the authors
of = the=20 document to remove the sentence.

PatC
-----Original=20 Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Tue=20 7/13/2004 7:35 AM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

I don't object the idea of = provide more=20 explanation about the issue at all.
Your reasoning of the edge = filtering=20 might serve as the example there.

But also one point to note is = the=20 difference between the manageability of
the AP and the network. The = filtering function to be place at the edge (AP)
could improve the = network=20 manageability, but may descrease the manageability
of the AP = (function)=20 itself.

cheers

Cheng Hong

-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 1:04 = PM
To:=20 Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: = [Capwap]=20 Comments on draft-ietf-capwap-arch-03.txt



The one round = trip=20 "burden" of pushing a rule dow to the AP is minuscule in
comparison = with=20 opening up the floodgates for all traffic to be sent to = the
AC.

I=20 agree that wired networks have higher bandwidth than the wireless=20 network,
but I would wonder how many IT managers would be pleased = to know=20 that their
wired network investment is being used to potentially = carry=20 unauthorized
traffic because their wireless solution's APs cannot = provide=20 any form of
traffic policing.

The advantage of Split MAC is = that the=20 AP is being told what it should and
shouldn't allow onto the wired = network,=20 and if encryption is done on the AP,
it will even eliminate invalid = (perhaps malicious) traffic from cluttering
the wired network. This = enables=20 the AP to protect the AC's resources,
further guaranteeing a well = behaved=20 wireless system.

Anyhow, the original point behind this whole = thread=20 was that I disagreed
with the statement in the document that stated = that=20 remote MAC was more
manageable than split MAC. If we can kill that = sentence=20 (or at least provide
some concrete data proving this is true), then = I will=20 more than gladly get
off my soap box.

PatC
-----Original=20 Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 9:24 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Well. That is a valid point. But = would=20 that be equally a burden with the
split MAC where you need to put = in extra=20 efforts to manage the filter and
the encryption at the edge?  = And,=20 with a proper network design (not
management), we don't need to = care about=20 the "burden" of traffic considering
that the wireless has much = lower=20 bandwidth offered than the wired=20 network.

cheers


-----Original Message-----
From: = Pat R.=20 Calhoun [mailto:pcalhoun@airespace.com]=
Sent:=20 Tuesday, July 13, 2004 12:14 PM
To: Cheng Hong; = sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt



But I would equally argue = that a=20 remote MAC causes *all* traffic to traverse
the network from the AP = to the=20 AC (because the AP is really dumb). One of
the benefits of Split = MAC is=20 that you have the ability to "protect" network
resources by being = able to=20 apply specific filters at the edge. For example,
if you have an = encrypted=20 channel, and you are capable of decrypting packets
at the edge, you = would=20 further protect the network by ensuring that only
properly = encrypted=20 packets enter the wired network.

So if unnecessary burden of = the wired=20 network is considered a management
burden, then I would argue that = Split=20 MAC increases manageability.

PatC
-----Original=20 Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 9:00 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

This really depends on how you = define=20 MANAGEABILITY. If the decrease in
signaling message is counted as = increase=20 in managemeability, it is obivous
that that moving the whole MAC to = AC will=20 simplify the protocol messages
used between AC and AP (at least = less=20 messags).

cheers

Cheng

-----Original=20 Message-----
From: Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent:=20 Tuesday, July 13, 2004 11:55 AM
To: Cheng Hong; = sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt



Could I perhaps ask you = to=20 provide me with concrete data that proves this is
the case? I have = plenty=20 of data that proves that the centralized approach
provides much = better=20 manageability. However, there is nothing in my data
that shows that = where=20 some of the finer components of the MAC terminate
increase (or = decrease)=20 manageability.

PatC


-----Original = Message-----
From:=20 Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

As for the remote vs split, when = we apply=20 the same logic here, when the
degree of centralization increases, = more info=20 will be available at the AC.
Thus, the manageability will be=20 better.

But, of course the centralization also brings other = issues, and=20 therefore
the degree of split should be a trade off result of = different=20 aspects.

cheers

Cheng Hong

-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 = AM
To:=20 Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: = [Capwap]=20 Comments on draft-ietf-capwap-arch-03.txt



I'm obviously = not=20 arguing that centralization is better... my point was that
the = sentence=20 that remote vs. split provides better manageability. I do not
agree = with=20 that sentence, and the document also does not provide = any
supporting data=20 to prove the point.

PatC
-----Original Message-----
From: = Cheng=20 Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point = is that=20 with a centralized arch. you have more information
about the = network, i.e.=20 at the centralized controller you have a overall
view of the = network=20 instead of just the AP point of view. Therefore, more
"value added" = service=20 could be provided. One simple example is that the SME
could make = better=20 decisions with info from several AP.


cheers

Cheng=20 Hong




-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m]=20 On Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 = AM
To:=20 sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] = Comments on=20 draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could = the=20 authors please explain how they came to the
conclusion that Remote = MAC=20 "improves
> WTP manageability"?

If I can proffer an = explanation;=20 the characteristics of Remote MAC
follow from those of the Split = MAC=20 architecture. The Split MAC improves
manageability over basic = autonomous=20 WTPs by centralizing some control
aspects; Remote MAC goes further = by=20 centralizing 'all' aspects of the
MAC. So the entire MAC processing = is=20 consolidated while the WTPs become
extremely light=20 devices.

<PRC> But one of the "advantages" of a = centralized=20 architecture, is that the
WTP look like "local interfaces", and are = managed=20 as such. Whether one
implements
remote or split MAC does not = really=20 change how one would manage such a
network -
so it's really down = to=20 implementation details.

<PRC> So as a consequence I = disagree with=20 the assumption (and statement)
made
in the=20 = document

PatC












<= BR>






=00 ------_=_NextPart_001_01C46B9F.85AC1396-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Jul 18 15:20:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28126 for ; Sun, 18 Jul 2004 15:20:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 943C421085; Sun, 18 Jul 2004 15:06:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 543D721627; Sun, 18 Jul 2004 15:06:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60CD721627 for ; Sun, 18 Jul 2004 15:05:26 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 7C5B321085 for ; Sun, 18 Jul 2004 15:05:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46CFC.88560215" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C4201@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Thread-Index: AcRo5xrJUxPtdpYVTGSADnJyUp2NFQADar1AAKm8MNAAAATHwABX+5rz From: "Pat R. Calhoun" To: "Randy Chou" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 18 Jul 2004 12:22:14 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C46CFC.88560215 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, jumping into the thread a bit late. Some comments to add to the = discussion...I don't believe there's justification of removal of a = manageability statement based on its security implication. If there is = a flaw in the security, then the flaw needs to be fixed. In this case = however, the security implication itself has not gone through thorough = analysis either and I don't agree with some of the conclusions implied. =20 First, the manageability side...Clearly the less state there is to = transmit between different devices, the easier it is to manage. So the = statement in current draft is correct IMO. Since you started by implying that you had multiple points to = make, perhaps you'd like to also include those? I have made counter = arguments that no one else has been able to refute, so at this point the = justification made in favor of this sentence seems to be about as good = as my mother's old argument "because I said so".=20 Traffic policing can be done in many ways. In this case, even if the AP = can do encryption, it cannot firewall everything as it will not have all = the possible keys for all the types of authentication and encryption in = a wireless network. There's also a security weakness in keeping the = keys at the AP itself, but I'll leave that discussion for another day. =20 Can you say apples and oranges? The definition of an AP does not = even include a firewall function, so trying to introduce this now is = irrelevant (unless you plan to introduce a firewall as part of the = IEEE's definition of an AP). Hell at that point why don't we also = include a web server, traffic shaper, etc. =20 WEP for example has no replay counters [ed: trimmed unnecessary text] The use of WEP and security in the same sentence is contradictory. = PatC ------_=_NextPart_001_01C46CFC.88560215 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

Sorry, jumping into the thread a bit late.  Some = comments to add to the discussion...I don't believe there's = justification of removal of a manageability statement based on its = security implication.  If there is a flaw in the security, then the = flaw needs to be fixed.  In this case however, the security = implication itself has not gone through thorough analysis either and I = don't agree with some of the conclusions implied.

First, the manageability side...Clearly the less state there is to = transmit between different devices, the easier it is to manage.  So = the statement in current draft is correct IMO.

<PRC> Since you started by implying that you had multiple points = to make, perhaps you'd like to also include those? I have made counter = arguments that no one else has been able to refute, so at this point the = justification made in favor of this sentence seems to be about as good = as my mother's old argument "because I said so".

Traffic policing can be done in many ways.  In this case, even if = the AP can do encryption, it cannot firewall everything as it will not = have all the possible keys for all the types of authentication and = encryption in a wireless network.  There's also a security weakness = in keeping the keys at the AP itself, but I'll leave that discussion for = another day. 

<PRC> Can you say apples and oranges? The definition of an AP does = not even include a firewall function, so trying to introduce this now is = irrelevant (unless you plan to introduce a firewall as part of the = IEEE's definition of an AP). Hell at that point why don't we also = include a web server, traffic shaper, etc.

WEP for example has no replay counters [ed: trimmed unnecessary = text]

<PRC> The use of WEP and security in the same sentence is = contradictory.

PatC

------_=_NextPart_001_01C46CFC.88560215-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 02:38:27 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17780 for ; Mon, 19 Jul 2004 02:38:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FC6521100; Mon, 19 Jul 2004 02:24:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE012216B8; Mon, 19 Jul 2004 02:24:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12B17216B3 for ; Mon, 19 Jul 2004 02:23:04 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id B214121100 for ; Mon, 19 Jul 2004 02:23:01 -0400 (EDT) Received: from FATCAT ([10.202.10.126]) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 18 Jul 2004 23:37:08 -0700 From: "Randy Chou" To: Cc: Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C46D20.BFEB5AB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 19 Jul 2004 06:37:08.0273 (UTC) FILETIME=[D051EA10:01C46D5A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 18 Jul 2004 23:41:29 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C46D20.BFEB5AB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Interesting how you cut most of my points out, then ask me where they are. I've included the thread again for reference below... >>First, the manageability side...Clearly the less state there is to transmit between different devices, the easier it is to manage. So the statement in current draft is correct IMO. > Since you started by implying that you had multiple points to make, perhaps you'd like to also include those? I have made counter arguments that no one else has been able to refute, so at this point the justification made in favor of this sentence seems to be about as good as my mother's old argument "because I said so". I'm beginning to understand why most choose not to reply to your posts. My statement is self-evident. We're not getting anywhere discussing it further when it comes to manageability and I'd certainly like to keep your mother out of this discussion. Your security statement I refuted (which you also conveniently cut out) was a misconception I heard elsewhere too and wanted to correct it...The idea that handling encryption at the AP can prevent flooding the wired network. Because the authentication portion of 802.11i is based on 802.1x, and the keys for 802.1x (TLS portion) reside on the authentication server, the AP cannot prevent EAP flooding. So flooding must be prevented in other ways which I've already mentioned below... The use of WEP and security in the same sentence is contradictory. Again you chose to cut out what I said. I mentioned both WEP and AES-CCM where flooding can occur to point out that it is irrelevant what encryption is used. On a slightly more humorous note...searching on google for "wep security airespace", the first hit yields: "Specifically, the Airespace security framework supports the following layers of security protocols and ... action • Layer 2 – WEP, WPA, 802.1x" And I'm the one with contradictory statements??? Sigh... Regards, -- Randy -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of Pat R. Calhoun Sent: Sunday, July 18, 2004 12:22 PM To: Randy Chou; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Sorry, jumping into the thread a bit late. Some comments to add to the discussion...I don't believe there's justification of removal of a manageability statement based on its security implication. If there is a flaw in the security, then the flaw needs to be fixed. In this case however, the security implication itself has not gone through thorough analysis either and I don't agree with some of the conclusions implied. First, the manageability side...Clearly the less state there is to transmit between different devices, the easier it is to manage. So the statement in current draft is correct IMO. Since you started by implying that you had multiple points to make, perhaps you'd like to also include those? I have made counter arguments that no one else has been able to refute, so at this point the justification made in favor of this sentence seems to be about as good as my mother's old argument "because I said so". Traffic policing can be done in many ways. In this case, even if the AP can do encryption, it cannot firewall everything as it will not have all the possible keys for all the types of authentication and encryption in a wireless network. There's also a security weakness in keeping the keys at the AP itself, but I'll leave that discussion for another day. Can you say apples and oranges? The definition of an AP does not even include a firewall function, so trying to introduce this now is irrelevant (unless you plan to introduce a firewall as part of the IEEE's definition of an AP). Hell at that point why don't we also include a web server, traffic shaper, etc. WEP for example has no replay counters [ed: trimmed unnecessary text] The use of WEP and security in the same sentence is contradictory. PatC -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of Randy Chou Sent: Friday, July 16, 2004 6:44 PM To: capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Sorry, jumping into the thread a bit late. Some comments to add to the discussion...I don't believe there's justification of removal of a manageability statement based on its security implication. If there is a flaw in the security, then the flaw needs to be fixed. In this case however, the security implication itself has not gone through thorough analysis either and I don't agree with some of the conclusions implied. First, the manageability side...Clearly the less state there is to transmit between different devices, the easier it is to manage. So the statement in current draft is correct IMO. Now moving to the security implications which I believe should be a different discussion... > I agree that wired networks have higher bandwidth than the wireless network, but I would wonder how many IT managers would be pleased to know that their wired network investment is being used to potentially carry unauthorized traffic because their wireless solution's APs cannot provide any form of traffic policing. >The advantage of Split MAC is that the AP is being told what it should and shouldn't allow onto the wired network, and if encryption is done on the AP, it will even eliminate invalid (perhaps malicious) traffic from cluttering the wired network. This enables the AP to protect the AC's resources, further guaranteeing a well behaved wireless system. Traffic policing can be done in many ways. In this case, even if the AP can do encryption, it cannot firewall everything as it will not have all the possible keys for all the types of authentication and encryption in a wireless network. There's also a security weakness in keeping the keys at the AP itself, but I'll leave that discussion for another day. WEP for example has no replay counters and hence the AP does not have enough information and the wired network can be flooded with or without the encryption being done on the AP itself. So the AP wouldn't be able to protect even simple data. With more sophisticated encryption such as AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by the backend radius and so the AP does not have enough information to protect either. In other networks, VPN over wireless is required and so unless the AP is doing L3 encryption, this wouldn't work either. I'm sure I've left other possible flood attacks out. So with strong or weak encryption, flooding is possible and needs to be addressed in a different way (firewall'd). But we're going off on a different tangent and I'd also be advertising a feature rather than discussing the merits of the draft itself ;). Regards, -- Randy -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 9:23 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt So I think what this thread validates is that there is no clear data to prove that the sentence stating that remote MAC is more manageable - so I'd like to kill this thread and ask the authors of the document to remove the sentence. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Tue 7/13/2004 7:35 AM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I don't object the idea of provide more explanation about the issue at all. Your reasoning of the edge filtering might serve as the example there. But also one point to note is the difference between the manageability of the AP and the network. The filtering function to be place at the edge (AP) could improve the network manageability, but may descrease the manageability of the AP (function) itself. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 1:04 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt The one round trip "burden" of pushing a rule dow to the AP is minuscule in comparison with opening up the floodgates for all traffic to be sent to the AC. I agree that wired networks have higher bandwidth than the wireless network, but I would wonder how many IT managers would be pleased to know that their wired network investment is being used to potentially carry unauthorized traffic because their wireless solution's APs cannot provide any form of traffic policing. The advantage of Split MAC is that the AP is being told what it should and shouldn't allow onto the wired network, and if encryption is done on the AP, it will even eliminate invalid (perhaps malicious) traffic from cluttering the wired network. This enables the AP to protect the AC's resources, further guaranteeing a well behaved wireless system. Anyhow, the original point behind this whole thread was that I disagreed with the statement in the document that stated that remote MAC was more manageable than split MAC. If we can kill that sentence (or at least provide some concrete data proving this is true), then I will more than gladly get off my soap box. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:24 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Well. That is a valid point. But would that be equally a burden with the split MAC where you need to put in extra efforts to manage the filter and the encryption at the edge? And, with a proper network design (not management), we don't need to care about the "burden" of traffic considering that the wireless has much lower bandwidth offered than the wired network. cheers -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 12:14 PM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt But I would equally argue that a remote MAC causes *all* traffic to traverse the network from the AP to the AC (because the AP is really dumb). One of the benefits of Split MAC is that you have the ability to "protect" network resources by being able to apply specific filters at the edge. For example, if you have an encrypted channel, and you are capable of decrypting packets at the edge, you would further protect the network by ensuring that only properly encrypted packets enter the wired network. So if unnecessary burden of the wired network is considered a management burden, then I would argue that Split MAC increases manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 9:00 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt This really depends on how you define MANAGEABILITY. If the decrease in signaling message is counted as increase in managemeability, it is obivous that that moving the whole MAC to AC will simplify the protocol messages used between AC and AP (at least less messags). cheers Cheng -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Tuesday, July 13, 2004 11:55 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Could I perhaps ask you to provide me with concrete data that proves this is the case? I have plenty of data that proves that the centralized approach provides much better manageability. However, there is nothing in my data that shows that where some of the finer components of the MAC terminate increase (or decrease) manageability. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:50 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt As for the remote vs split, when we apply the same logic here, when the degree of centralization increases, more info will be available at the AC. Thus, the manageability will be better. But, of course the centralization also brings other issues, and therefore the degree of split should be a trade off result of different aspects. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 11:35 AM To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm obviously not arguing that centralization is better... my point was that the sentence that remote vs. split provides better manageability. I do not agree with that sentence, and the document also does not provide any supporting data to prove the point. PatC -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg] Sent: Mon 7/12/2004 8:28 PM To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Hi Pat, I think the point is that with a centralized arch. you have more information about the network, i.e. at the centralized controller you have a overall view of the network instead of just the AP point of view. Therefore, more "value added" service could be provided. One simple example is that the SME could make better decisions with info from several AP. cheers Cheng Hong -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, July 13, 2004 10:29 AM To: sgovindan@psl.com.sg; capwap@frascone.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves > WTP manageability"? If I can proffer an explanation; the characteristics of Remote MAC follow from those of the Split MAC architecture. The Split MAC improves manageability over basic autonomous WTPs by centralizing some control aspects; Remote MAC goes further by centralizing 'all' aspects of the MAC. So the entire MAC processing is consolidated while the WTPs become extremely light devices. But one of the "advantages" of a centralized architecture, is that the WTP look like "local interfaces", and are managed as such. Whether one implements remote or split MAC does not really change how one would manage such a network - so it's really down to implementation details. So as a consequence I disagree with the assumption (and statement) made in the document PatC ------=_NextPart_000_0002_01C46D20.BFEB5AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Interesting = how you cut most=20 of my points out, then ask me where they are.  I've = included the=20 thread again for reference below...
 
>>First, the manageability side...Clearly the = less state=20 there is to transmit between different devices, the easier it is to=20 manage.  So the statement in current draft is correct=20 IMO.
><PRC> Since you started by implying that you had = multiple=20 points to make, perhaps you'd like to also include those? I have made = counter=20 arguments that no one else has been able to refute, so at this point the = justification made in favor of this sentence seems to be about as good = as my=20 mother's old argument "because I said so".
I'm beginning to = understand why most=20 choose not to reply to your posts.  My statement is = self-evident. =20 We're not getting anywhere discussing it further when it comes to = manageability=20 and I'd certainly like to keep your mother out of this = discussion.
 
Your security statement = I refuted=20 (which you also conveniently cut out) was a misconception I heard = elsewhere too=20 and wanted to correct it...The idea that handling encryption at the AP = can=20 prevent flooding the wired network.  Because the authentication = portion of=20 802.11i is based on 802.1x, and the keys for 802.1x (TLS portion) reside = on the=20 authentication server, the AP cannot prevent EAP flooding.  So = flooding=20 must be prevented in other ways which I've already mentioned=20 below...
 
<PRC> The use of WEP and security in the same sentence is = contradictory.
 
Again you chose to cut = out what I=20 said.  I mentioned both WEP and AES-CCM where flooding can occur to = point=20 out that it is irrelevant what encryption is used.
 
On a slightly more = humorous=20 note...searching on google for "wep security airespace", the=20 first hit yields:
 
"Specifically, the = Airespace=20 security framework supports the following layers of = security=20 protocols and ... action =95 Layer 2 =96 WEP, WPA,=20 802.1x"
 
And I'm the one = with=20 contradictory statements???  Sigh...
 
Regards,
 
--
Randy
 
 
 
-----Original Message-----
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com]On Behalf Of Pat R.=20 Calhoun
Sent: Sunday, July 18, 2004 12:22 PM
To: = Randy=20 Chou; capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Sorry, jumping into the thread a bit late.  = Some comments=20 to add to the discussion...I don't believe there's justification of = removal of=20 a manageability statement based on its security implication.  If = there is=20 a flaw in the security, then the flaw needs to be fixed.  In this = case=20 however, the security implication itself has not gone through thorough = analysis either and I don't agree with some of the conclusions=20 implied.

First, the manageability side...Clearly the less state = there=20 is to transmit between different devices, the easier it is to = manage.  So=20 the statement in current draft is correct IMO.

<PRC> = Since you=20 started by implying that you had multiple points to make, perhaps = you'd like=20 to also include those? I have made counter arguments that no one else = has been=20 able to refute, so at this point the justification made in favor of = this=20 sentence seems to be about as good as my mother's old argument = "because I said=20 so".

Traffic policing can be done in many ways.  In this = case,=20 even if the AP can do encryption, it cannot firewall everything as it = will not=20 have all the possible keys for all the types of authentication and = encryption=20 in a wireless network.  There's also a security weakness in = keeping the=20 keys at the AP itself, but I'll leave that discussion for another=20 day. 

<PRC> Can you say apples and oranges? The = definition=20 of an AP does not even include a firewall function, so trying to = introduce=20 this now is irrelevant (unless you plan to introduce a firewall as = part of the=20 IEEE's definition of an AP). Hell at that point why don't we also = include a=20 web server, traffic shaper, etc.

WEP for example has no replay = counters=20 [ed: trimmed unnecessary text]

<PRC> The use of WEP and = security=20 in the same sentence is contradictory.

PatC=20



-----Original Message-----
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.co= m]On
Behalf=20 Of Randy Chou
Sent: Friday, July 16, 2004 6:44 PM
To:=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt


Sorry, jumping into the thread = a bit=20 late.  Some comments to add to the discussion...I don't believe = there's=20 justification of removal of a manageability statement based on its = security=20 implication.  If there is a flaw in the security, then the flaw = needs to be=20 fixed.  In this case however, the security implication itself has = not gone=20 through thorough analysis either and I don't agree with some of the = conclusions=20 implied.

First, the manageability side...Clearly the less state = there is=20 to transmit between different devices, the easier it is to manage.  = So the=20 statement in current draft is correct IMO.

Now moving to the = security=20 implications which I believe should be a different = discussion...

> I=20 agree that wired networks have higher bandwidth than the wireless=20 network,
but I would wonder how many IT managers would be pleased to = know=20 that their
wired network investment is being used to potentially = carry=20 unauthorized
traffic because their wireless solution's APs cannot = provide any=20 form of
traffic policing.

>The advantage of Split MAC is = that the=20 AP is being told what it should and
shouldn't allow onto the wired = network,=20 and if encryption is done on the AP,
it will even eliminate invalid = (perhaps=20 malicious) traffic from cluttering
the wired network. This enables = the AP to=20 protect the AC's resources,
further guaranteeing a well behaved = wireless=20 system.


Traffic policing can be done in many ways.  In = this=20 case, even if the AP can do encryption, it cannot firewall everything as = it will=20 not have all the possible keys for all the types of authentication and=20 encryption in a wireless network.  There's also a security weakness = in=20 keeping the keys at the AP itself, but I'll leave that discussion for = another=20 day. 

WEP for example has no replay counters and hence the = AP does=20 not have enough information and the wired network can be flooded with or = without=20 the encryption being done on the AP itself.  So the AP wouldn't be = able to=20 protect even simple data.  With more sophisticated encryption such = as=20 AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by = the=20 backend radius and so the AP does not have enough information to protect = either.   In other networks, VPN over wireless is required and = so=20 unless the AP is doing L3 encryption, this wouldn't work either.  = I'm sure=20 I've left other possible flood attacks out.  So with strong or weak = encryption, flooding is possible and needs to be addressed in a = different way=20 (firewall'd).  But we're going off on a different tangent and I'd = also be=20 advertising a feature rather than discussing the merits of the draft = itself=20 ;).

Regards,

--
Randy







---= --Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On=20 Behalf Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 9:23 AM
To: = Cheng=20 Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] = Comments on draft-ietf-capwap-arch-03.txt



So I think what = this=20 thread validates is that there is no clear data to prove that the=20 sentence
stating that remote MAC is more manageable - so I'd like to = kill=20 this thread and ask the authors
of the document to remove the=20 sentence.

PatC
-----Original Message-----
From: Cheng Hong = [mailto:hcheng@psl.com.sg]
Sent: = Tue=20 7/13/2004 7:35 AM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

I don't object the idea of provide = more=20 explanation about the issue at all.
Your reasoning of the edge = filtering=20 might serve as the example there.

But also one point to note is = the=20 difference between the manageability of
the AP and the network. The = filtering=20 function to be place at the edge (AP)
could improve the network=20 manageability, but may descrease the manageability
of the AP = (function)=20 itself.

cheers

Cheng Hong

-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On=20 Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 1:04 = PM
To: Cheng=20 Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] = Comments on draft-ietf-capwap-arch-03.txt



The one round = trip=20 "burden" of pushing a rule dow to the AP is minuscule in
comparison = with=20 opening up the floodgates for all traffic to be sent to = the
AC.

I=20 agree that wired networks have higher bandwidth than the wireless=20 network,
but I would wonder how many IT managers would be pleased to = know=20 that their
wired network investment is being used to potentially = carry=20 unauthorized
traffic because their wireless solution's APs cannot = provide any=20 form of
traffic policing.

The advantage of Split MAC is that = the AP is=20 being told what it should and
shouldn't allow onto the wired network, = and if=20 encryption is done on the AP,
it will even eliminate invalid (perhaps = malicious) traffic from cluttering
the wired network. This enables = the AP to=20 protect the AC's resources,
further guaranteeing a well behaved = wireless=20 system.

Anyhow, the original point behind this whole thread was = that I=20 disagreed
with the statement in the document that stated that remote = MAC was=20 more
manageable than split MAC. If we can kill that sentence (or at = least=20 provide
some concrete data proving this is true), then I will more = than=20 gladly get
off my soap box.

PatC
-----Original=20 Message-----
From: Cheng Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 9:24 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Well. That is a valid point. But = would that=20 be equally a burden with the
split MAC where you need to put in extra = efforts=20 to manage the filter and
the encryption at the edge?  And, with = a proper=20 network design (not
management), we don't need to care about the = "burden" of=20 traffic considering
that the wireless has much lower bandwidth = offered than=20 the wired network.

cheers


-----Original = Message-----
From:=20 Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent:=20 Tuesday, July 13, 2004 12:14 PM
To: Cheng Hong; sgovindan@psl.com.sg; = capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt



But I would equally argue = that a=20 remote MAC causes *all* traffic to traverse
the network from the AP = to the AC=20 (because the AP is really dumb). One of
the benefits of Split MAC is = that you=20 have the ability to "protect" network
resources by being able to = apply=20 specific filters at the edge. For example,
if you have an encrypted = channel,=20 and you are capable of decrypting packets
at the edge, you would = further=20 protect the network by ensuring that only
properly encrypted packets = enter=20 the wired network.

So if unnecessary burden of the wired network = is=20 considered a management
burden, then I would argue that Split MAC = increases=20 manageability.

PatC
-----Original Message-----
From: Cheng = Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 9:00 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

This really depends on how you = define=20 MANAGEABILITY. If the decrease in
signaling message is counted as = increase in=20 managemeability, it is obivous
that that moving the whole MAC to AC = will=20 simplify the protocol messages
used between AC and AP (at least less=20 messags).

cheers

Cheng

-----Original = Message-----
From:=20 Pat R. Calhoun [mailto:pcalhoun@airespace.com]=
Sent:=20 Tuesday, July 13, 2004 11:55 AM
To: Cheng Hong; sgovindan@psl.com.sg; = capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt



Could I perhaps ask you to = provide=20 me with concrete data that proves this is
the case? I have plenty of = data=20 that proves that the centralized approach
provides much better = manageability.=20 However, there is nothing in my data
that shows that where some of = the finer=20 components of the MAC terminate
increase (or decrease)=20 manageability.

PatC


-----Original = Message-----
From: Cheng=20 Hong [mailto:hcheng@psl.com.sg]
Sent: = Mon 7/12/2004 8:50 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

As for the remote vs split, when we = apply=20 the same logic here, when the
degree of centralization increases, = more info=20 will be available at the AC.
Thus, the manageability will be=20 better.

But, of course the centralization also brings other = issues, and=20 therefore
the degree of split should be a trade off result of = different=20 aspects.

cheers

Cheng Hong

-----Original=20 Message-----
From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On=20 Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 11:35 = AM
To:=20 Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: = [Capwap]=20 Comments on draft-ietf-capwap-arch-03.txt



I'm obviously = not=20 arguing that centralization is better... my point was that
the = sentence that=20 remote vs. split provides better manageability. I do not
agree with = that=20 sentence, and the document also does not provide any
supporting data = to prove=20 the point.

PatC
-----Original Message-----
From: Cheng Hong = [mailto:hcheng@psl.com.sg]
Sent: = Mon=20 7/12/2004 8:28 PM
To: Pat R. Calhoun; sgovindan@psl.com.sg;=20 capwap@frascone.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

Hi Pat,

I think the point is = that=20 with a centralized arch. you have more information
about the network, = i.e. at=20 the centralized controller you have a overall
view of the network = instead of=20 just the AP point of view. Therefore, more
"value added" service = could be=20 provided. One simple example is that the SME
could make better = decisions with=20 info from several AP.


cheers

Cheng=20 Hong




-----Original Message-----
From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.co= m] On=20 Behalf
Of Pat R. Calhoun
Sent: Tuesday, July 13, 2004 10:29 = AM
To:=20 sgovindan@psl.com.sg; capwap@frascone.com
Subject: RE: [Capwap] = Comments on=20 draft-ietf-capwap-arch-03.txt


> 7. Section 4.5. Could the = authors=20 please explain how they came to the
conclusion that Remote MAC=20 "improves
> WTP manageability"?

If I can proffer an = explanation;=20 the characteristics of Remote MAC
follow from those of the Split MAC=20 architecture. The Split MAC improves
manageability over basic = autonomous WTPs=20 by centralizing some control
aspects; Remote MAC goes further by = centralizing=20 'all' aspects of the
MAC. So the entire MAC processing is = consolidated while=20 the WTPs become
extremely light devices.

<PRC> But one = of the=20 "advantages" of a centralized architecture, is that the
WTP look like = "local=20 interfaces", and are managed as such. Whether = one
implements
remote or=20 split MAC does not really change how one would manage such a
network = -
so=20 it's really down to implementation details.

<PRC> So as a=20 consequence I disagree with the assumption (and statement)
made
in = the=20 document

PatC












<= BR>








------=_NextPart_000_0002_01C46D20.BFEB5AB0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 08:52:24 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12416 for ; Mon, 19 Jul 2004 08:52:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 993542174D; Mon, 19 Jul 2004 08:38:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3165821748; Mon, 19 Jul 2004 08:38:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3118A21748 for ; Mon, 19 Jul 2004 08:37:18 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 28A0D21746 for ; Mon, 19 Jul 2004 08:37:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46D8F.81F709B6" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <55749BC69138654EBBC4C50BA4F55610020C4212@AIREMAIL.airespace.com> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Thread-Index: AcRtW2qBmW4jDM7bR1ySqPTxc0EHVgAMu3/z From: "Pat R. Calhoun" To: "Randy Chou" , Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 05:54:20 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C46D8F.81F709B6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm beginning to understand why most choose not to reply to your posts. = My statement is self-evident. We're not getting anywhere discussing it = further when it comes to manageability and I'd certainly like to keep = your mother out of this discussion. Then may I introduce you to my aunt ;-) =20 Your security statement I refuted (which you also conveniently cut out) = was a misconception I heard elsewhere too and wanted to correct it...The = idea that handling encryption at the AP can prevent flooding the wired = network. Because the authentication portion of 802.11i is based on = 802.1x, and the keys for 802.1x (TLS portion) reside on the = authentication server, the AP cannot prevent EAP flooding. So flooding = must be prevented in other ways which I've already mentioned below... hmmmm.... you really have me confused here. Certainly the client's = credentials are on the AS, but the PMK and the PTK aren't. Therefore the = questions really is whether it is possible to decrypt the packets in the = AP or not. I would state that pushing the PTK into the AP (not in = permanent storage) makes plenty of sense as it allows the AP to at least = discard invalid packets. As far as authenticating 802.1x packets = (because they are not authenticated), there are other methods,such as = rate limiting, etc. =20 Again you chose to cut out what I said. I mentioned both WEP and = AES-CCM where flooding can occur to point out that it is irrelevant what = encryption is used. I apologize for removing the text, but it really didn't address = the point. In any case, you seem to imply that encryption cannot be done = in the AP, or that a system must be designed for WEP (not sure which = one). I think that one should not assume that either one of these points = is true. =20 On a slightly more humorous note...searching on google for "wep security = airespace", the first hit yields: =20 "Specifically, the Airespace security framework supports the following = layers of security protocols and ... action * Layer 2 - WEP, WPA, = 802.1x" =20 Indeed, that is rather humurous - but keep in mind that this is a = marketing brochure and IT buyers have a check list that very often = includes items that will not (or should not) be used. How many times = have I seen that famous RFP come in with some April Fool's RFC on it. = That said, what I was *trying* to say is that we should not be designing = the system for WEP, but for TKIP and AES-CCM. =20 So we can keep this thread alive or agree to disagree. In either = case, there is no clear evidence that the original statement was valid. = You have an opinion, I have my own. =20 PatC ------_=_NextPart_001_01C46D8F.81F709B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
I'm beginning = to understand =0A= why most choose not to reply to your posts.  My statement is =0A= self-evident.  We're not getting anywhere discussing it further = when it =0A= comes to manageability and I'd certainly like to keep your mother out of = this =0A= discussion.
=0A=
=0A=
<PRC> Then may I = introduce you =0A= to my aunt ;-)
=0A=
 
=0A=
Your security statement = I refuted =0A= (which you also conveniently cut out) was a misconception I heard = elsewhere too =0A= and wanted to correct it...The idea that handling encryption at the AP = can =0A= prevent flooding the wired network.  Because the authentication = portion of =0A= 802.11i is based on 802.1x, and the keys for 802.1x (TLS portion) reside = on the =0A= authentication server, the AP cannot prevent EAP flooding.  So = flooding =0A= must be prevented in other ways which I've already mentioned =0A= below...
=0A=
<PRC> hmmmm.... = you really have =0A= me confused here. Certainly the client's credentials are on the AS, but = the PMK =0A= and the PTK aren't. Therefore the questions really is whether it is = possible to =0A= decrypt the packets in the AP or not. I would state that pushing the PTK = into =0A= the AP (not in permanent storage) makes plenty of sense as it allows the = AP to =0A= at least discard invalid packets. As far as authenticating 802.1x = packets =0A= (because they are not authenticated), there are other methods,such as = rate =0A= limiting, etc.
=0A=
 
=0A=
Again you chose to cut = out what I =0A= said.  I mentioned both WEP and AES-CCM where flooding can occur to = point =0A= out that it is irrelevant what encryption is used.
=0A=
<PRC> I apologize = for removing =0A= the text, but it really didn't address the point. In any case, you seem = to imply =0A= that encryption cannot be done in the AP, or that a system must be = designed for =0A= WEP (not sure which one). I think that one should not assume that either = one of =0A= these points is true.
=0A=
 
=0A=
On a slightly more = humorous =0A= note...searching on google for "wep security airespace", the =0A= first hit yields:
=0A=
 
=0A=
"Specifically, the = Airespace =0A= security framework supports the following layers of = security =0A= protocols and ... action • Layer 2 – WEP, WPA, =0A= 802.1x"
=0A=
 
=0A=
<PRC> Indeed, that is rather humurous - = but keep in =0A= mind that this is a marketing brochure and IT buyers have a check list = that very =0A= often includes items that will not (or should not) be used. How many = times have =0A= I seen that famous RFP come in with some April Fool's RFC on it. That = said, what =0A= I was *trying* to say is that we should not be designing the system for = WEP, but =0A= for TKIP and AES-CCM.
=0A=
 
=0A=
<PRC> So we can keep this thread alive or = agree to =0A= disagree. In either case, there is no clear evidence that the original = statement =0A= was valid. You have an opinion, I have my own.
=0A=
 
=0A=
PatC
------_=_NextPart_001_01C46D8F.81F709B6-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 12:00:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00222 for ; Mon, 19 Jul 2004 12:00:19 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BE3F4205D9; Mon, 19 Jul 2004 11:46:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05A94208B6; Mon, 19 Jul 2004 11:46:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3279C2083A for ; Mon, 19 Jul 2004 11:45:50 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 6CF99205D9 for ; Mon, 19 Jul 2004 11:45:47 -0400 (EDT) Message-ID: <00f601c46da9$8ccd9380$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Randy Chou" , Cc: References: Subject: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 09:00:43 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Gentlemen, (At the risk of getting beat up by both sides...)IETF is for people with competing technical ideas to come to concensus for the purpose of providing interoperability, something that has time and again proven valuable to customers of networking equipment (like my current employer). Scoring points about why one's technical vision is better than one's competitor, or bashing one's competitor's product offering is, in my opinion, somewhat inconsistent with this goal. There's obviously a difference of opinion here about where to locate state and how that impacts ease of managability. Barring some real hard data about managability for different products (which I would highly encourage both sides to seek through some neutral third party), there's probably no way to objectively assess the two sides of this argument. Therefore, as an attempt at concensus, I'd suggest modifying the statement to say something like the following: The exact balance of centralized v.s. decentralized state and its impact on managability for CAPWAP architectures such as Split MAC and Remote MAC is currently a matter of dispute within the technical community. Sound reasonable? jak ----- Original Message ----- From: "Randy Chou" To: Cc: Sent: Sunday, July 18, 2004 11:41 PM Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > Interesting how you cut most of my points out, then ask me where they are. > I've included the thread again for reference below... > > >>First, the manageability side...Clearly the less state there is to > transmit between different devices, the easier it is to manage. So the > statement in current draft is correct IMO. > > Since you started by implying that you had multiple points to make, > perhaps you'd like to also include those? I have made counter arguments that > no one else has been able to refute, so at this point the justification made > in favor of this sentence seems to be about as good as my mother's old > argument "because I said so". > > I'm beginning to understand why most choose not to reply to your posts. My > statement is self-evident. We're not getting anywhere discussing it further > when it comes to manageability and I'd certainly like to keep your mother > out of this discussion. > > Your security statement I refuted (which you also conveniently cut out) was > a misconception I heard elsewhere too and wanted to correct it...The idea > that handling encryption at the AP can prevent flooding the wired network. > Because the authentication portion of 802.11i is based on 802.1x, and the > keys for 802.1x (TLS portion) reside on the authentication server, the AP > cannot prevent EAP flooding. So flooding must be prevented in other ways > which I've already mentioned below... > > The use of WEP and security in the same sentence is contradictory. > > > Again you chose to cut out what I said. I mentioned both WEP and AES-CCM > where flooding can occur to point out that it is irrelevant what encryption > is used. > > On a slightly more humorous note...searching on google for "wep security > airespace", the first hit yields: > > "Specifically, the Airespace security framework supports the following > layers of security protocols and ... action . Layer 2 - WEP, WPA, 802.1x" > > And I'm the one with contradictory statements??? Sigh... > > Regards, > > -- > Randy > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of Pat R. Calhoun > Sent: Sunday, July 18, 2004 12:22 PM > To: Randy Chou; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > Sorry, jumping into the thread a bit late. Some comments to add to the > discussion...I don't believe there's justification of removal of a > manageability statement based on its security implication. If there is a > flaw in the security, then the flaw needs to be fixed. In this case > however, the security implication itself has not gone through thorough > analysis either and I don't agree with some of the conclusions implied. > > First, the manageability side...Clearly the less state there is to > transmit between different devices, the easier it is to manage. So the > statement in current draft is correct IMO. > > Since you started by implying that you had multiple points to make, > perhaps you'd like to also include those? I have made counter arguments that > no one else has been able to refute, so at this point the justification made > in favor of this sentence seems to be about as good as my mother's old > argument "because I said so". > > Traffic policing can be done in many ways. In this case, even if the AP > can do encryption, it cannot firewall everything as it will not have all the > possible keys for all the types of authentication and encryption in a > wireless network. There's also a security weakness in keeping the keys at > the AP itself, but I'll leave that discussion for another day. > > Can you say apples and oranges? The definition of an AP does not > even include a firewall function, so trying to introduce this now is > irrelevant (unless you plan to introduce a firewall as part of the IEEE's > definition of an AP). Hell at that point why don't we also include a web > server, traffic shaper, etc. > > WEP for example has no replay counters [ed: trimmed unnecessary text] > > The use of WEP and security in the same sentence is contradictory. > > PatC > > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of Randy Chou > Sent: Friday, July 16, 2004 6:44 PM > To: capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > Sorry, jumping into the thread a bit late. Some comments to add to the > discussion...I don't believe there's justification of removal of a > manageability statement based on its security implication. If there is a > flaw in the security, then the flaw needs to be fixed. In this case > however, the security implication itself has not gone through thorough > analysis either and I don't agree with some of the conclusions implied. > > First, the manageability side...Clearly the less state there is to transmit > between different devices, the easier it is to manage. So the statement in > current draft is correct IMO. > > Now moving to the security implications which I believe should be a > different discussion... > > > I agree that wired networks have higher bandwidth than the wireless > network, > but I would wonder how many IT managers would be pleased to know that their > wired network investment is being used to potentially carry unauthorized > traffic because their wireless solution's APs cannot provide any form of > traffic policing. > > >The advantage of Split MAC is that the AP is being told what it should and > shouldn't allow onto the wired network, and if encryption is done on the AP, > it will even eliminate invalid (perhaps malicious) traffic from cluttering > the wired network. This enables the AP to protect the AC's resources, > further guaranteeing a well behaved wireless system. > > > Traffic policing can be done in many ways. In this case, even if the AP can > do encryption, it cannot firewall everything as it will not have all the > possible keys for all the types of authentication and encryption in a > wireless network. There's also a security weakness in keeping the keys at > the AP itself, but I'll leave that discussion for another day. > > WEP for example has no replay counters and hence the AP does not have enough > information and the wired network can be flooded with or without the > encryption being done on the AP itself. So the AP wouldn't be able to > protect even simple data. With more sophisticated encryption such as > AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by the > backend radius and so the AP does not have enough information to protect > either. In other networks, VPN over wireless is required and so unless the > AP is doing L3 encryption, this wouldn't work either. I'm sure I've left > other possible flood attacks out. So with strong or weak encryption, > flooding is possible and needs to be addressed in a different way > (firewall'd). But we're going off on a different tangent and I'd also be > advertising a feature rather than discussing the merits of the draft itself > ;). > > Regards, > > -- > Randy > > > > > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Pat R. Calhoun > Sent: Tuesday, July 13, 2004 9:23 AM > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > So I think what this thread validates is that there is no clear data to > prove that the sentence > stating that remote MAC is more manageable - so I'd like to kill this thread > and ask the authors > of the document to remove the sentence. > > PatC > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Tue 7/13/2004 7:35 AM > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > I don't object the idea of provide more explanation about the issue at all. > Your reasoning of the edge filtering might serve as the example there. > > But also one point to note is the difference between the manageability of > the AP and the network. The filtering function to be place at the edge (AP) > could improve the network manageability, but may descrease the manageability > of the AP (function) itself. > > cheers > > Cheng Hong > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Pat R. Calhoun > Sent: Tuesday, July 13, 2004 1:04 PM > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > The one round trip "burden" of pushing a rule dow to the AP is minuscule in > comparison with opening up the floodgates for all traffic to be sent to the > AC. > > I agree that wired networks have higher bandwidth than the wireless network, > but I would wonder how many IT managers would be pleased to know that their > wired network investment is being used to potentially carry unauthorized > traffic because their wireless solution's APs cannot provide any form of > traffic policing. > > The advantage of Split MAC is that the AP is being told what it should and > shouldn't allow onto the wired network, and if encryption is done on the AP, > it will even eliminate invalid (perhaps malicious) traffic from cluttering > the wired network. This enables the AP to protect the AC's resources, > further guaranteeing a well behaved wireless system. > > Anyhow, the original point behind this whole thread was that I disagreed > with the statement in the document that stated that remote MAC was more > manageable than split MAC. If we can kill that sentence (or at least provide > some concrete data proving this is true), then I will more than gladly get > off my soap box. > > PatC > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Mon 7/12/2004 9:24 PM > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > Well. That is a valid point. But would that be equally a burden with the > split MAC where you need to put in extra efforts to manage the filter and > the encryption at the edge? And, with a proper network design (not > management), we don't need to care about the "burden" of traffic considering > that the wireless has much lower bandwidth offered than the wired network. > > cheers > > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Tuesday, July 13, 2004 12:14 PM > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > But I would equally argue that a remote MAC causes *all* traffic to traverse > the network from the AP to the AC (because the AP is really dumb). One of > the benefits of Split MAC is that you have the ability to "protect" network > resources by being able to apply specific filters at the edge. For example, > if you have an encrypted channel, and you are capable of decrypting packets > at the edge, you would further protect the network by ensuring that only > properly encrypted packets enter the wired network. > > So if unnecessary burden of the wired network is considered a management > burden, then I would argue that Split MAC increases manageability. > > PatC > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Mon 7/12/2004 9:00 PM > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > This really depends on how you define MANAGEABILITY. If the decrease in > signaling message is counted as increase in managemeability, it is obivous > that that moving the whole MAC to AC will simplify the protocol messages > used between AC and AP (at least less messags). > > cheers > > Cheng > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Tuesday, July 13, 2004 11:55 AM > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > Could I perhaps ask you to provide me with concrete data that proves this is > the case? I have plenty of data that proves that the centralized approach > provides much better manageability. However, there is nothing in my data > that shows that where some of the finer components of the MAC terminate > increase (or decrease) manageability. > > PatC > > > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Mon 7/12/2004 8:50 PM > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > As for the remote vs split, when we apply the same logic here, when the > degree of centralization increases, more info will be available at the AC. > Thus, the manageability will be better. > > But, of course the centralization also brings other issues, and therefore > the degree of split should be a trade off result of different aspects. > > cheers > > Cheng Hong > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Pat R. Calhoun > Sent: Tuesday, July 13, 2004 11:35 AM > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > I'm obviously not arguing that centralization is better... my point was that > the sentence that remote vs. split provides better manageability. I do not > agree with that sentence, and the document also does not provide any > supporting data to prove the point. > > PatC > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg] > Sent: Mon 7/12/2004 8:28 PM > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > Hi Pat, > > I think the point is that with a centralized arch. you have more information > about the network, i.e. at the centralized controller you have a overall > view of the network instead of just the AP point of view. Therefore, more > "value added" service could be provided. One simple example is that the SME > could make better decisions with info from several AP. > > > cheers > > Cheng Hong > > > > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Pat R. Calhoun > Sent: Tuesday, July 13, 2004 10:29 AM > To: sgovindan@psl.com.sg; capwap@frascone.com > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > 7. Section 4.5. Could the authors please explain how they came to the > conclusion that Remote MAC "improves > > WTP manageability"? > > If I can proffer an explanation; the characteristics of Remote MAC > follow from those of the Split MAC architecture. The Split MAC improves > manageability over basic autonomous WTPs by centralizing some control > aspects; Remote MAC goes further by centralizing 'all' aspects of the > MAC. So the entire MAC processing is consolidated while the WTPs become > extremely light devices. > > But one of the "advantages" of a centralized architecture, is that the > WTP look like "local interfaces", and are managed as such. Whether one > implements > remote or split MAC does not really change how one would manage such a > network - > so it's really down to implementation details. > > So as a consequence I disagree with the assumption (and statement) > made > in the document > > PatC > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 13:10:55 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06913 for ; Mon, 19 Jul 2004 13:10:54 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53E5620827; Mon, 19 Jul 2004 12:53:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 677802036E; Mon, 19 Jul 2004 12:53:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB94F2065C for ; Mon, 19 Jul 2004 12:52:42 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id B320E20623 for ; Mon, 19 Jul 2004 12:52:39 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.12.6/8.12.6) with ESMTP id i6JH79rw033740; Mon, 19 Jul 2004 10:07:09 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200407191707.i6JH79rw033740@homebrew.trpz.com> To: "James Kempf" Cc: "Randy Chou" , capwap@frascone.com Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) In-Reply-To: Your message of "Mon, 19 Jul 2004 09:00:43 PDT." <00f601c46da9$8ccd9380$536115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33738.1090256829.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 10:07:09 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) That is certainly one view of the IETF, sadly it is more of a nostalgic one. Another view is that the IETF is a place to submit a (portion of a) proprietary scheme or protocol with the desire to place the official imprimatur of the IETF upon it and to then claim compliance to a "standard". When the points being made include marketing speak (e.g. "[the AP] cannot firewall (sic) everything as it will not have all possible keys (sic)") I think it's obvious which IETF this is. Also, you mentioned your current employer valuing the output of the nostalgic IETF, but your current employer has already made up its mind regarding the issue at hand without waiting for "competing technical ideas to come to concensus." Dan. On Mon, 19 Jul 2004 09:00:43 PDT you wrote > Gentlemen, > > (At the risk of getting beat up by both sides...)IETF is for people with > competing technical ideas to come to concensus for the purpose of providing > interoperability, something that has time and again proven valuable to > customers of networking equipment (like my current employer). Scoring points > about why one's technical vision is better than one's competitor, or bashing > one's competitor's product offering is, in my opinion, somewhat inconsistent > with this goal. > > There's obviously a difference of opinion here about where to locate state > and how that impacts ease of managability. Barring some real hard data about > managability for different products (which I would highly encourage both > sides to seek through some neutral third party), there's probably no way to > objectively assess the two sides of this argument. > > Therefore, as an attempt at concensus, I'd suggest modifying the statement > to say something like the following: > > The exact balance of centralized v.s. decentralized state and its impact > on managability for CAPWAP architectures such as Split MAC and > Remote MAC is currently a matter of dispute > within the technical community. > > Sound reasonable? > > jak > > > > ----- Original Message ----- > From: "Randy Chou" > To: > Cc: > Sent: Sunday, July 18, 2004 11:41 PM > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > Interesting how you cut most of my points out, then ask me where they are. > > I've included the thread again for reference below... > > > > >>First, the manageability side...Clearly the less state there is to > > transmit between different devices, the easier it is to manage. So the > > statement in current draft is correct IMO. > > > Since you started by implying that you had multiple points to make, > > perhaps you'd like to also include those? I have made counter arguments > that > > no one else has been able to refute, so at this point the justification > made > > in favor of this sentence seems to be about as good as my mother's old > > argument "because I said so". > > > > I'm beginning to understand why most choose not to reply to your posts. > My > > statement is self-evident. We're not getting anywhere discussing it > further > > when it comes to manageability and I'd certainly like to keep your mother > > out of this discussion. > > > > Your security statement I refuted (which you also conveniently cut out) > was > > a misconception I heard elsewhere too and wanted to correct it...The idea > > that handling encryption at the AP can prevent flooding the wired network. > > Because the authentication portion of 802.11i is based on 802.1x, and the > > keys for 802.1x (TLS portion) reside on the authentication server, the AP > > cannot prevent EAP flooding. So flooding must be prevented in other ways > > which I've already mentioned below... > > > > The use of WEP and security in the same sentence is contradictory. > > > > > > Again you chose to cut out what I said. I mentioned both WEP and AES-CCM > > where flooding can occur to point out that it is irrelevant what > encryption > > is used. > > > > On a slightly more humorous note...searching on google for "wep security > > airespace", the first hit yields: > > > > "Specifically, the Airespace security framework supports the following > > layers of security protocols and ... action . Layer 2 - WEP, WPA, 802.1x" > > > > And I'm the one with contradictory statements??? Sigh... > > > > Regards, > > > > -- > > Randy > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of Pat R. Calhoun > > Sent: Sunday, July 18, 2004 12:22 PM > > To: Randy Chou; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > Sorry, jumping into the thread a bit late. Some comments to add to the > > discussion...I don't believe there's justification of removal of a > > manageability statement based on its security implication. If there is a > > flaw in the security, then the flaw needs to be fixed. In this case > > however, the security implication itself has not gone through thorough > > analysis either and I don't agree with some of the conclusions implied. > > > > First, the manageability side...Clearly the less state there is to > > transmit between different devices, the easier it is to manage. So the > > statement in current draft is correct IMO. > > > > Since you started by implying that you had multiple points to > make, > > perhaps you'd like to also include those? I have made counter arguments > that > > no one else has been able to refute, so at this point the justification > made > > in favor of this sentence seems to be about as good as my mother's old > > argument "because I said so". > > > > Traffic policing can be done in many ways. In this case, even if the AP > > can do encryption, it cannot firewall everything as it will not have all > the > > possible keys for all the types of authentication and encryption in a > > wireless network. There's also a security weakness in keeping the keys at > > the AP itself, but I'll leave that discussion for another day. > > > > Can you say apples and oranges? The definition of an AP does not > > even include a firewall function, so trying to introduce this now is > > irrelevant (unless you plan to introduce a firewall as part of the IEEE's > > definition of an AP). Hell at that point why don't we also include a web > > server, traffic shaper, etc. > > > > WEP for example has no replay counters [ed: trimmed unnecessary text] > > > > The use of WEP and security in the same sentence is contradictory. > > > > PatC > > > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > Behalf Of Randy Chou > > Sent: Friday, July 16, 2004 6:44 PM > > To: capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > Sorry, jumping into the thread a bit late. Some comments to add to the > > discussion...I don't believe there's justification of removal of a > > manageability statement based on its security implication. If there is a > > flaw in the security, then the flaw needs to be fixed. In this case > > however, the security implication itself has not gone through thorough > > analysis either and I don't agree with some of the conclusions implied. > > > > First, the manageability side...Clearly the less state there is to > transmit > > between different devices, the easier it is to manage. So the statement > in > > current draft is correct IMO. > > > > Now moving to the security implications which I believe should be a > > different discussion... > > > > > I agree that wired networks have higher bandwidth than the wireless > > network, > > but I would wonder how many IT managers would be pleased to know that > their > > wired network investment is being used to potentially carry unauthorized > > traffic because their wireless solution's APs cannot provide any form of > > traffic policing. > > > > >The advantage of Split MAC is that the AP is being told what it should > and > > shouldn't allow onto the wired network, and if encryption is done on the > AP, > > it will even eliminate invalid (perhaps malicious) traffic from cluttering > > the wired network. This enables the AP to protect the AC's resources, > > further guaranteeing a well behaved wireless system. > > > > > > Traffic policing can be done in many ways. In this case, even if the AP > can > > do encryption, it cannot firewall everything as it will not have all the > > possible keys for all the types of authentication and encryption in a > > wireless network. There's also a security weakness in keeping the keys at > > the AP itself, but I'll leave that discussion for another day. > > > > WEP for example has no replay counters and hence the AP does not have > enough > > information and the wired network can be flooded with or without the > > encryption being done on the AP itself. So the AP wouldn't be able to > > protect even simple data. With more sophisticated encryption such as > > AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by > the > > backend radius and so the AP does not have enough information to protect > > either. In other networks, VPN over wireless is required and so unless > the > > AP is doing L3 encryption, this wouldn't work either. I'm sure I've left > > other possible flood attacks out. So with strong or weak encryption, > > flooding is possible and needs to be addressed in a different way > > (firewall'd). But we're going off on a different tangent and I'd also be > > advertising a feature rather than discussing the merits of the draft > itself > > ;). > > > > Regards, > > > > -- > > Randy > > > > > > > > > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > > Of Pat R. Calhoun > > Sent: Tuesday, July 13, 2004 9:23 AM > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > So I think what this thread validates is that there is no clear data to > > prove that the sentence > > stating that remote MAC is more manageable - so I'd like to kill this > thread > > and ask the authors > > of the document to remove the sentence. > > > > PatC > > -----Original Message----- > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > Sent: Tue 7/13/2004 7:35 AM > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > I don't object the idea of provide more explanation about the issue at > all. > > Your reasoning of the edge filtering might serve as the example there. > > > > But also one point to note is the difference between the manageability of > > the AP and the network. The filtering function to be place at the edge > (AP) > > could improve the network manageability, but may descrease the > manageability > > of the AP (function) itself. > > > > cheers > > > > Cheng Hong > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > > Of Pat R. Calhoun > > Sent: Tuesday, July 13, 2004 1:04 PM > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > The one round trip "burden" of pushing a rule dow to the AP is minuscule > in > > comparison with opening up the floodgates for all traffic to be sent to > the > > AC. > > > > I agree that wired networks have higher bandwidth than the wireless > network, > > but I would wonder how many IT managers would be pleased to know that > their > > wired network investment is being used to potentially carry unauthorized > > traffic because their wireless solution's APs cannot provide any form of > > traffic policing. > > > > The advantage of Split MAC is that the AP is being told what it should and > > shouldn't allow onto the wired network, and if encryption is done on the > AP, > > it will even eliminate invalid (perhaps malicious) traffic from cluttering > > the wired network. This enables the AP to protect the AC's resources, > > further guaranteeing a well behaved wireless system. > > > > Anyhow, the original point behind this whole thread was that I disagreed > > with the statement in the document that stated that remote MAC was more > > manageable than split MAC. If we can kill that sentence (or at least > provide > > some concrete data proving this is true), then I will more than gladly get > > off my soap box. > > > > PatC > > -----Original Message----- > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > Sent: Mon 7/12/2004 9:24 PM > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > Well. That is a valid point. But would that be equally a burden with the > > split MAC where you need to put in extra efforts to manage the filter and > > the encryption at the edge? And, with a proper network design (not > > management), we don't need to care about the "burden" of traffic > considering > > that the wireless has much lower bandwidth offered than the wired network. > > > > cheers > > > > > > -----Original Message----- > > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > > Sent: Tuesday, July 13, 2004 12:14 PM > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > But I would equally argue that a remote MAC causes *all* traffic to > traverse > > the network from the AP to the AC (because the AP is really dumb). One of > > the benefits of Split MAC is that you have the ability to "protect" > network > > resources by being able to apply specific filters at the edge. For > example, > > if you have an encrypted channel, and you are capable of decrypting > packets > > at the edge, you would further protect the network by ensuring that only > > properly encrypted packets enter the wired network. > > > > So if unnecessary burden of the wired network is considered a management > > burden, then I would argue that Split MAC increases manageability. > > > > PatC > > -----Original Message----- > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > Sent: Mon 7/12/2004 9:00 PM > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > This really depends on how you define MANAGEABILITY. If the decrease in > > signaling message is counted as increase in managemeability, it is obivous > > that that moving the whole MAC to AC will simplify the protocol messages > > used between AC and AP (at least less messags). > > > > cheers > > > > Cheng > > > > -----Original Message----- > > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > > Sent: Tuesday, July 13, 2004 11:55 AM > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > Could I perhaps ask you to provide me with concrete data that proves this > is > > the case? I have plenty of data that proves that the centralized approach > > provides much better manageability. However, there is nothing in my data > > that shows that where some of the finer components of the MAC terminate > > increase (or decrease) manageability. > > > > PatC > > > > > > -----Original Message----- > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > Sent: Mon 7/12/2004 8:50 PM > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > As for the remote vs split, when we apply the same logic here, when the > > degree of centralization increases, more info will be available at the AC. > > Thus, the manageability will be better. > > > > But, of course the centralization also brings other issues, and therefore > > the degree of split should be a trade off result of different aspects. > > > > cheers > > > > Cheng Hong > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > > Of Pat R. Calhoun > > Sent: Tuesday, July 13, 2004 11:35 AM > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > I'm obviously not arguing that centralization is better... my point was > that > > the sentence that remote vs. split provides better manageability. I do not > > agree with that sentence, and the document also does not provide any > > supporting data to prove the point. > > > > PatC > > -----Original Message----- > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > Sent: Mon 7/12/2004 8:28 PM > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > Hi Pat, > > > > I think the point is that with a centralized arch. you have more > information > > about the network, i.e. at the centralized controller you have a overall > > view of the network instead of just the AP point of view. Therefore, more > > "value added" service could be provided. One simple example is that the > SME > > could make better decisions with info from several AP. > > > > > > cheers > > > > Cheng Hong > > > > > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf > > Of Pat R. Calhoun > > Sent: Tuesday, July 13, 2004 10:29 AM > > To: sgovindan@psl.com.sg; capwap@frascone.com > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > 7. Section 4.5. Could the authors please explain how they came to the > > conclusion that Remote MAC "improves > > > WTP manageability"? > > > > If I can proffer an explanation; the characteristics of Remote MAC > > follow from those of the Split MAC architecture. The Split MAC improves > > manageability over basic autonomous WTPs by centralizing some control > > aspects; Remote MAC goes further by centralizing 'all' aspects of the > > MAC. So the entire MAC processing is consolidated while the WTPs become > > extremely light devices. > > > > But one of the "advantages" of a centralized architecture, is that > the > > WTP look like "local interfaces", and are managed as such. Whether one > > implements > > remote or split MAC does not really change how one would manage such a > > network - > > so it's really down to implementation details. > > > > So as a consequence I disagree with the assumption (and statement) > > made > > in the document > > > > PatC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 13:26:20 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08364 for ; Mon, 19 Jul 2004 13:26:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AC4D20582; Mon, 19 Jul 2004 13:12:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FF8C207BC; Mon, 19 Jul 2004 13:12:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22382207BC for ; Mon, 19 Jul 2004 13:11:58 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 33E4820582 for ; Mon, 19 Jul 2004 13:11:56 -0400 (EDT) Message-ID: <01e701c46db5$9680ad20$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Dan Harkins" Cc: "Kempf" , References: <200407191707.i6JH79rw033740@homebrew.trpz.com> Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 10:26:52 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dan, > Also, you mentioned your current employer valuing the output of the > nostalgic IETF, but your current employer has already made up its mind > regarding the issue at hand without waiting for "competing technical ideas > to come to concensus." > Whatever gave you that impression? The fact that I'm author if the problem statement draft? That just means I think there's a problem, not that I agree with any particular solution. Note: In case you haven't seen, the Docomo co-author was dropped from the latest LWAPP draft. Turns out this was because his job description changed, but enough technical disagreement has arisen since he agreed to be co-author that taking a step backwards and seeing what actually is the case, based on some hard data, seems prudent. At the time he agreed to co-author, LWAPP was the only solution being suggested (other than the standard autonomous AP model). So, no, neither I nor my current employer (so far as I know,) have made a decision about the right solution. It's up to IEEE (and not IETF, incidently) to do that. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 13:30:22 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08760 for ; Mon, 19 Jul 2004 13:30:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D06AF207BC; Mon, 19 Jul 2004 13:16:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5501D207DD; Mon, 19 Jul 2004 13:16:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76826207DD for ; Mon, 19 Jul 2004 13:15:50 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id D71E7207BC for ; Mon, 19 Jul 2004 13:15:47 -0400 (EDT) Message-ID: <01f901c46db6$206c7230$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Dan Harkins" Cc: "Randy Chou" , References: <200407191707.i6JH79rw033740@homebrew.trpz.com> Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 10:30:44 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dan, And more to the point, do you or do you not think the text I posted was an appropriate substitution for the disputed text in the draft? jak ----- Original Message ----- From: "Dan Harkins" To: "James Kempf" Cc: "Randy Chou" ; Sent: Monday, July 19, 2004 10:07 AM Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) > That is certainly one view of the IETF, sadly it is more of a nostalgic > one. Another view is that the IETF is a place to submit a (portion of a) > proprietary scheme or protocol with the desire to place the official > imprimatur of the IETF upon it and to then claim compliance to a > "standard". When the points being made include marketing speak (e.g. > "[the AP] cannot firewall (sic) everything as it will not have all possible > keys (sic)") I think it's obvious which IETF this is. > > Also, you mentioned your current employer valuing the output of the > nostalgic IETF, but your current employer has already made up its mind > regarding the issue at hand without waiting for "competing technical ideas > to come to concensus." > > Dan. > > On Mon, 19 Jul 2004 09:00:43 PDT you wrote > > Gentlemen, > > > > (At the risk of getting beat up by both sides...)IETF is for people with > > competing technical ideas to come to concensus for the purpose of providing > > interoperability, something that has time and again proven valuable to > > customers of networking equipment (like my current employer). Scoring points > > about why one's technical vision is better than one's competitor, or bashing > > one's competitor's product offering is, in my opinion, somewhat inconsistent > > with this goal. > > > > There's obviously a difference of opinion here about where to locate state > > and how that impacts ease of managability. Barring some real hard data about > > managability for different products (which I would highly encourage both > > sides to seek through some neutral third party), there's probably no way to > > objectively assess the two sides of this argument. > > > > Therefore, as an attempt at concensus, I'd suggest modifying the statement > > to say something like the following: > > > > The exact balance of centralized v.s. decentralized state and its impact > > on managability for CAPWAP architectures such as Split MAC and > > Remote MAC is currently a matter of dispute > > within the technical community. > > > > Sound reasonable? > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Randy Chou" > > To: > > Cc: > > Sent: Sunday, July 18, 2004 11:41 PM > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > Interesting how you cut most of my points out, then ask me where they are. > > > I've included the thread again for reference below... > > > > > > >>First, the manageability side...Clearly the less state there is to > > > transmit between different devices, the easier it is to manage. So the > > > statement in current draft is correct IMO. > > > > Since you started by implying that you had multiple points to make, > > > perhaps you'd like to also include those? I have made counter arguments > > that > > > no one else has been able to refute, so at this point the justification > > made > > > in favor of this sentence seems to be about as good as my mother's old > > > argument "because I said so". > > > > > > I'm beginning to understand why most choose not to reply to your posts. > > My > > > statement is self-evident. We're not getting anywhere discussing it > > further > > > when it comes to manageability and I'd certainly like to keep your mother > > > out of this discussion. > > > > > > Your security statement I refuted (which you also conveniently cut out) > > was > > > a misconception I heard elsewhere too and wanted to correct it...The idea > > > that handling encryption at the AP can prevent flooding the wired network. > > > Because the authentication portion of 802.11i is based on 802.1x, and the > > > keys for 802.1x (TLS portion) reside on the authentication server, the AP > > > cannot prevent EAP flooding. So flooding must be prevented in other ways > > > which I've already mentioned below... > > > > > > The use of WEP and security in the same sentence is contradictory. > > > > > > > > > Again you chose to cut out what I said. I mentioned both WEP and AES-CCM > > > where flooding can occur to point out that it is irrelevant what > > encryption > > > is used. > > > > > > On a slightly more humorous note...searching on google for "wep security > > > airespace", the first hit yields: > > > > > > "Specifically, the Airespace security framework supports the following > > > layers of security protocols and ... action . Layer 2 - WEP, WPA, 802.1x" > > > > > > And I'm the one with contradictory statements??? Sigh... > > > > > > Regards, > > > > > > -- > > > Randy > > > > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > > Behalf Of Pat R. Calhoun > > > Sent: Sunday, July 18, 2004 12:22 PM > > > To: Randy Chou; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > > Sorry, jumping into the thread a bit late. Some comments to add to the > > > discussion...I don't believe there's justification of removal of a > > > manageability statement based on its security implication. If there is a > > > flaw in the security, then the flaw needs to be fixed. In this case > > > however, the security implication itself has not gone through thorough > > > analysis either and I don't agree with some of the conclusions implied. > > > > > > First, the manageability side...Clearly the less state there is to > > > transmit between different devices, the easier it is to manage. So the > > > statement in current draft is correct IMO. > > > > > > Since you started by implying that you had multiple points to > > make, > > > perhaps you'd like to also include those? I have made counter arguments > > that > > > no one else has been able to refute, so at this point the justification > > made > > > in favor of this sentence seems to be about as good as my mother's old > > > argument "because I said so". > > > > > > Traffic policing can be done in many ways. In this case, even if the AP > > > can do encryption, it cannot firewall everything as it will not have all > > the > > > possible keys for all the types of authentication and encryption in a > > > wireless network. There's also a security weakness in keeping the keys at > > > the AP itself, but I'll leave that discussion for another day. > > > > > > Can you say apples and oranges? The definition of an AP does not > > > even include a firewall function, so trying to introduce this now is > > > irrelevant (unless you plan to introduce a firewall as part of the IEEE's > > > definition of an AP). Hell at that point why don't we also include a web > > > server, traffic shaper, etc. > > > > > > WEP for example has no replay counters [ed: trimmed unnecessary text] > > > > > > The use of WEP and security in the same sentence is contradictory. > > > > > > PatC > > > > > > > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > > > Behalf Of Randy Chou > > > Sent: Friday, July 16, 2004 6:44 PM > > > To: capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > > Sorry, jumping into the thread a bit late. Some comments to add to the > > > discussion...I don't believe there's justification of removal of a > > > manageability statement based on its security implication. If there is a > > > flaw in the security, then the flaw needs to be fixed. In this case > > > however, the security implication itself has not gone through thorough > > > analysis either and I don't agree with some of the conclusions implied. > > > > > > First, the manageability side...Clearly the less state there is to > > transmit > > > between different devices, the easier it is to manage. So the statement > > in > > > current draft is correct IMO. > > > > > > Now moving to the security implications which I believe should be a > > > different discussion... > > > > > > > I agree that wired networks have higher bandwidth than the wireless > > > network, > > > but I would wonder how many IT managers would be pleased to know that > > their > > > wired network investment is being used to potentially carry unauthorized > > > traffic because their wireless solution's APs cannot provide any form of > > > traffic policing. > > > > > > >The advantage of Split MAC is that the AP is being told what it should > > and > > > shouldn't allow onto the wired network, and if encryption is done on the > > AP, > > > it will even eliminate invalid (perhaps malicious) traffic from cluttering > > > the wired network. This enables the AP to protect the AC's resources, > > > further guaranteeing a well behaved wireless system. > > > > > > > > > Traffic policing can be done in many ways. In this case, even if the AP > > can > > > do encryption, it cannot firewall everything as it will not have all the > > > possible keys for all the types of authentication and encryption in a > > > wireless network. There's also a security weakness in keeping the keys at > > > the AP itself, but I'll leave that discussion for another day. > > > > > > WEP for example has no replay counters and hence the AP does not have > > enough > > > information and the wired network can be flooded with or without the > > > encryption being done on the AP itself. So the AP wouldn't be able to > > > protect even simple data. With more sophisticated encryption such as > > > AES-CCMP (802.11i) and assuming dot1x, EAP packets are authenticated by > > the > > > backend radius and so the AP does not have enough information to protect > > > either. In other networks, VPN over wireless is required and so unless > > the > > > AP is doing L3 encryption, this wouldn't work either. I'm sure I've left > > > other possible flood attacks out. So with strong or weak encryption, > > > flooding is possible and needs to be addressed in a different way > > > (firewall'd). But we're going off on a different tangent and I'd also be > > > advertising a feature rather than discussing the merits of the draft > > itself > > > ;). > > > > > > Regards, > > > > > > -- > > > Randy > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf > > > Of Pat R. Calhoun > > > Sent: Tuesday, July 13, 2004 9:23 AM > > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > > > > > So I think what this thread validates is that there is no clear data to > > > prove that the sentence > > > stating that remote MAC is more manageable - so I'd like to kill this > > thread > > > and ask the authors > > > of the document to remove the sentence. > > > > > > PatC > > > -----Original Message----- > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > Sent: Tue 7/13/2004 7:35 AM > > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > I don't object the idea of provide more explanation about the issue at > > all. > > > Your reasoning of the edge filtering might serve as the example there. > > > > > > But also one point to note is the difference between the manageability of > > > the AP and the network. The filtering function to be place at the edge > > (AP) > > > could improve the network manageability, but may descrease the > > manageability > > > of the AP (function) itself. > > > > > > cheers > > > > > > Cheng Hong > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf > > > Of Pat R. Calhoun > > > Sent: Tuesday, July 13, 2004 1:04 PM > > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > > > > > The one round trip "burden" of pushing a rule dow to the AP is minuscule > > in > > > comparison with opening up the floodgates for all traffic to be sent to > > the > > > AC. > > > > > > I agree that wired networks have higher bandwidth than the wireless > > network, > > > but I would wonder how many IT managers would be pleased to know that > > their > > > wired network investment is being used to potentially carry unauthorized > > > traffic because their wireless solution's APs cannot provide any form of > > > traffic policing. > > > > > > The advantage of Split MAC is that the AP is being told what it should and > > > shouldn't allow onto the wired network, and if encryption is done on the > > AP, > > > it will even eliminate invalid (perhaps malicious) traffic from cluttering > > > the wired network. This enables the AP to protect the AC's resources, > > > further guaranteeing a well behaved wireless system. > > > > > > Anyhow, the original point behind this whole thread was that I disagreed > > > with the statement in the document that stated that remote MAC was more > > > manageable than split MAC. If we can kill that sentence (or at least > > provide > > > some concrete data proving this is true), then I will more than gladly get > > > off my soap box. > > > > > > PatC > > > -----Original Message----- > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > Sent: Mon 7/12/2004 9:24 PM > > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > Well. That is a valid point. But would that be equally a burden with the > > > split MAC where you need to put in extra efforts to manage the filter and > > > the encryption at the edge? And, with a proper network design (not > > > management), we don't need to care about the "burden" of traffic > > considering > > > that the wireless has much lower bandwidth offered than the wired network. > > > > > > cheers > > > > > > > > > -----Original Message----- > > > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > > > Sent: Tuesday, July 13, 2004 12:14 PM > > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > > > > > But I would equally argue that a remote MAC causes *all* traffic to > > traverse > > > the network from the AP to the AC (because the AP is really dumb). One of > > > the benefits of Split MAC is that you have the ability to "protect" > > network > > > resources by being able to apply specific filters at the edge. For > > example, > > > if you have an encrypted channel, and you are capable of decrypting > > packets > > > at the edge, you would further protect the network by ensuring that only > > > properly encrypted packets enter the wired network. > > > > > > So if unnecessary burden of the wired network is considered a management > > > burden, then I would argue that Split MAC increases manageability. > > > > > > PatC > > > -----Original Message----- > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > Sent: Mon 7/12/2004 9:00 PM > > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > This really depends on how you define MANAGEABILITY. If the decrease in > > > signaling message is counted as increase in managemeability, it is obivous > > > that that moving the whole MAC to AC will simplify the protocol messages > > > used between AC and AP (at least less messags). > > > > > > cheers > > > > > > Cheng > > > > > > -----Original Message----- > > > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > > > Sent: Tuesday, July 13, 2004 11:55 AM > > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > > > > > Could I perhaps ask you to provide me with concrete data that proves this > > is > > > the case? I have plenty of data that proves that the centralized approach > > > provides much better manageability. However, there is nothing in my data > > > that shows that where some of the finer components of the MAC terminate > > > increase (or decrease) manageability. > > > > > > PatC > > > > > > > > > -----Original Message----- > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > Sent: Mon 7/12/2004 8:50 PM > > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > As for the remote vs split, when we apply the same logic here, when the > > > degree of centralization increases, more info will be available at the AC. > > > Thus, the manageability will be better. > > > > > > But, of course the centralization also brings other issues, and therefore > > > the degree of split should be a trade off result of different aspects. > > > > > > cheers > > > > > > Cheng Hong > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf > > > Of Pat R. Calhoun > > > Sent: Tuesday, July 13, 2004 11:35 AM > > > To: Cheng Hong; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > > > > > I'm obviously not arguing that centralization is better... my point was > > that > > > the sentence that remote vs. split provides better manageability. I do not > > > agree with that sentence, and the document also does not provide any > > > supporting data to prove the point. > > > > > > PatC > > > -----Original Message----- > > > From: Cheng Hong [mailto:hcheng@psl.com.sg] > > > Sent: Mon 7/12/2004 8:28 PM > > > To: Pat R. Calhoun; sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > Hi Pat, > > > > > > I think the point is that with a centralized arch. you have more > > information > > > about the network, i.e. at the centralized controller you have a overall > > > view of the network instead of just the AP point of view. Therefore, more > > > "value added" service could be provided. One simple example is that the > > SME > > > could make better decisions with info from several AP. > > > > > > > > > cheers > > > > > > Cheng Hong > > > > > > > > > > > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf > > > Of Pat R. Calhoun > > > Sent: Tuesday, July 13, 2004 10:29 AM > > > To: sgovindan@psl.com.sg; capwap@frascone.com > > > Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt > > > > > > > > > > 7. Section 4.5. Could the authors please explain how they came to the > > > conclusion that Remote MAC "improves > > > > WTP manageability"? > > > > > > If I can proffer an explanation; the characteristics of Remote MAC > > > follow from those of the Split MAC architecture. The Split MAC improves > > > manageability over basic autonomous WTPs by centralizing some control > > > aspects; Remote MAC goes further by centralizing 'all' aspects of the > > > MAC. So the entire MAC processing is consolidated while the WTPs become > > > extremely light devices. > > > > > > But one of the "advantages" of a centralized architecture, is that > > the > > > WTP look like "local interfaces", and are managed as such. Whether one > > > implements > > > remote or split MAC does not really change how one would manage such a > > > network - > > > so it's really down to implementation details. > > > > > > So as a consequence I disagree with the assumption (and statement) > > > made > > > in the document > > > > > > PatC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 13:42:22 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10133 for ; Mon, 19 Jul 2004 13:42:21 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F44020368; Mon, 19 Jul 2004 13:28:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3674E208C5; Mon, 19 Jul 2004 13:28:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48C63208C5 for ; Mon, 19 Jul 2004 13:27:35 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id 9292720368 for ; Mon, 19 Jul 2004 13:27:32 -0400 (EDT) Received: from FATCAT ([10.202.10.126]) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jul 2004 10:41:40 -0700 From: "Randy Chou" To: "Pat R. Calhoun" , Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C46D7D.97036C20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <55749BC69138654EBBC4C50BA4F55610020C4212@AIREMAIL.airespace.com> X-OriginalArrivalTime: 19 Jul 2004 17:41:40.0387 (UTC) FILETIME=[A5F3AF30:01C46DB7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 10:46:04 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C46D7D.97036C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > As far as authenticating 802.1x packets (because they are not authenticated), there are other methods,such as rate limiting, etc. That's when we start moving functionality into the AP that doesn't necessarily belong in this document, something we should prevent as you also alluded to. Rate limiting as we've seen in other security products isn't that simple of a problem. A plain rate limiting approach is simply shifting the problem elsewhere. Note that this was just one of the problems I had listed out. The AP can never fully guarantee that a packet that isn't destined to the wired side can be dropped, so the AP cannot claim to prevent flooding (based on its current definition). So flood prevention shouldn't come into discussion when analyzing ease of manageability. > That said, what I was *trying* to say is that we should not be designing the system for WEP, but for TKIP and AES-CCM. As much as I hate WEP, ease of manageability should take into account all likely modes of operation. Besides EAP flood in TKIP and AES-CCM environments, there are plenty of enterprises running different types of encryption (or no encryption) for guests, phones, VPN over WEP, where a plain replay attack will flood the wire. That is why I wanted to separate manageability and security in the first place. From email from James Kempf: > Can we keep it civil? My apologies. Email's not always the best medium for arguments and it's easy to get carried away. > There's obviously a difference of opinion here about where to locate state and how that impacts ease of managability. Barring some real hard data about managability for different products (which I would highly encourage both sides to seek through some neutral third party), there's probably no way to objectively assess the two sides of this argument. Therefore, as an attempt at concensus, I'd suggest modifying the statement to say... Besides giving Pat a hard time, I truly do believe the statement I had made was self-evident, "fewer state between devices makes it easier to manage", and would like to hear other's opinion before changing the wording. Was there any other compelling reason against the current wording besides Pat's flood prevention claim? Regards, -- Randy -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Monday, July 19, 2004 5:54 AM To: Randy Chou; capwap@frascone.com Cc: rchou@arubanetworks.com Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt I'm beginning to understand why most choose not to reply to your posts. My statement is self-evident. We're not getting anywhere discussing it further when it comes to manageability and I'd certainly like to keep your mother out of this discussion. Then may I introduce you to my aunt ;-) Your security statement I refuted (which you also conveniently cut out) was a misconception I heard elsewhere too and wanted to correct it...The idea that handling encryption at the AP can prevent flooding the wired network. Because the authentication portion of 802.11i is based on 802.1x, and the keys for 802.1x (TLS portion) reside on the authentication server, the AP cannot prevent EAP flooding. So flooding must be prevented in other ways which I've already mentioned below... hmmmm.... you really have me confused here. Certainly the client's credentials are on the AS, but the PMK and the PTK aren't. Therefore the questions really is whether it is possible to decrypt the packets in the AP or not. I would state that pushing the PTK into the AP (not in permanent storage) makes plenty of sense as it allows the AP to at least discard invalid packets. As far as authenticating 802.1x packets (because they are not authenticated), there are other methods,such as rate limiting, etc. Again you chose to cut out what I said. I mentioned both WEP and AES-CCM where flooding can occur to point out that it is irrelevant what encryption is used. I apologize for removing the text, but it really didn't address the point. In any case, you seem to imply that encryption cannot be done in the AP, or that a system must be designed for WEP (not sure which one). I think that one should not assume that either one of these points is true. On a slightly more humorous note...searching on google for "wep security airespace", the first hit yields: "Specifically, the Airespace security framework supports the following layers of security protocols and ... action • Layer 2 – WEP, WPA, 802.1x" Indeed, that is rather humurous - but keep in mind that this is a marketing brochure and IT buyers have a check list that very often includes items that will not (or should not) be used. How many times have I seen that famous RFP come in with some April Fool's RFC on it. That said, what I was *trying* to say is that we should not be designing the system for WEP, but for TKIP and AES-CCM. So we can keep this thread alive or agree to disagree. In either case, there is no clear evidence that the original statement was valid. You have an opinion, I have my own. PatC ------=_NextPart_000_0002_01C46D7D.97036C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> As far as authenticating 802.1x = packets=20 (because they are not authenticated), there are other methods,such as = rate=20 limiting, etc.
 
That's when we start moving functionality into the AP that = doesn't=20 necessarily belong in this document, something we should prevent as you = also=20 alluded to.  Rate limiting as we've seen in other security products = isn't=20 that simple of a problem.  A plain rate limiting approach is simply = shifting the problem elsewhere.  Note that this was just one of the = problems I had listed out.  The AP can never fully guarantee = that a=20 packet that isn't destined to the wired side can be dropped, so the AP = cannot=20 claim to prevent flooding (based on its current definition).  So = flood=20 prevention shouldn't come into discussion when analyzing ease of=20 manageability.
 
>=20 That said, what I was *trying* to say is that we should not be designing = the=20 system for WEP, but for TKIP and AES-CCM.
 
As=20 much as I hate WEP, ease of manageability should take into account = all=20 likely modes of operation.  Besides EAP flood in TKIP and AES-CCM=20 environments, there are plenty of enterprises running different types of = encryption (or no encryption) for guests, phones, VPN over WEP, where a = plain=20 replay attack will flood the wire.  That is why I wanted to = separate=20 manageability and security in the first place.
 
From email from James=20 Kempf:
> Can = we keep it=20 civil?
 
My apologies.  Email's not always the = best medium=20 for arguments and it's easy to get carried=20 away.
 
> There's obviously a difference of = opinion=20 here about where to locate state
and how that impacts = ease of=20 managability. Barring some real hard data about
managability for = different products=20 (which I would highly encourage both
sides to seek through = some neutral=20 third party), there's probably no way to
objectively assess the = two sides of=20 this argument.
Therefore, as an = attempt at=20 concensus, I'd suggest modifying the statement
to say...
 
Besides giving Pat a hard time, I truly do = believe the=20 statement I had made was self-evident, "fewer state between devices = makes it=20 easier to manage", and would like to hear other's opinion before = changing=20 the wording.  Was there any other compelling reason against the = current=20 wording besides Pat's flood prevention=20 claim?
 
 
Regards,
 
--
Randy
-----Original Message-----
From: Pat R. Calhoun=20 [mailto:pcalhoun@airespace.com]
Sent: Monday, July 19, 2004 = 5:54=20 AM
To: Randy Chou; capwap@frascone.com
Cc:=20 rchou@arubanetworks.com
Subject: RE: [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

I'm = beginning to understand=20 why most choose not to reply to your posts.  My statement is=20 self-evident.  We're not getting anywhere discussing it further = when it=20 comes to manageability and I'd certainly like to keep your mother out = of this=20 discussion.
<PRC> Then may = I introduce=20 you to my aunt ;-)
 
Your security = statement I refuted=20 (which you also conveniently cut out) was a misconception I heard = elsewhere=20 too and wanted to correct it...The idea that handling encryption at = the AP can=20 prevent flooding the wired network.  Because the authentication = portion=20 of 802.11i is based on 802.1x, and the keys for 802.1x (TLS portion) = reside on=20 the authentication server, the AP cannot prevent EAP flooding.  = So=20 flooding must be prevented in other ways which I've already mentioned=20 below...
<PRC> hmmmm.... = you really=20 have me confused here. Certainly the client's credentials are on the = AS, but=20 the PMK and the PTK aren't. Therefore the questions really is whether = it is=20 possible to decrypt the packets in the AP or not. I would state that = pushing=20 the PTK into the AP (not in permanent storage) makes plenty of sense = as it=20 allows the AP to at least discard invalid packets. As far as = authenticating=20 802.1x packets (because they are not authenticated), there are other=20 methods,such as rate limiting, etc.
 
Again you chose to = cut out what I=20 said.  I mentioned both WEP and AES-CCM where flooding can occur = to point=20 out that it is irrelevant what encryption is used.
<PRC> I = apologize for=20 removing the text, but it really didn't address the point. In any = case, you=20 seem to imply that encryption cannot be done in the AP, or that a = system must=20 be designed for WEP (not sure which one). I think that one should not = assume=20 that either one of these points is true.
 
On a slightly more = humorous=20 note...searching on google for "wep security airespace", the=20 first hit yields:
 
"Specifically, the = Airespace=20 security framework supports the following layers of = security=20 protocols and ... action =95 Layer 2 =96 WEP, WPA,=20 802.1x"
 
<PRC> Indeed, that is rather humurous - = but keep=20 in mind that this is a marketing brochure and IT buyers have a check = list that=20 very often includes items that will not (or should not) be used. How = many=20 times have I seen that famous RFP come in with some April Fool's RFC = on it.=20 That said, what I was *trying* to say is that we should not be = designing the=20 system for WEP, but for TKIP and AES-CCM.
 
<PRC> So we can keep this thread alive or = agree to=20 disagree. In either case, there is no clear evidence that the original = statement was valid. You have an opinion, I have my own.
 
PatC
------=_NextPart_000_0002_01C46D7D.97036C20-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 14:02:32 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11728 for ; Mon, 19 Jul 2004 14:02:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 235F421791; Mon, 19 Jul 2004 13:43:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08C7A2094B; Mon, 19 Jul 2004 13:43:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C38420786 for ; Mon, 19 Jul 2004 13:43:00 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id E4803206D1 for ; Mon, 19 Jul 2004 13:42:57 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.12.6/8.12.6) with ESMTP id i6JHvWrw033905; Mon, 19 Jul 2004 10:57:32 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200407191757.i6JHvWrw033905@homebrew.trpz.com> To: "James Kempf" Cc: capwap@frascone.com Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) In-Reply-To: Your message of "Mon, 19 Jul 2004 10:26:52 PDT." <01e701c46db5$9680ad20$536115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33903.1090259852.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 10:57:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) James, Your email address is at docomolabs-usa.com. According to this http://www.80211info.com/publications/page207-515048.asp docomoolabs-usa has already purchased product that is the basis of one of these "competing technical ideas". So unless that press release is not factual-- it wouldn't be the first and definitely won't be the last-- your current employer has already made up its mind. I am not inferring any bias on you, don't misunderstand me. You mentioned that your current company, as a customer of networking equipment, values consensus-based standards like the IETF used to make but it has already acted in its capacity as a customer of networking equipment without waiting for any consensus-based standard to arrive. What your company's official view is vis-a-vis CAPWAP is not really relevant because at the IETF we're all supposed to be individuals pursuing the best solution (wink-wink) and not representatives with a corporate ax to grind. I mentioned your company in the same context you did-- as a customer of networking equipment-- and in that context it has already decided. Dan. On Mon, 19 Jul 2004 10:26:52 PDT you wrote > Dan, > > > Also, you mentioned your current employer valuing the output of the > > nostalgic IETF, but your current employer has already made up its mind > > regarding the issue at hand without waiting for "competing technical ideas > > to come to concensus." > > > > Whatever gave you that impression? The fact that I'm author if the problem > statement draft? That just means I think there's a problem, not that I agree > with any particular solution. > > Note: In case you haven't seen, the Docomo co-author was dropped from the > latest LWAPP draft. Turns out this was because his job description changed, > but enough technical disagreement has arisen since he agreed to be co-author > that taking a step backwards and seeing what actually is the case, based on > some hard data, seems prudent. At the time he agreed to co-author, LWAPP was > the only solution being suggested (other than the standard autonomous AP > model). > > So, no, neither I nor my current employer (so far as I know,) have made a > decision about the right solution. It's up to IEEE (and not IETF, > incidently) to do that. > > jak > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 14:04:49 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11893 for ; Mon, 19 Jul 2004 14:04:49 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DAE420552; Mon, 19 Jul 2004 13:49:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0553120622; Mon, 19 Jul 2004 13:49:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A706920552 for ; Mon, 19 Jul 2004 13:48:37 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id A110F20316 for ; Mon, 19 Jul 2004 13:48:35 -0400 (EDT) Message-ID: <024201c46dba$b5790b50$536115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Dan Harkins" Cc: References: <200407191757.i6JHvWrw033905@homebrew.trpz.com> Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 11:03:32 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dan, I partially swallowed the former bait, but I won't take this barbed hook! :-) The issue before the WG is what text to put into the draft. I've put out a suggestion on some compromise text between Pat and Randy. Randy wants to hear from other WG members. Instead of questioning my motives, how about putting out an opinion about what you think the text should be (and post an alternative if you don't like what I posted)? jak ----- Original Message ----- From: "Dan Harkins" To: "James Kempf" Cc: Sent: Monday, July 19, 2004 10:57 AM Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) > James, > > Your email address is at docomolabs-usa.com. According to this > > http://www.80211info.com/publications/page207-515048.asp > > docomoolabs-usa has already purchased product that is the basis of > one of these "competing technical ideas". So unless that press release > is not factual-- it wouldn't be the first and definitely won't be the > last-- your current employer has already made up its mind. > > I am not inferring any bias on you, don't misunderstand me. You > mentioned that your current company, as a customer of networking > equipment, values consensus-based standards like the IETF used to > make but it has already acted in its capacity as a customer of > networking equipment without waiting for any consensus-based > standard to arrive. > > What your company's official view is vis-a-vis CAPWAP is not really > relevant because at the IETF we're all supposed to be individuals > pursuing the best solution (wink-wink) and not representatives with a > corporate ax to grind. I mentioned your company in the same context > you did-- as a customer of networking equipment-- and in that context > it has already decided. > > Dan. > > On Mon, 19 Jul 2004 10:26:52 PDT you wrote > > Dan, > > > > > Also, you mentioned your current employer valuing the output of the > > > nostalgic IETF, but your current employer has already made up its mind > > > regarding the issue at hand without waiting for "competing technical ideas > > > to come to concensus." > > > > > > > Whatever gave you that impression? The fact that I'm author if the problem > > statement draft? That just means I think there's a problem, not that I agree > > with any particular solution. > > > > Note: In case you haven't seen, the Docomo co-author was dropped from the > > latest LWAPP draft. Turns out this was because his job description changed, > > but enough technical disagreement has arisen since he agreed to be co-author > > that taking a step backwards and seeing what actually is the case, based on > > some hard data, seems prudent. At the time he agreed to co-author, LWAPP was > > the only solution being suggested (other than the standard autonomous AP > > model). > > > > So, no, neither I nor my current employer (so far as I know,) have made a > > decision about the right solution. It's up to IEEE (and not IETF, > > incidently) to do that. > > > > jak > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 14:18:21 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13029 for ; Mon, 19 Jul 2004 14:18:20 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D0F0208A3; Mon, 19 Jul 2004 14:04:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E1B920960; Mon, 19 Jul 2004 14:04:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14B6A20960 for ; Mon, 19 Jul 2004 14:03:56 -0400 (EDT) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id D7309208A3 for ; Mon, 19 Jul 2004 14:03:53 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.12.6/8.12.6) with ESMTP id i6JIIRrw034000; Mon, 19 Jul 2004 11:18:27 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200407191818.i6JIIRrw034000@homebrew.trpz.com> To: "James Kempf" Cc: capwap@frascone.com Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) In-Reply-To: Your message of "Mon, 19 Jul 2004 11:03:32 PDT." <024201c46dba$b5790b50$536115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33998.1090261107.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 11:18:27 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) James, A bad day fishing beats a good day working but if no one is biting then I might as well go back to work :-) I actually preferred Pat's suggestion to just kill the text. But your suggested text is emminently reasonable and including it will enable the reader who has not followed this thread to be aware of the debate. Dan. On Mon, 19 Jul 2004 11:03:32 PDT you wrote > Dan, > > I partially swallowed the former bait, but I won't take this barbed hook! > :-) > > The issue before the WG is what text to put into the draft. I've put out a > suggestion on some compromise text between Pat and Randy. Randy wants to > hear from other WG members. Instead of questioning my motives, how about > putting out an opinion about what you think the text should be (and post an > alternative if you don't like what I posted)? > > jak > > ----- Original Message ----- > From: "Dan Harkins" > To: "James Kempf" > Cc: > Sent: Monday, July 19, 2004 10:57 AM > Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on > draft-ietf-capwap-arch-03.txt) > > > > James, > > > > Your email address is at docomolabs-usa.com. According to this > > > > http://www.80211info.com/publications/page207-515048.asp > > > > docomoolabs-usa has already purchased product that is the basis of > > one of these "competing technical ideas". So unless that press release > > is not factual-- it wouldn't be the first and definitely won't be the > > last-- your current employer has already made up its mind. > > > > I am not inferring any bias on you, don't misunderstand me. You > > mentioned that your current company, as a customer of networking > > equipment, values consensus-based standards like the IETF used to > > make but it has already acted in its capacity as a customer of > > networking equipment without waiting for any consensus-based > > standard to arrive. > > > > What your company's official view is vis-a-vis CAPWAP is not really > > relevant because at the IETF we're all supposed to be individuals > > pursuing the best solution (wink-wink) and not representatives with a > > corporate ax to grind. I mentioned your company in the same context > > you did-- as a customer of networking equipment-- and in that context > > it has already decided. > > > > Dan. > > > > On Mon, 19 Jul 2004 10:26:52 PDT you wrote > > > Dan, > > > > > > > Also, you mentioned your current employer valuing the output of the > > > > nostalgic IETF, but your current employer has already made up its mind > > > > regarding the issue at hand without waiting for "competing technical > ideas > > > > to come to concensus." > > > > > > > > > > Whatever gave you that impression? The fact that I'm author if the > problem > > > statement draft? That just means I think there's a problem, not that I > agree > > > with any particular solution. > > > > > > Note: In case you haven't seen, the Docomo co-author was dropped from > the > > > latest LWAPP draft. Turns out this was because his job description > changed, > > > but enough technical disagreement has arisen since he agreed to be > co-author > > > that taking a step backwards and seeing what actually is the case, based > on > > > some hard data, seems prudent. At the time he agreed to co-author, LWAPP > was > > > the only solution being suggested (other than the standard autonomous AP > > > model). > > > > > > So, no, neither I nor my current employer (so far as I know,) have made > a > > > decision about the right solution. It's up to IEEE (and not IETF, > > > incidently) to do that. > > > > > > jak > > > > > > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 14:45:27 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15188 for ; Mon, 19 Jul 2004 14:45:26 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A0CD020A1D; Mon, 19 Jul 2004 14:31:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6953820A9D; Mon, 19 Jul 2004 14:31:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E914720A4C for ; Mon, 19 Jul 2004 14:30:20 -0400 (EDT) Received: from gunstock.propagatenet.com (cust-206-40-173-43.gis.net [206.40.173.43]) by mail.frascone.com (Postfix) with SMTP id 1EAF520A1D for ; Mon, 19 Jul 2004 14:30:19 -0400 (EDT) Received: from exchange.propagatenet.com ([192.168.193.203]) by gunstock.propagatenet.com (SMSSMTP 4.0.0.59) with SMTP id M2004071914411410067 for ; Mon, 19 Jul 2004 14:41:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <2079E501DCD2FF4096F221E248CB28B006C35B@exchange.propagatenet.com> Thread-Topic: Can we keep it civil? Thread-Index: AcRtvM/1P7Fq2WLLQRm/G+pik1kcQwAAT58g From: "Roger Durand" To: "Dan Harkins" , "James Kempf" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Can we keep it civil? Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 14:44:28 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable As a third party who has tracked this debate let me recommend the following for now- Do both - kill the sentence which is the subject of the objection and debate and then make a note or comment in another document location that the manageability advantages and disadvantages of different architectures is presently an item of debate...=20 For the future - humbly request those parties who care to enter this manageability debate and make statements of advantage they should provide a proof or data so as to better understand from what viewpoint such an advantage is perceived? Different management viewpoints may perceive different results regarding this debate and I think that may be a cause for a fundamental communication failure but actual data will clear up any misunderstanding. Sincerely Roger Durand =20 -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com]=20 Sent: Monday, July 19, 2004 2:18 PM To: James Kempf Cc: capwap@frascone.com Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt)=20 James, A bad day fishing beats a good day working but if no one is biting then I might as well go back to work :-) I actually preferred Pat's suggestion to just kill the text. But your suggested text is emminently reasonable and including it will enable the reader who has not followed this thread to be aware of the debate. Dan. On Mon, 19 Jul 2004 11:03:32 PDT you wrote > Dan, >=20 > I partially swallowed the former bait, but I won't take this barbed hook! > :-) >=20 > The issue before the WG is what text to put into the draft. I've put out a > suggestion on some compromise text between Pat and Randy. Randy wants to > hear from other WG members. Instead of questioning my motives, how about > putting out an opinion about what you think the text should be (and post an > alternative if you don't like what I posted)? >=20 > jak >=20 > ----- Original Message -----=20 > From: "Dan Harkins" > To: "James Kempf" > Cc: > Sent: Monday, July 19, 2004 10:57 AM > Subject: Re: Can we keep it civil? (was: Re: [Capwap] Comments on > draft-ietf-capwap-arch-03.txt) >=20 >=20 > > James, > > > > Your email address is at docomolabs-usa.com. According to this > > > > http://www.80211info.com/publications/page207-515048.asp > > > > docomoolabs-usa has already purchased product that is the basis of > > one of these "competing technical ideas". So unless that press release > > is not factual-- it wouldn't be the first and definitely won't be the > > last-- your current employer has already made up its mind. > > > > I am not inferring any bias on you, don't misunderstand me. You > > mentioned that your current company, as a customer of networking > > equipment, values consensus-based standards like the IETF used to > > make but it has already acted in its capacity as a customer of > > networking equipment without waiting for any consensus-based > > standard to arrive. > > > > What your company's official view is vis-a-vis CAPWAP is not really > > relevant because at the IETF we're all supposed to be individuals > > pursuing the best solution (wink-wink) and not representatives with a > > corporate ax to grind. I mentioned your company in the same context > > you did-- as a customer of networking equipment-- and in that context > > it has already decided. > > > > Dan. > > > > On Mon, 19 Jul 2004 10:26:52 PDT you wrote > > > Dan, > > > > > > > Also, you mentioned your current employer valuing the output of the > > > > nostalgic IETF, but your current employer has already made up its mind > > > > regarding the issue at hand without waiting for "competing technical > ideas > > > > to come to concensus." > > > > > > > > > > Whatever gave you that impression? The fact that I'm author if the > problem > > > statement draft? That just means I think there's a problem, not that I > agree > > > with any particular solution. > > > > > > Note: In case you haven't seen, the Docomo co-author was dropped from > the > > > latest LWAPP draft. Turns out this was because his job description > changed, > > > but enough technical disagreement has arisen since he agreed to be > co-author > > > that taking a step backwards and seeing what actually is the case, based > on > > > some hard data, seems prudent. At the time he agreed to co-author, LWAPP > was > > > the only solution being suggested (other than the standard autonomous AP > > > model). > > > > > > So, no, neither I nor my current employer (so far as I know,) have made > a > > > decision about the right solution. It's up to IEEE (and not IETF, > > > incidently) to do that. > > > > > > jak > > > > > > > > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Jul 19 15:31:28 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18553 for ; Mon, 19 Jul 2004 15:31:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE62220529; Mon, 19 Jul 2004 15:16:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D19BA20830; Mon, 19 Jul 2004 15:16:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A856A20529 for ; Mon, 19 Jul 2004 15:15:26 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id CF1DD20247 for ; Mon, 19 Jul 2004 15:15:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46DC7.19FC6DA4" Subject: RE: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) Message-ID: <55749BC69138654EBBC4C50BA4F55610020C4236@AIREMAIL.airespace.com> Thread-Topic: Can we keep it civil? (was: Re: [Capwap] Comments on draft-ietf-capwap-arch-03.txt) Thread-Index: AcRtqe0Pvc03u57eTcOGTiU5ym6WVQAHPdsg From: "Pat R. Calhoun" To: "James Kempf" , "Randy Chou" , Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 19 Jul 2004 12:30:47 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C46DC7.19FC6DA4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Therefore, as an attempt at concensus, I'd suggest modifying the = statement to say something like the following: The exact balance of centralized v.s. decentralized state and its = impact on managability for CAPWAP architectures such as Split MAC and Remote MAC is currently a matter of dispute within the technical community. Well, my preferred approach is to kill the text, but I am willing = to live with this proposed text instead. PatC ------_=_NextPart_001_01C46DC7.19FC6DA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Can we keep it civil? (was: Re: [Capwap] Comments on = draft-ietf-capwap-arch-03.txt)

Therefore, as an attempt at concensus, I'd suggest = modifying the statement
to say something like the following:

    The exact balance of centralized v.s. decentralized = state and its impact
    on managability for CAPWAP architectures such as = Split  MAC and
    Remote MAC is currently a matter of dispute
    within the technical community.

<PRC> Well, my preferred approach is to kill the text, but I am = willing to live
with this proposed text instead.

PatC

------_=_NextPart_001_01C46DC7.19FC6DA4-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 20 03:56:24 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27762 for ; Tue, 20 Jul 2004 03:56:23 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FD4C20290; Tue, 20 Jul 2004 03:42:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE03A20E5F; Tue, 20 Jul 2004 03:42:03 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C40E20E5F for ; Tue, 20 Jul 2004 03:41:41 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id EF3FE20290 for ; Tue, 20 Jul 2004 03:41:38 -0400 (EDT) Received: from jadefox ([10.81.113.120]) by mailsrv.psl.com.sg (8.12.11/8.12.11) with ESMTP id i6K7rdkd016267; Tue, 20 Jul 2004 15:53:40 +0800 (SGT) Reply-To: From: "Saravanan Govindan" To: , , Cc: "Cheng Hong" , "Satoshi IINO" Organization: Panasonic Singapore Laboratories Message-ID: <002901c46e2f$18baa560$7871510a@jadefox> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] draft-cheng-capwap-classifications-01.txt Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 20 Jul 2004 15:56:41 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear All, This is an update to the previous classifications document. It also includes CAPWAP scenarios based on which some requirements have been derived. The draft should come online soon. Until then, it is available here; http://www.psl.com.sg/internet-drafts/draft-cheng-capwap-classifications -01.txt We look forward to feedback from the WG. Cheers Saravanan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.722 / Virus Database: 478 - Release Date: 18/07/2004 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jul 22 22:35:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21891 for ; Thu, 22 Jul 2004 22:35:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B4E3C20821; Thu, 22 Jul 2004 22:21:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4733B2097F; Thu, 22 Jul 2004 22:21:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 184EA20BD1 for ; Thu, 22 Jul 2004 22:20:05 -0400 (EDT) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 8997B20412 for ; Thu, 22 Jul 2004 22:20:02 -0400 (EDT) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.0/8.13.0) with ESMTP id i6N2W3sw005139; Fri, 23 Jul 2004 10:32:11 +0800 (SGT) From: "Cheng Hong" To: Cc: "'Saravanan Govindan'" , "'Satoshi IINO'" , "'TAN, Pek-Yew'" Organization: Panasonic Singapore Laboratories Message-ID: <021f01c4705d$92af54d0$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0220_01C470A0.A0D294D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] FW: I-D ACTION:draft-cheng-capwap-classifications-01.txt Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 23 Jul 2004 10:34:21 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0220_01C470A0.A0D294D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, July 23, 2004 3:34 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-cheng-capwap-classifications-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Functionality Classifications for Control and Provisioning=20 of Wireless Access Points (CAPWAP) Author(s) : H. Cheng, et al. Filename : draft-cheng-capwap-classifications-01.txt Pages : 19 Date : 2004-7-22 =09 This document describes classifications for wireless local area network (WLAN) functionality. The main benefit of a consistent system of classification is accommodating the diversity of WLAN designs as seen in the Control and Provisioning of Wireless Access Points framework. This draft describes policies with which classifications may be used. The document analyzes various WLAN architectures and recent standardization efforts to derive key requirements for a CAPWAP WLAN protocol. It is envisioned that protocol development based on these requirements will enable interoperability among the various WLAN designs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-capwap-classifications-01= .tx t To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, = type "cd internet-drafts" and then "get draft-cheng-capwap-classifications-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-cheng-capwap-classifications-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0220_01C470A0.A0D294D0 Content-Type: Message/External-body; name="ATT00129.dat" Content-Disposition: attachment; filename="ATT00129.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-7-22145228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cheng-capwap-classifications-01.txt ------=_NextPart_000_0220_01C470A0.A0D294D0 Content-Type: Message/External-body; name="draft-cheng-capwap-classifications-01.txt" Content-Disposition: attachment; filename="draft-cheng-capwap-classifications-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-7-22145228.I-D@ietf.org> ------=_NextPart_000_0220_01C470A0.A0D294D0 Content-Type: text/plain; name="ATT00132.txt" Content-Disposition: attachment; filename="ATT00132.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0220_01C470A0.A0D294D0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 23 10:17:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26386 for ; Fri, 23 Jul 2004 10:17:51 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFEE4215BB; Fri, 23 Jul 2004 09:56:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21491215B8; Fri, 23 Jul 2004 09:56:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A4DF215B7 for ; Fri, 23 Jul 2004 09:54:43 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 15E76204BF for ; Fri, 23 Jul 2004 09:54:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C470BE.F609EE7D" Message-ID: <55749BC69138654EBBC4C50BA4F55610020C42B7@AIREMAIL.airespace.com> Thread-Topic: Comments on draft-cheng-capwap-classifications-01.txt Thread-Index: AcRwXjNgnhBPZTa3T8ioL4pHbwjJLAAYDQGh From: "Pat R. Calhoun" To: "Cheng Hong" , Cc: "Saravanan Govindan" , "Satoshi IINO" , "TAN, Pek-Yew" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 23 Jul 2004 07:07:35 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C470BE.F609EE7D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I applaud the authors on taking the time to write up this draft, while I = do believe that such a document is useful, I do have some issues with the actual = specification. 1. Section 2.1: I have an issue with this proposal. The basic premise is = that we cannot agree on a single model, so every vendor implements all possible = combinations. First, I believe that the engineering resources required to design such = a box would be cost prohibitive. Second, the number of possible combination=20 significantly increases the test conditions that must be performed by = the vendor. Third, it increases the code count on all devices - and the more = code you have, the higher the potential for errors. I would like to understand the motivation behind this proposal. 2. Section 3.1: The statement that consumers and enterprises need the = combined benefit of all architectures does not seem correct. Customers will = purchase a product that delivers the features and performance they require. It is = not clear to me that this can only be met by supporting all possible=20 architectures. 3. Section 3.4: So my view is slightly different. Some customers want = the plug and play convenience of a layer 2 approach. Furthermore, the fact that the AP is = not IP addresseable significantly reduces the risk of attack. Meanwhile, = some customers prefer the flexibility of a layer 3 approach, since it = provides them with the ability to deploy their access points on various subnets, = eliminating the network architectural restrictions associated with the layer 2 = approach. The security issue that is introduced with layer 3 can be overcome with a carefully designed implementation that is tested against a variety of = network attacks. However, I believe that you will find customers in both camps. = Does this mean that the IETF has to care about what customers will want? I = guess it is up to us to decide. 4. Section 4.1: I disagree for the reasons listed above. 5. Section 4.2: But there are some additional deployment issues here = that we are=20 ignoring, such as how to protect the data on the backhaul. Perhaps it is = fine to state that this is out of scope for the WG. 6. Section 4.4: QoS can be achieved via other means, such as DS or = 802.1P, and therefore there is not necessarily a need for sub-data channels. PatC ------_=_NextPart_001_01C470BE.F609EE7D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-cheng-capwap-classifications-01.txt

I applaud the authors on taking the time to write up = this draft, while I do believe
that such a document is useful, I do have some issues with the actual = specification.

1. Section 2.1: I have an issue with this proposal. The basic premise is = that we cannot
agree on a single model, so every vendor implements all possible = combinations.
First, I believe that the engineering resources required to design such = a box
would be cost prohibitive. Second, the number of possible = combination
significantly increases the test conditions that must be performed by = the
vendor. Third, it increases the code count on all devices - and the more = code
you have, the higher the potential for errors.

I would like to understand the motivation behind this proposal.


2. Section 3.1: The statement that consumers and enterprises need the = combined
benefit of all architectures does not seem correct. Customers will = purchase
a product that delivers the features and performance they require. It = is
not clear to me that this can only be met by supporting all possible
architectures.


3. Section 3.4: So my view is slightly different. Some customers want = the plug and play
convenience of a layer 2 approach. Furthermore, the fact that the AP is = not
IP addresseable significantly reduces the risk of attack. Meanwhile, = some
customers prefer the flexibility of a layer 3 approach, since it = provides them
with the ability to deploy their access points on various subnets, = eliminating
the network architectural restrictions associated with the layer 2 = approach.

The security issue that is introduced with layer 3 can be overcome = with
a carefully designed implementation that is tested against a variety of = network
attacks. However, I believe that you will find customers in both camps. = Does
this mean that the IETF has to care about what customers will want? I = guess it
is up to us to decide.


4. Section 4.1: I disagree for the reasons listed above.


5. Section 4.2: But there are some additional deployment issues here = that we are
ignoring, such as how to protect the data on the backhaul. Perhaps it is = fine
to state that this is out of scope for the WG.


6. Section 4.4: QoS can be achieved via other means, such as DS or = 802.1P, and therefore
there is not necessarily a need for sub-data channels.


PatC

------_=_NextPart_001_01C470BE.F609EE7D-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 23 13:03:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09271 for ; Fri, 23 Jul 2004 13:03:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2E6320C88; Fri, 23 Jul 2004 12:45:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 832022102C; Fri, 23 Jul 2004 12:45:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2323621604 for ; Fri, 23 Jul 2004 12:44:31 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 9664D20C88 for ; Fri, 23 Jul 2004 12:44:28 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i6NGvHm2012603 for ; Fri, 23 Jul 2004 12:57:18 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i6NGvGm2012568 for ; Fri, 23 Jul 2004 12:57:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C470D6.506D243E" Subject: RE: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt Message-ID: Thread-Topic: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt Thread-Index: AcRwXjNgnhBPZTa3T8ioL4pHbwjJLAAYDQGhAAVWTzA= From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 23 Jul 2004 10:58:44 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C470D6.506D243E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 This is to note that this ID is an individual submission - not a WG draft item; nor appears within the scope and timeframe of this charter. =20 However, In principle, the subject of draft is closely relevant to the taxonomy work. Therefore, we would allow the discussion in this WG list for now. =20 -mani _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Friday, July 23, 2004 7:08 AM To: Cheng Hong; capwap@frascone.com Cc: Saravanan Govindan; Satoshi IINO; TAN, Pek-Yew Subject: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt =20 I applaud the authors on taking the time to write up this draft, while I do believe that such a document is useful, I do have some issues with the actual specification. [...] 5. Section 4.2: But there are some additional deployment issues here that we are ignoring, such as how to protect the data on the backhaul. Perhaps it is fine to state that this is out of scope for the WG. [Mani, Mahalingam (Mahalingam)] see above. 6. Section 4.4: QoS can be achieved via other means, such as DS or 802.1P, and therefore there is not necessarily a need for sub-data channels. PatC=20 ------_=_NextPart_001_01C470D6.506D243E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-cheng-capwap-classifications-01.txt

All,

 

This is to note that this ID is an individual submission - not a WG draft = item;

nor appears within the scope and = timeframe of this charter.

 

However, In principle, the subject = of draft is closely relevant to the taxonomy work.

Therefore, we would allow the = discussion in this WG list for now.

 

-mani

From: = capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Friday, July 23, = 2004 7:08 AM
To: Cheng Hong; capwap@frascone.com
Cc: Saravanan Govindan; = Satoshi IINO; TAN, Pek-Yew
Subject: [Capwap] = Comments on draft-cheng-capwap-classifications-01.txt

 

I applaud the authors on taking the time to write up this draft, while I do = believe
that such a document is useful, I do have some issues with the actual specification.

[…]
5. Section 4.2: But there are some additional deployment issues here = that we are
ignoring, such as how to protect the data on the backhaul. Perhaps it is = fine
to state that this is out of scope for the WG.

[Mani, Mahalingam (Mahalingam)] see = above.



6. Section 4.4: QoS can be achieved via other means, such as DS or = 802.1P, and therefore
there is not necessarily a need for sub-data channels.


PatC

------_=_NextPart_001_01C470D6.506D243E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 23 14:00:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14442 for ; Fri, 23 Jul 2004 14:00:28 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A04D9215F7; Fri, 23 Jul 2004 13:46:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7BAFE20CD5; Fri, 23 Jul 2004 13:46:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72D71206B5 for ; Fri, 23 Jul 2004 13:45:43 -0400 (EDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 5896A2046C for ; Fri, 23 Jul 2004 13:45:41 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6NHxGm6018363; Fri, 23 Jul 2004 17:59:18 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6NI1iDo011297; Fri, 23 Jul 2004 18:01:47 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072310594903606 ; Fri, 23 Jul 2004 10:59:49 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Jul 2004 10:59:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C470DE.D7FCAC0F" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE019A3CF1@orsmsx408> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Thread-Index: AcRlFnioUmajvm3FSbiqICHTxvFYCALxdNsA From: "Yang, Lily L" To: "Pat R. Calhoun" , X-OriginalArrivalTime: 23 Jul 2004 17:59:48.0933 (UTC) FILETIME=[D86D9F50:01C470DE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 23 Jul 2004 10:59:47 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C470DE.D7FCAC0F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Pat - =20 Thanks for your careful review of the documents. The design team is preparing v04 right now to address your comments and the discussion lately. =20 One clarification question for you on item #2 below: Are you referring to 1.3 "WTP" definition here? We want to be able to use the terminology of "WTP" in all Centralized architecture discussion, including remote MAC. So we kind of took the "lowest denominator" approach in defining "WTP", which is 802.11 PHY. That is why we didn't want to say anything about MAC layer.=20 =20 Does that make sense? =20 Another clarification on item #7 below: it seems that you read the text as to say "it improves WTP manageability OVER SPIT and LOCAL MAC". But what we really intended to convey is a much weaker statement "improves WTP manageability OVER autonomous architecture".=20 But I agree the text isn't explicit and hence confusing. The discussion later in the mailing list shows that how vague a concept "manageability" can be, and how hard it is to make a sweeping value judgment statement. That is why we try to restraint ourselves in the draft to make such statements. But it is possible that we slip in one or two without thinking really hard. =20 We should be sending out our suggestions to resolve these comments in this mailing list soon. =20 Thanks again, =20 Lily =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Thursday, July 08, 2004 11:08 AM To: capwap@frascone.com Subject: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =20 =20 First, I'd like to applaud the authors on a job well done. It is clear in reading this spec that there was a significant amount of data to work with... I am very impressed with the document. 1. Section 1.3. "Typically ," -> "Typically, " 2. This section defines the AP as terminating the 802.11 PHY, but it should be noted that this device also terminates the 802.11 MAC mgmt layer, which is not specified. 3. The definition of Split MAC implies that all MAC mgmt is handled in the AC, but in certain implementations this is not true. The MAC mgmt packets that have very tight timing requirements can be handled in the WTP. 4. Page 14. The text reads 14 contributions, yet above 16 is mentioned. 5. Section 3.2. Another security issue is the very fact that this device is most likely not under lock and key, but does contain secret information in order to communicate with the backend systems, such as AAA, SNMP, etc. Due to the common management method used by IT personel of pushing a "template" to all similar devices, theft of such a device would compromise the wired network. 5. A Network Management Station (NMS) should not be considered as part of the Access Controller. While most controllers will provide one or more management interfaces, a system that is used to scale a global network generally resides on a separate system. 6. Page 25. The list of real-time features should probably include Power Save handling. 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves WTP manageability"? 8. Page 30. The term "Integration Service" is used as a substitute to bringing function. However, the terminology section called this function "portal". We should stick to a single term throughout the document. 9. Page 33, second to last paragraph, there is a non traditional character in the line that starts with "every mesh node..." 10. Section 5.1. If stations (or non-trusted equipment) are allowed to become part of the mesh backbone, end to end security is required otherwise users traffic will be compromised. 11. Page 45. The URL for the LWAPP draft has changed and the one listed has expired. Does it make sense to update it? 12. General comment. I understand that there was a desire to mask the vendor in the appendices, but I wonder whether this makes sense. The primary issue moving forward is that this is (and will) be known to people on the list (or reading he archives) 13. Appendix C. We really should discourage baseless marketing claims like "secure, scalable, large scale WLAN deployments" unless one intends to back this up with facts. I'm quite certain that no submittal was intended for the home user. 14. Appendix D, Page 52. Seems like spelling rogue as "rouge" is a common mistake. May want to search/replace. 15. Appendix D, question 4. Could the submitter be a tad more specific than "IP Tunnel". For instance, is there a control protocol to setup the tunnels, etc. 16. Appendix D, question 5. Probably too late now, but I really question how these claims can be made given the rather brief data - so we just have to assume the claims are true. 17. Appendix E. Good write-up! 18. Appendix F. I have a question for the author, but this is purely asked due to curiosity. In a home environment, you seem to imply that there is a single set top box, and that you can provide dynamic power assignment, but I wonder how you can do that with a single antenna - you need a clear view of the whole space that needs to be covered. 19. Appendix F, section 9. The paragraph states that the PHY and MAC association services are handled in the STB, and other MAC services are in the controller. Is it possible to get a breakdown or at least an understanding of what the other services being provided are? 20. Appendix L. I am curious about the fact that this architecture is completely agnostic of the PHY, yet it can provide such functions as centralized RF management (which cannot be performed if one has no idea what they are dealing with). PatC ------_=_NextPart_001_01C470DE.D7FCAC0F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-capwap-arch-03.txt

Hi, Pat = –

 

Thanks for your careful review of = the documents. The design team is preparing v04 right now to address your = comments and the discussion lately.

 

One clarification question for you = on item #2 below: Are you referring to 1.3 “WTP” definition here? We = want to be able to use the terminology of “WTP” in all = Centralized architecture discussion, including remote MAC. So we kind of took the = “lowest denominator” approach in defining “WTP”, which is = 802.11 PHY. That is why we didn’t want to say anything about MAC layer. =

 

Does that make = sense?

 

Another clarification on item #7 = below: it seems that you read the text as to say “it improves WTP manageability OVER SPIT and = LOCAL MAC”. But what we really intended to convey is a much weaker statement = “improves WTP = manageability OVER autonomous architecture”.

But I agree the text isn’t explicit and hence confusing. The discussion later in the mailing list shows that how vague = a concept “manageability” can be, and how hard it is to make a sweeping value judgment statement. That is why we try to restraint = ourselves in the draft to make such statements. But it is possible that we slip in = one or two without thinking really hard.

 

We should be sending out our = suggestions to resolve these comments in this mailing list = soon.

 

Thanks = again,

 

Lily

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun
Sent: Thursday, July 08, = 2004 11:08 AM
To: = capwap@frascone.com
Subject: [Capwap] Comments on draft-ietf-capwap-arch-03.txt

 

 

First, I'd like to applaud the authors on a job well done. It is clear in = reading this spec that there was a significant amount of data to work with... I am = very impressed with the document.

1. Section 1.3. "Typically ," -> "Typically, = "

2. This section defines the AP as terminating the 802.11 PHY, but it = should be noted that this device also terminates the
802.11 MAC mgmt layer, which is not specified.

3. The definition of Split MAC implies that all MAC mgmt is handled in = the AC, but in certain implementations this is not true. The MAC mgmt packets = that have very tight timing requirements can be handled in the WTP.

4. Page 14. The text reads 14 contributions, yet above 16 is = mentioned.

5. Section 3.2. Another security issue is the very fact that this device = is most likely not under lock and key, but does contain secret information = in order to communicate with the backend systems, such as AAA, SNMP, etc. = Due to the common management method used by IT personel of pushing a = "template" to all similar devices, theft of such a device would compromise the = wired network.

5. A Network Management Station (NMS) should not be considered as part = of the Access Controller. While most controllers will provide one or more = management interfaces, a system that is used to scale a global network generally = resides on a separate system.

6. Page 25. The list of real-time features should probably include Power = Save handling.

7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves WTP manageability"?

8. Page 30. The term "Integration Service" is used as a = substitute to bringing function. However, the terminology section called this function "portal". We should stick to a single term throughout the = document.

9. Page 33, second to last paragraph, there is a non traditional = character in the line that starts with "every mesh node..."

10. Section 5.1. If stations (or non-trusted equipment) are allowed to = become part of the mesh backbone, end to end security is required otherwise = users traffic will be compromised.

11. Page 45. The URL for the LWAPP draft has changed and the one listed = has expired. Does it make sense to update it?

12. General comment. I understand that there was a desire to mask the = vendor in the appendices, but I wonder whether this makes sense. The primary issue = moving forward is that this is (and will) be known to people on the list (or = reading he archives)

13. Appendix C. We really should discourage baseless marketing claims = like "secure, scalable, large scale WLAN deployments" unless one = intends to back this up with facts. I'm quite certain that no submittal was = intended for the home user.

14. Appendix D, Page 52. Seems like spelling rogue as "rouge" = is a common mistake. May want to search/replace.

15. Appendix D, question 4. Could the submitter be a tad more specific = than "IP Tunnel". For instance, is there a control protocol to = setup the tunnels, etc.

16. Appendix D, question 5. Probably too late now, but I really question = how these claims can be made given the rather brief data - so we just have = to assume the claims are true.

17. Appendix E. Good write-up!

18. Appendix F. I have a question for the author, but this is purely = asked due to curiosity. In a home environment, you seem to imply that there is a = single set top box, and that you can provide dynamic power assignment, but I = wonder how you can do that with a single antenna - you need a clear view of the = whole space that needs to be covered.

19. Appendix F, section 9. The paragraph states that the PHY and MAC association services are handled in the STB, and other MAC services are = in the controller. Is it possible to get a breakdown or at least an = understanding of what the other services being provided are?

20. Appendix L. I am curious about the fact that this architecture is completely agnostic of the PHY, yet it can provide such functions as centralized RF management (which cannot be performed if one has no idea = what they are dealing with).

PatC

------_=_NextPart_001_01C470DE.D7FCAC0F-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 23 18:23:28 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01920 for ; Fri, 23 Jul 2004 18:23:27 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 454EF201DE; Fri, 23 Jul 2004 18:09:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A55221730; Fri, 23 Jul 2004 18:09:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71B4121730 for ; Fri, 23 Jul 2004 18:08:58 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id 4E66A201DE for ; Fri, 23 Jul 2004 18:08:56 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6NMNES25853; Sat, 24 Jul 2004 01:23:14 +0300 (EET DST) X-Scanned: Sat, 24 Jul 2004 01:23:01 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i6NMN1FC022978; Sat, 24 Jul 2004 01:23:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 000x2H92; Sat, 24 Jul 2004 01:22:59 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6NMMvn19405; Sat, 24 Jul 2004 01:22:58 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Jul 2004 17:22:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47103.9A3ABFC4" Message-ID: Thread-Topic: question regarding Appendix Thread-Index: AcRxAbkfoDeaGkHIR7O6c7gBS7XY1gAAHYnQ From: To: , Cc: , X-OriginalArrivalTime: 23 Jul 2004 22:22:57.0033 (UTC) FILETIME=[9ADE7F90:01C47103] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: question regarding Appendix Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 23 Jul 2004 15:22:55 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47103.9A3ABFC4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good idea. I completely agree with you. In fact I keep meaning to send = mail you mail about removing it. It has served its purpose by allowing = us to have access to the raw, original data if someone were to challenge = the results. After 4 versions, I think we can remove the appendix. Any = questions regarding the data can be addressed by any of the DT members = that are listed in the draft. You are right, I think people do get = intimidated when they see a 100 page document, and we don't want that = when true document is only about 30 pages. =20 Does the WG have any objections to removing the appendix? =20 Thanks- Dorothy =20 =20 =20 -----Original Message----- From: ext Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Friday, July 23, 2004 3:09 PM To: Gellert Dorothy (Nokia-ES/MtView); Mani, Mahalingam (Mahalingam)=20 Cc: bwijnen@lucent.com Subject: question regarding Appendix Hi, Mani and Dorothy - =20 A question for you; what do we do with the vendor submissions currently = included in the Appendix section? Are we going to keep it as part of = RFC? That seems strange to me. I personally would like to see them removed, = because the quality of the text varies from vendor to vendor and we have = no control over it. .... It also = makes the text so much longer and scares people off reading it. =20 If we want to get rid of them eventually for RFC, we should do it in = v04. =20 Please advise.=20 =20 Lily ------_=_NextPart_001_01C47103.9A3ABFC4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good=20 idea.  I completely agree with you.  In fact I keep = meaning to=20 send mail you mail about removing it.  It has served its purpose by = allowing us to have access to the raw, original data if someone were=20 to challenge the results.  After 4 versions, I think we can = remove the=20 appendix.  Any questions regarding the data can be addressed = by any of=20 the DT members that are listed in the draft.   You are = right, I=20 think people do get intimidated when they see a 100 page document, and = we don't=20 want that when true document is only about 30 pages.
 
Does=20 the WG have any objections to removing the appendix?
 
Thanks-
Dorothy
 
 
 
-----Original Message-----
From: ext Yang, Lily L=20 [mailto:lily.l.yang@intel.com]
Sent: Friday, July 23, 2004 = 3:09=20 PM
To: Gellert Dorothy (Nokia-ES/MtView); Mani, Mahalingam=20 (Mahalingam)
Cc: bwijnen@lucent.com
Subject: = question=20 regarding Appendix

Hi, Mani and Dorothy=20 –

 

A question for you; what = do we do=20 with the vendor submissions currently included in the Appendix = section? Are we=20 going to keep it as part of RFC?

That=20 seems strange to me. I personally would like to see them removed, = because the=20 quality of the text varies from vendor to vendor and we have no = control over=20 it.  .... <some text removed for = readability>=20   It also makes the text so much longer and scares = people=20 off reading it.

 

 If we want to get = rid of=20 them eventually for RFC, we should do it in = v04.

 

Please advise.=20

 

Lily

= ------_=_NextPart_001_01C47103.9A3ABFC4-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Jul 25 03:04:33 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21250 for ; Sun, 25 Jul 2004 03:04:32 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1992E211DB; Sun, 25 Jul 2004 02:50:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72B9820A5D; Sun, 25 Jul 2004 02:50:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04707211DA for ; Sun, 25 Jul 2004 02:49:56 -0400 (EDT) Received: from 127.0.0.1 (fi-hs3509.zapsurf.com.sg [203.169.86.9]) by mail.frascone.com (Postfix) with SMTP id 1816020A5D for ; Sun, 25 Jul 2004 02:49:47 -0400 (EDT) From: "Cheng Hong" To: "'Pat R. Calhoun'" , Cc: "'Saravanan Govindan'" , "'Satoshi IINO'" , "'TAN, Pek-Yew'" Subject: RE: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt Organization: Panasonic Singapore Laboratories Message-ID: <000501c47215$8a079950$0956a9cb@Palpatine> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C47258.982AD950" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-GCMulti: 1 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 25 Jul 2004 15:03:45 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C47258.982AD950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pat, =20 Thanks a lot for the comments. Please see some reply inline: =20 1. Section 2.1: I have an issue with this proposal. The basic premise is that we cannot agree on a single model, so every vendor implements all possible combinations. First, I believe that the engineering resources required to design such = a box would be cost prohibitive. Second, the number of possible combination significantly increases the test conditions that must be performed by = the vendor. Third, it increases the code count on all devices - and the more code you have, the higher the potential for errors. I would like to understand the motivation behind this proposal. [[Cheng Hong]] I think it is quite obvious from the taxonomy draft that different vendors have their own split methods. Also, according the to discussion about "manageability" in the mailing list, different focus = could result in different conclusions. As you also mentioned later in this = mail that there are different customers aiming for different functions, I = don't think it would be easy for us to converge to one single split = architecture soon. And, it is almost impossible for a single way of split to meet all = the market requirements.=20 [[Cheng Hong]] In view of these, the proposal is to have the split implemented in a standard way, so that different split could work = together. This is not to ask every vendor to implement all possible combinations. = The motivation is quite simple: a customer are free to buy AC from any = vendor even if he has WTP from different sources. This should be the reason for forming this working group, I guess. One example of this, as described = in the draft, is that for an AC with function 1+2+3, it should be able to = work with WTP with function 2+3 and WTP with function 3, provided that 1+2+3 represents the whole MAC function. This is not asking every AC has too implement 1+2+3. Obviously, AC could only have 1+2, and it should also = work with WTP (2+3) and WTP (3). Here the requirement is that the AC to be implemented with module 1, 2, 3, and have well defined interface between them. (the actual implementation of the module is still up to the = vendors) I don't think it would increase the "code count" significantly. And this proposal is for the group to define the protocol to support the = interface between the modules. [[Cheng Hong]] As you had attended the last IEEE802 meeting, you may = already know that there is a AP function description SG formed there. With the = IEEE having a standard AP architecture defined, I think the above proposal becomes more reasonable: we won't expect "infinite" kinds of split. And therefore, we don't have to worried about the significantly increased = test conditions.=20 [[Cheng Hong]] So, again, the motivation is to free the customers from = being tied down to a vendor because he already has some equipments from it. (although that may be desired by vendors with big market share :) = [[Cheng Hong]] =20 2. Section 3.1: The statement that consumers and enterprises need the combined benefit of all architectures does not seem correct. Customers will = purchase a product that delivers the features and performance they require. It is not clear to me that this can only be met by supporting all possible architectures. [[Cheng Hong]] You are correct. The customer should have the choice. = That is what we are trying to achieve here. Since there are different ways of architecture for the split, user should be allowed to enjoy the benefits according to their needs. For example, a customer could have two = locations for the deployment, e.g. inside office, and outside in public area. = There would be different requirements for these two locations, and may be met = by different split architecture. The idea for the draft is that the = customer don't have to buy two AC to construct two different network for that, = and he don't have to buy expensive WTPs for both of the locations. A = interoperable design of the AC would allow the customer to have one AC to work with different split architecture, with different WTPs deployed in different locations. And again, this is not proposing the support of all possible architectures. (The customer could buy an AC that could just support = these two architectures) =20 3. Section 3.4: So my view is slightly different. Some customers want = the plug and play convenience of a layer 2 approach. Furthermore, the fact that the AP is = not IP addresseable significantly reduces the risk of attack. Meanwhile, = some customers prefer the flexibility of a layer 3 approach, since it = provides them with the ability to deploy their access points on various subnets, eliminating the network architectural restrictions associated with the layer 2 = approach. The security issue that is introduced with layer 3 can be overcome with a carefully designed implementation that is tested against a variety of network attacks. However, I believe that you will find customers in both camps. = Does this mean that the IETF has to care about what customers will want? I = guess it is up to us to decide. [[Cheng Hong]] Please see the comments above. It is exactly because of = the various customer needs, we need to have the interoperable architecture = so that we don't have to case about their individual requirements. We only = need to care about a few general scenarios. =20 4. Section 4.1: I disagree for the reasons listed above. 5. Section 4.2: But there are some additional deployment issues here = that we are ignoring, such as how to protect the data on the backhaul. Perhaps it is fine to state that this is out of scope for the WG. [[Cheng Hong]] Thanks for pointing out this. Yes. There are quite some other issues we haven't included into the draft. We are expecting to = find out more issues during the discussion. I think this would be a good practice, especially during our re-chartering time. We need to identify = the items for the next charter. Any requirement draft based on the taxonomy draft would help a lot. This draft is just some effort from us towards = that direction.=20 =20 6. Section 4.4: QoS can be achieved via other means, such as DS or = 802.1P, and therefore there is not necessarily a need for sub-data channels. [[Cheng Hong]] There are different ways of providing the QoS and = security. Comparing to pure 802.1P, the sub-data channel could have a more = extensible and clean way of achieving the goal. There are also some references to = the channel separations in the Taxonomy submissions. Maybe we could have a thorough analysis of this in the future drafts. =20 cheers =20 Cheng Hong ------=_NextPart_000_0006_01C47258.982AD950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Pat,
 
Thanks=20 a lot for the comments. Please see some reply = inline:
<snip> 
1. = Section 2.1: I=20 have an issue with this proposal. The basic premise is that we = cannot
agree=20 on a single model, so every vendor implements all possible=20 combinations.
First, I believe that the engineering resources = required to=20 design such a box
would be cost prohibitive. Second, the number of = possible=20 combination
significantly increases the test conditions that must = be=20 performed by the
vendor. Third, it increases the code count on all = devices=20 - and the more code
you have, the higher the potential for = errors.

I=20 would like to understand the motivation behind this = proposal.

[[Cheng = Hong]] I=20 think it is quite obvious from the taxonomy draft that different=20 vendors have their own split methods. Also, according the to = discussion=20 about "manageability" in the mailing list, different focus could = result in=20 different conclusions. As you also mentioned later in this mail that = there are=20 different customers aiming for different functions, I don't think it = would be=20 easy for us to converge to one single split architecture = soon. And,=20 it is almost impossible for a single way of split to meet all the = market=20 requirements. 

[[Cheng=20 Hong]]  In view of these, the proposal is to have the split=20 implemented in a standard way, so that different split could work = together.=20 This is not to ask every vendor to implement all possible = combinations. The=20 motivation is quite simple: a customer are free to buy AC from any = vendor even=20 if he has WTP from different sources. This should be the reason for = forming=20 this working group, I guess. One example of this, as described in the = draft,=20 is that for an AC with function 1+2+3, it should be able to work with = WTP with=20 function 2+3 and WTP with function 3, provided that 1+2+3 represents = the whole=20 MAC function. This is not asking every AC has too implement 1+2+3. = Obviously,=20 AC could only have 1+2, and it should also work with WTP (2+3) and WTP = (3).=20 Here the requirement is that the AC to be implemented with module 1, = 2, 3, and=20 have well defined interface between them. (the actual implementation = of the=20 module is still up to the vendors) I don't think it would = increase the=20 "code count" significantly. And this proposal is for the group to = define=20 the protocol to support the interface between the=20 modules.

[[Cheng=20 Hong]] As you had attended the last IEEE802 meeting, you may = already know=20 that there is a AP function description SG formed there. =  With the=20 IEEE having a standard AP architecture defined, I think the above = proposal=20 becomes more reasonable: we won't expect "infinite" kinds of split. = And=20 therefore, we don't have to worried about the significantly increased = test=20 conditions.

[[Cheng=20 Hong]] So, again, the motivation is to free the customers = from being=20 tied down to a vendor because he already has some equipments = from=20 it. (although that may be desired by vendors with big market = share=20 :) [[Cheng Hong]]  

2. = Section 3.1:=20 The statement that consumers and enterprises need the = combined
benefit of=20 all architectures does not seem correct. Customers will purchase
a = product=20 that delivers the features and performance they require. It is
not = clear to=20 me that this can only be met by supporting all=20 possible
architectures.

[[Cheng Hong]] You are correct. The = customer=20 should have the choice. That is what we are trying to achieve here. = Since=20 there are different ways of architecture for the split, user should be = allowed=20 to enjoy the benefits according to their needs. For example, a = customer could=20 have two locations for the deployment, e.g. inside office, and outside = in=20 public area. There would be different requirements for these two = locations,=20 and may be met by different split architecture. The idea for the draft = is that=20 the customer  don't have to buy two AC to construct two different = network=20 for that, and he don't have to buy expensive WTPs for both of the = locations. A=20 interoperable design of the AC would allow the customer to have one AC = to work=20 with different split architecture, with different WTPs deployed in = different=20 locations.  And again, this is not proposing the support of all = possible=20 architectures. (The customer could buy an AC that could just support = these two=20 architectures)
 

3. Section 3.4: = So my view is=20 slightly different. Some customers want the plug and = play
convenience of a=20 layer 2 approach. Furthermore, the fact that the AP is not
IP = addresseable=20 significantly reduces the risk of attack. Meanwhile, some
customers = prefer=20 the flexibility of a layer 3 approach, since it provides them
with = the=20 ability to deploy their access points on various subnets, = eliminating
the=20 network architectural restrictions associated with the layer 2=20 approach.

The security issue that is introduced with layer 3 = can be=20 overcome with
a carefully designed implementation that is tested = against a=20 variety of network
attacks. However, I believe that you will find = customers=20 in both camps. Does
this mean that the IETF has to care about what=20 customers will want? I guess it
is up to us to decide.

[[Cheng=20 Hong]] Please see the comments above. It is exactly because of = the=20 various customer needs, we need to have the interoperable architecture = so that=20 we don't have to case about their individual requirements. We = only need=20 to care about a few general scenarios. =  

4.=20 Section 4.1: I disagree for the reasons listed above.


5. = Section=20 4.2: But there are some additional deployment issues here that we=20 are
ignoring, such as how to protect the data on the backhaul. = Perhaps it=20 is fine
to state that this is out of scope for the WG.

[[Cheng=20 Hong]]  Thanks for pointing out this. Yes. There are quite = some=20 other issues we haven't included into the draft. We are expecting = to find out more issues during the discussion. I think this would = be a=20 good practice, especially during our re-chartering time. We need=20 to identify the items for the next charter. Any requirement draft = based=20 on the taxonomy draft would help a lot. This draft is just = some=20 effort from us towards that = direction. 
  

6. Section 4.4: QoS = can be=20 achieved via other means, such as DS or 802.1P, and therefore
there = is not=20 necessarily a need for sub-data channels.


[[Cheng=20 Hong]] There are different ways of providing the QoS and = security.=20 Comparing to pure 802.1P, the sub-data channel could have a more = extensible=20 and clean way of achieving the goal. There are also some = references to=20 the channel separations in the Taxonomy submissions. Maybe we = could have=20 a thorough analysis of this in the future=20 drafts.
 
 cheers
 
Cheng=20 Hong
------=_NextPart_000_0006_01C47258.982AD950-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Jul 25 04:49:29 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25748 for ; Sun, 25 Jul 2004 04:49:29 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7FE3211FF; Sun, 25 Jul 2004 04:35:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFAA62120A; Sun, 25 Jul 2004 04:35:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 183B62120A for ; Sun, 25 Jul 2004 04:34:15 -0400 (EDT) Received: from aruba-server.arubanetworks.com (mail.arubanetworks.com [64.60.249.195]) by mail.frascone.com (Postfix) with SMTP id 2AA90211FF for ; Sun, 25 Jul 2004 04:34:13 -0400 (EDT) Received: from FATCAT ([10.202.10.44]) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Jul 2004 01:48:29 -0700 Message-ID: <072301c47224$cc16c550$020aa8c0@FATCAT> From: "Randy Chou" To: "Cheng Hong" , "Pat R. Calhoun" , Cc: "Saravanan Govindan" , "Satoshi IINO" , "TAN, Pek-Yew" , "Randy Chou" References: <000501c47215$8a079950$0956a9cb@Palpatine> Subject: Re: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 25 Jul 2004 08:48:29.0671 (UTC) FILETIME=[287A4F70:01C47224] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 25 Jul 2004 01:53:03 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think we should keep all the different models but also specifically list out important features that are expected to function properly given 1+2 and 2+3. If history is any indication from other IETF WGs, we'll have an AC and a WTP where the only working feature is static WEP :). I don't think consumers will be too happy about that. If a vendor supports a certain set of models, I'd like to see that such models have clearly defined functions and boundaries that don't only work with the vendor's native model. Regards, -- Randy ----- Original Message ----- From: "Cheng Hong" To: "Pat R. Calhoun" ; Cc: "Saravanan Govindan" ; "Satoshi IINO" ; "TAN, Pek-Yew" Sent: Sunday, July 25, 2004 12:03 AM Subject: RE: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt Hi Pat, Thanks a lot for the comments. Please see some reply inline: 1. Section 2.1: I have an issue with this proposal. The basic premise is that we cannot agree on a single model, so every vendor implements all possible combinations. First, I believe that the engineering resources required to design such a box would be cost prohibitive. Second, the number of possible combination significantly increases the test conditions that must be performed by the vendor. Third, it increases the code count on all devices - and the more code you have, the higher the potential for errors. I would like to understand the motivation behind this proposal. [[Cheng Hong]] I think it is quite obvious from the taxonomy draft that different vendors have their own split methods. Also, according the to discussion about "manageability" in the mailing list, different focus could result in different conclusions. As you also mentioned later in this mail that there are different customers aiming for different functions, I don't think it would be easy for us to converge to one single split architecture soon. And, it is almost impossible for a single way of split to meet all the market requirements. [[Cheng Hong]] In view of these, the proposal is to have the split implemented in a standard way, so that different split could work together. This is not to ask every vendor to implement all possible combinations. The motivation is quite simple: a customer are free to buy AC from any vendor even if he has WTP from different sources. This should be the reason for forming this working group, I guess. One example of this, as described in the draft, is that for an AC with function 1+2+3, it should be able to work with WTP with function 2+3 and WTP with function 3, provided that 1+2+3 represents the whole MAC function. This is not asking every AC has too implement 1+2+3. Obviously, AC could only have 1+2, and it should also work with WTP (2+3) and WTP (3). Here the requirement is that the AC to be implemented with module 1, 2, 3, and have well defined interface between them. (the actual implementation of the module is still up to the vendors) I don't think it would increase the "code count" significantly. And this proposal is for the group to define the protocol to support the interface between the modules. [[Cheng Hong]] As you had attended the last IEEE802 meeting, you may already know that there is a AP function description SG formed there. With the IEEE having a standard AP architecture defined, I think the above proposal becomes more reasonable: we won't expect "infinite" kinds of split. And therefore, we don't have to worried about the significantly increased test conditions. [[Cheng Hong]] So, again, the motivation is to free the customers from being tied down to a vendor because he already has some equipments from it. (although that may be desired by vendors with big market share :) [[Cheng Hong]] 2. Section 3.1: The statement that consumers and enterprises need the combined benefit of all architectures does not seem correct. Customers will purchase a product that delivers the features and performance they require. It is not clear to me that this can only be met by supporting all possible architectures. [[Cheng Hong]] You are correct. The customer should have the choice. That is what we are trying to achieve here. Since there are different ways of architecture for the split, user should be allowed to enjoy the benefits according to their needs. For example, a customer could have two locations for the deployment, e.g. inside office, and outside in public area. There would be different requirements for these two locations, and may be met by different split architecture. The idea for the draft is that the customer don't have to buy two AC to construct two different network for that, and he don't have to buy expensive WTPs for both of the locations. A interoperable design of the AC would allow the customer to have one AC to work with different split architecture, with different WTPs deployed in different locations. And again, this is not proposing the support of all possible architectures. (The customer could buy an AC that could just support these two architectures) 3. Section 3.4: So my view is slightly different. Some customers want the plug and play convenience of a layer 2 approach. Furthermore, the fact that the AP is not IP addresseable significantly reduces the risk of attack. Meanwhile, some customers prefer the flexibility of a layer 3 approach, since it provides them with the ability to deploy their access points on various subnets, eliminating the network architectural restrictions associated with the layer 2 approach. The security issue that is introduced with layer 3 can be overcome with a carefully designed implementation that is tested against a variety of network attacks. However, I believe that you will find customers in both camps. Does this mean that the IETF has to care about what customers will want? I guess it is up to us to decide. [[Cheng Hong]] Please see the comments above. It is exactly because of the various customer needs, we need to have the interoperable architecture so that we don't have to case about their individual requirements. We only need to care about a few general scenarios. 4. Section 4.1: I disagree for the reasons listed above. 5. Section 4.2: But there are some additional deployment issues here that we are ignoring, such as how to protect the data on the backhaul. Perhaps it is fine to state that this is out of scope for the WG. [[Cheng Hong]] Thanks for pointing out this. Yes. There are quite some other issues we haven't included into the draft. We are expecting to find out more issues during the discussion. I think this would be a good practice, especially during our re-chartering time. We need to identify the items for the next charter. Any requirement draft based on the taxonomy draft would help a lot. This draft is just some effort from us towards that direction. 6. Section 4.4: QoS can be achieved via other means, such as DS or 802.1P, and therefore there is not necessarily a need for sub-data channels. [[Cheng Hong]] There are different ways of providing the QoS and security. Comparing to pure 802.1P, the sub-data channel could have a more extensible and clean way of achieving the goal. There are also some references to the channel separations in the Taxonomy submissions. Maybe we could have a thorough analysis of this in the future drafts. cheers Cheng Hong _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 27 17:06:34 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13673 for ; Tue, 27 Jul 2004 17:06:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91E37204C4; Tue, 27 Jul 2004 16:52:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2751320833; Tue, 27 Jul 2004 16:52:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 530E520833 for ; Tue, 27 Jul 2004 16:51:11 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 6008E204C4 for ; Tue, 27 Jul 2004 16:51:09 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6RL6B32012473; Tue, 27 Jul 2004 21:06:13 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6RL6SFV020615; Tue, 27 Jul 2004 21:06:39 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072714043611721 ; Tue, 27 Jul 2004 14:04:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Jul 2004 14:04:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4741D.4D169788" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01836F65@orsmsx408> Thread-Topic: question regarding Appendix Thread-Index: AcRxAbkfoDeaGkHIR7O6c7gBS7XY1gAAHYnQAMa7jhA= From: "Yang, Lily L" To: , Cc: , X-OriginalArrivalTime: 27 Jul 2004 21:04:27.0766 (UTC) FILETIME=[4D946160:01C4741D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: question regarding Appendix Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Jul 2004 14:04:26 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4741D.4D169788 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So far I have not heard any objection to this idea, then I am going to remove all the survey submissions from the draft for v04. =20 Lily ________________________________ From: Dorothy.Gellert@nokia.com [mailto:Dorothy.Gellert@nokia.com]=20 Sent: Friday, July 23, 2004 3:23 PM To: Yang, Lily L; mmani@avaya.com Cc: bwijnen@lucent.com; capwap@frascone.com Subject: RE: question regarding Appendix =09 =09 Good idea. I completely agree with you. In fact I keep meaning to send mail you mail about removing it. It has served its purpose by allowing us to have access to the raw, original data if someone were to challenge the results. After 4 versions, I think we can remove the appendix. Any questions regarding the data can be addressed by any of the DT members that are listed in the draft. You are right, I think people do get intimidated when they see a 100 page document, and we don't want that when true document is only about 30 pages. =20 Does the WG have any objections to removing the appendix? =20 Thanks- Dorothy =20 =20 =20 -----Original Message----- From: ext Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Friday, July 23, 2004 3:09 PM To: Gellert Dorothy (Nokia-ES/MtView); Mani, Mahalingam (Mahalingam)=20 Cc: bwijnen@lucent.com Subject: question regarding Appendix =09 =09 Hi, Mani and Dorothy - =20 A question for you; what do we do with the vendor submissions currently included in the Appendix section? Are we going to keep it as part of RFC? That seems strange to me. I personally would like to see them removed, because the quality of the text varies from vendor to vendor and we have no control over it. .... It also makes the text so much longer and scares people off reading it. =20 If we want to get rid of them eventually for RFC, we should do it in v04. =20 Please advise.=20 =20 Lily ------_=_NextPart_001_01C4741D.4D169788 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So far I have not heard any objection to this = idea, then I=20 am going to remove all the survey submissions from the draft for=20 v04.
 
Lily

From: Dorothy.Gellert@nokia.com=20 [mailto:Dorothy.Gellert@nokia.com]
Sent: Friday, July 23, = 2004 3:23=20 PM
To: Yang, Lily L; mmani@avaya.com
Cc:=20 bwijnen@lucent.com; capwap@frascone.com
Subject: RE: = question=20 regarding Appendix

Good=20 idea.  I completely agree with you.  In fact I keep = meaning to=20 send mail you mail about removing it.  It has served its purpose = by=20 allowing us to have access to the raw, original data if someone were=20 to challenge the results.  After 4 versions, I think we can = remove=20 the appendix.  Any questions regarding the data can be = addressed by=20 any of the DT members that are listed in the = draft.   You are=20 right, I think people do get intimidated when they see a 100 page = document,=20 and we don't want that when true document is only about 30=20 pages.
 
Does=20 the WG have any objections to removing the = appendix?
 
Thanks-
Dorothy
 
 
 
-----Original Message-----
From: ext Yang, Lily L = [mailto:lily.l.yang@intel.com]
Sent: Friday, July 23, 2004 = 3:09=20 PM
To: Gellert Dorothy (Nokia-ES/MtView); Mani, Mahalingam = (Mahalingam)
Cc: bwijnen@lucent.com
Subject: = question=20 regarding Appendix

Hi, Mani and Dorothy=20 –

 

A question for you; = what do we=20 do with the vendor submissions currently included in the Appendix = section?=20 Are we going to keep it as part of RFC?

That=20 seems strange to me. I personally would like to see them removed, = because=20 the quality of the text varies from vendor to vendor and we have no = control=20 over it.  .... <some text removed for = readability>=20   It also makes the text so much longer and = scares people=20 off reading it.

 

 If we want to = get rid of=20 them eventually for RFC, we should do it in=20 v04.

 

Please advise.=20

 

Lily

<= /BODY> ------_=_NextPart_001_01C4741D.4D169788-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Jul 27 17:45:36 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15390 for ; Tue, 27 Jul 2004 17:45:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D54D920D2F; Tue, 27 Jul 2004 17:31:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F55920D30; Tue, 27 Jul 2004 17:31:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8A6120D30 for ; Tue, 27 Jul 2004 17:30:48 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id B7FA520D2F for ; Tue, 27 Jul 2004 17:30:45 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6RLka32003348; Tue, 27 Jul 2004 21:46:36 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6RLej2h011990; Tue, 27 Jul 2004 21:40:46 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072714450309347 ; Tue, 27 Jul 2004 14:45:03 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Jul 2004 14:45:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47422.F8D1D22E" Subject: RE: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01836F67@orsmsx408> Thread-Topic: [Capwap] Comments on draft-ietf-capwap-arch-03.txt Thread-Index: AcRlFnioUmajvm3FSbiqICHTxvFYCAL51U3w From: "Yang, Lily L" To: "Pat R. Calhoun" , X-OriginalArrivalTime: 27 Jul 2004 21:45:03.0086 (UTC) FILETIME=[F924B8E0:01C47422] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 27 Jul 2004 14:45:02 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47422.F8D1D22E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Pat - see below some suggestions for draft change to address your comments. Let me know if you have further comments and if you don't like what you read here.=20 We plan to get v04 out soon to incorporate the comments from you and others since v03. =20 Lily =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Thursday, July 08, 2004 11:08 AM To: capwap@frascone.com Subject: [Capwap] Comments on draft-ietf-capwap-arch-03.txt =20 =20 First, I'd like to applaud the authors on a job well done. It is clear in reading this spec that there was a significant amount of data to work with... I am very impressed with the document. 1. Section 1.3. "Typically ," -> "Typically, " [Lily] Thanks. 2. This section defines the AP as terminating the 802.11 PHY, but it should be noted that this device also terminates the 802.11 MAC mgmt layer, which is not specified. [Lily] We would like to use "WTP" in all centralized architecture instances including remote MAC, so the lowest common denominator is terminating PHY. So I am inclined to leave it like that. 3. The definition of Split MAC implies that all MAC mgmt is handled in the AC, but in certain implementations this is not true. The MAC mgmt packets that have very tight timing requirements can be handled in the WTP. [Lily] You are right. Figure 10 shows that most but not all vendors terminate MAC mgmt packets at AC. So we can change the definition of "Split MAC" in 1.3 from "...implement the delay sensitive MAC services (like the control frame processing) for IEEE 802.11, while tunneling all the management and data frames to AC for centralized processing." to "...implement the delay sensitive MAC services (including all control frames and some management frames) for IEEE 802.11, while tunneling all the remaining management and data frames to AC for centralized processing." 4. Page 14. The text reads 14 contributions, yet above 16 is mentioned. [Lily] It should be 16. We will fix 2.4, in the middle of first paragraph "13 of them are from WLAN vendors" to "15 of them are from WLAN vendors". And the second last paragraph: from "11 out of 14" to "11 out of 16". 5. Section 3.2. Another security issue is the very fact that this device is most likely not under lock and key, but does contain secret information in order to communicate with the backend systems, such as AAA, SNMP, etc. Due to the common management method used by IT personel of pushing a "template" to all similar devices, theft of such a device would compromise the wired network. [Lily] Yes, the text in 3.2 alluded to it but I agree that this point should be made more explicitly.=20 Old text reads "As per problem #4 in [2], the only security issue in this architecture is mutual authentication between the WTP and the Ethernet infrastructure to ensure that WTPs cannot be easily stole and deployed in unprotected networks. This can be ensured by existing mechanisms such as, for instance, 802.1x between the WTP and the Ethernet switch it plugs into."=20 Suggested new text: "One of the security issues in this architecture is the need for mutual authentication between the WTP and the Ethernet infrastructure. This can be ensured by existing mechanisms such as, 802.1x between the WTP and the Ethernet switch it plugs into. Another critical security issue with this architecture is the very fact that the WTP is most likely not under lock and key, but does contain secret information in order to communicate with the backend systems, such as AAA, SNMP, etc. Due to the common management method used by IT personel of pushing a "template" to all similar devices, theft of such a device would compromise the wired network.=20 5. A Network Management Station (NMS) should not be considered as part of the Access Controller. While most controllers will provide one or more management interfaces, a system that is used to scale a global network generally resides on a separate system. [Lily] So far , we tend to talk about WLAN "management, control and configuration" all in one breath, and I think logically and it seems more natural to include the management functionality in AC. Architecturally it is also cleaner. Another way to look at this is that from WTP's point of view, AC is all they need to know to gain access to all the "management, control and config" functions for the network. So what it really means is that AC provides interface to all these services, including SNMP, AAA. It doesn't necessarily mean AC itself has to implement all these in one physical box. It is very reasonable to have a separete backend SNMP manager, and another AAA server. Therefore, SNMP and Radius protocol can co-exist and complement the to-be-developed CAPWAP protocol.=20 6. Page 25. The list of real-time features should probably include Power Save handling. [Lily] PS-Poll is included in "Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK". Is that what you mean? Keep in mind that there is no clear definition of what real time features are exactly, and so what we list here are "examples", not exhaustive and definitive list. 7. Section 4.5. Could the authors please explain how they came to the conclusion that Remote MAC "improves WTP manageability"? [Lily] What we really meant here is that Remote MAC "improves WTP manageability over autonomous architecture". We didn't intend to state that it "improves WTP manageability over local or split MAC". Since it causes lots of confusion here, I suggest we simply delete the ", and improves WTP manageability" from the first paragraph of 4.5. As the debate over mailing list shows that manageability is a vague concept, we have tried very hard to restraint from making sweeping value judgment statements. There are many factors in play here and it is very hard to say X is definetely better than Y, without taking into account the deployment scenarios and specific requirements. =20 8. Page 30. The term "Integration Service" is used as a substitute to bringing function. However, the terminology section called this function "portal". We should stick to a single term throughout the document. [Lily] Both terms are used commonly in IEEE and my take is that "Integration" is a service, while "Portal" is a logical point where that service gets invoked. So one of them may be more appropriate in certain sentences than the other. I think that should be ok. 9. Page 33, second to last paragraph, there is a non traditional character in the line that starts with "every mesh node..." 10. Section 5.1. If stations (or non-trusted equipment) are allowed to become part of the mesh backbone, end to end security is required otherwise users traffic will be compromised. 11. Page 45. The URL for the LWAPP draft has changed and the one listed has expired. Does it make sense to update it? 12. General comment. I understand that there was a desire to mask the vendor in the appendices, but I wonder whether this makes sense. The primary issue moving forward is that this is (and will) be known to people on the list (or reading he archives) [Lily] Yes, this has been public knowledge (on the list). But as a standalone RFC document which this draft eventually would become, I think it is more in the vendor-agnostic IETF spirit to leave the specific vendor info out. As I said in a separate email, we would like to remove all the survey data out of the draft in this new revision. 13. Appendix C. We really should discourage baseless marketing claims like "secure, scalable, large scale WLAN deployments" unless one intends to back this up with facts. I'm quite certain that no submittal was intended for the home user. 14. Appendix D, Page 52. Seems like spelling rogue as "rouge" is a common mistake. May want to search/replace. 15. Appendix D, question 4. Could the submitter be a tad more specific than "IP Tunnel". For instance, is there a control protocol to setup the tunnels, etc. 16. Appendix D, question 5. Probably too late now, but I really question how these claims can be made given the rather brief data - so we just have to assume the claims are true. 17. Appendix E. Good write-up! 18. Appendix F. I have a question for the author, but this is purely asked due to curiosity. In a home environment, you seem to imply that there is a single set top box, and that you can provide dynamic power assignment, but I wonder how you can do that with a single antenna - you need a clear view of the whole space that needs to be covered. 19. Appendix F, section 9. The paragraph states that the PHY and MAC association services are handled in the STB, and other MAC services are in the controller. Is it possible to get a breakdown or at least an understanding of what the other services being provided are? 20. Appendix L. I am curious about the fact that this architecture is completely agnostic of the PHY, yet it can provide such functions as centralized RF management (which cannot be performed if one has no idea what they are dealing with). [Lily] I would not be able to address any of the comments for the individual submissions as these are not part of the draft. We will remove all these Appendix sections in the final document. ------_=_NextPart_001_01C47422.F8D1D22E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on = draft-ietf-capwap-arch-03.txt

Hi, Pat = – see below=20 some suggestions for draft change to address your comments. Let me=20 know if you have further comments = and if you=20 don't like what you read here.

We plan to = get v04=20 out soon to incorporate the comments from you and = others=20 since v03.

 

Lily

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat R. = Calhoun
Sent: Thursday, July 08, 2004 = 11:08=20 AM
To:=20 capwap@frascone.com
Subject:=20 [Capwap] Comments on=20 draft-ietf-capwap-arch-03.txt

 

 

First, I'd like to applaud the = authors on a job=20 well done. It is clear in reading this spec that there was a significant = amount=20 of data to work with... I am very impressed with the document.

1. = Section=20 1.3. "Typically ," -> "Typically, = "
[Lily] Thanks.


2. This section = defines the AP=20 as terminating the 802.11 PHY, but it should be noted that this device = also=20 terminates the
802.11 MAC mgmt layer, which is not specified.

[Lily] We = would like to=20 use “WTP” in all centralized architecture instances = including remote MAC, so the=20 lowest common denominator is terminating PHY. So I am inclined to leave = it like=20 that.


3. The=20 definition of Split MAC implies that all MAC mgmt is handled in the AC, = but in=20 certain implementations this is not true. The MAC mgmt packets that have = very=20 tight timing requirements can be handled in the WTP.

[Lily] You = are right.=20 Figure 10 shows that most but not all vendors terminate MAC mgmt packets = at AC.=20 So we can change the definition of “Split MAC” in 1.3 from = “…implement the delay=20 sensitive MAC services (like the control frame processing) for IEEE = 802.11,=20 while tunneling all the management and data frames to AC for centralized = processing.” to “…implement the delay sensitive MAC = services (including all=20 control frames and some management frames) for IEEE 802.11, while = tunneling all=20 the remaining management and data frames to AC for centralized=20 processing.”

4.=20 Page 14. The text reads 14 contributions, yet above 16 is = mentioned.

[Lily] It = should be 16.=20 We will fix 2.4, in the middle of first paragraph “13 of them are = from WLAN=20 vendors” to “15 of them are from WLAN = vendors”.

And the = second last=20 paragraph: from “11 out of 14” to “11 out of = 16”.


5.=20 Section 3.2. Another security issue is the very fact that this device is = most=20 likely not under lock and key, but does contain secret information in = order to=20 communicate with the backend systems, such as AAA, SNMP, etc. Due to the = common=20 management method used by IT personel of pushing a "template" to all = similar=20 devices, theft of such a device would compromise the wired network.

[Lily] Yes,=20 the text in 3.2 alluded to it but = I agree=20 that this point should be made more = explicitly. 

 Old text=20 reads "As per = problem #4 in=20 [2], the only security issue in this architecture is mutual=20 authentication between the WTP and the Ethernet infrastructure to = ensure=20 that WTPs cannot be easily stole and deployed in = unprotected=20 networks.  This can be ensured by existing mechanisms such = as, for=20 instance, 802.1x between the WTP and the Ethernet switch = it plugs=20 into."

Suggested new text: "One of = the security issues=20 in this architecture is=20 the need for mutual authentication between the WTP and the Ethernet = infrastructure.  This can be = ensured by=20 existing = mechanisms=20 such as, 802.1x between the WTP and the Ethernet switch = it plugs=20 into. Another critical security issue with this architecture is = the very=20 fact that the WTP is most likely not under lock and key, = but does=20 contain secret information in order to communicate with the backend = systems,=20 such as AAA, SNMP, etc. Due to the common management method used by IT = personel=20 of pushing a "template" to all similar devices, theft of such a device = would=20 compromise the wired network.


5. A Network=20 Management Station (NMS) should not be considered as part of the Access=20 Controller. While most controllers will provide one or more management=20 interfaces, a system that is used to scale a global network generally = resides on=20 a separate system.

[Lily] So far , we tend to talk about WLAN = "management,=20 control and configuration" all in one breath, and I think logically and = it seems=20 more natural to include the management functionality in AC. = Architecturally it=20 is also cleaner. Another way to look at this is that from = WTP's point=20 of view, AC is all they need to know to gain access to all the = "management,=20 control and config" functions for the network. So what it really means = is that=20 AC provides interface to all these services, including SNMP, AAA. It = doesn't=20 necessarily mean AC itself has to implement all these in one physical = box. It is=20 very reasonable to have a separete backend SNMP manager, and another AAA = server.=20 Therefore, SNMP and Radius protocol can co-exist and complement the=20 to-be-developed CAPWAP protocol.


6. Page 25. The list of real-time features should probably = include Power=20 Save handling.

[Lily] = PS-Poll is=20 included in “Processing of Control Frames: = RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK”.=20 Is that what you mean?

Keep in mind = that there=20 is no clear definition of what real time features are exactly, and so = what we=20 list here are “examples”, not exhaustive and definitive = list.

7. Section 4.5. Could = the authors=20 please explain how they came to the conclusion that Remote MAC "improves = WTP=20 manageability"?

[Lily] What = we really=20 meant here is that Remote MAC "improves WTP manageability over autonomous=20 architecture”. We didn’t intend to state that it "improves = WTP manageability=20 over local or split MAC”. Since it causes=20 lots of confusion here, I suggest we simply delete the ", = and=20 improves WTP manageability" from the first paragraph of=20 4.5.

As the=20 debate over mailing list shows that manageability is a vague=20 concept, we have = tried very hard to restraint from = making=20 sweeping value judgment statements. There are many factors in play here = and=20 it is very hard to say X is = definetely=20 better than Y, without taking into account the deployment scenarios and specific=20 requirements.   

8. Page 30. The term "Integration = Service" is=20 used as a substitute to bringing function. However, the terminology = section=20 called this function "portal". We should stick to a single term = throughout the=20 document.

[Lily] Both = terms are=20 used commonly in IEEE and my take is that “Integration” is a = service, while=20 “Portal” is a logical point where that service gets invoked. = So one of them may be more appropriate in certain = sentences than the=20 other. I think that should be ok.



9.=20 Page 33, second to last paragraph, there is a non traditional character = in the=20 line that starts with "every mesh node..."

10. Section 5.1. If = stations=20 (or non-trusted equipment) are allowed to become part of the mesh = backbone, end=20 to end security is required otherwise users traffic will be=20 compromised.

11. Page 45. The URL for the LWAPP draft has changed = and the=20 one listed has expired. Does it make sense to update it?

12. = General=20 comment. I understand that there was a desire to mask the vendor in the=20 appendices, but I wonder whether this makes sense. The primary issue = moving=20 forward is that this is (and will) be known to people on the list (or = reading he=20 archives)

[Lily] Yes,=20 this has been public knowledge (on the list). But as a standalone RFC = document=20 which this draft eventually would become, I think it is more in the=20 vendor-agnostic IETF spirit to leave the specific vendor info = out. As I said in a separate email, we would like = to remove=20 all the survey data out of the draft in this new = revision.


13.=20 Appendix C. We really should discourage baseless marketing claims like = "secure,=20 scalable, large scale WLAN deployments" unless one intends to back this = up with=20 facts. I'm quite certain that no submittal was intended for the home=20 user.

14. Appendix D, Page 52. Seems like spelling rogue as = "rouge" is a=20 common mistake. May want to search/replace.

15. Appendix D, = question 4.=20 Could the submitter be a tad more specific than "IP Tunnel". For = instance, is=20 there a control protocol to setup the tunnels, etc.

16. Appendix = D,=20 question 5. Probably too late now, but I really question how these = claims can be=20 made given the rather brief data - so we just have to assume the claims = are=20 true.

17. Appendix E. Good write-up!

18. Appendix F. I = have a=20 question for the author, but this is purely asked due to curiosity. In a = home=20 environment, you seem to imply that there is a single set top box, and = that you=20 can provide dynamic power assignment, but I wonder how you can do that = with a=20 single antenna - you need a clear view of the whole space that needs to = be=20 covered.

19. Appendix F, section 9. The paragraph states that the = PHY and=20 MAC association services are handled in the STB, and other MAC services = are in=20 the controller. Is it possible to get a breakdown or at least an = understanding=20 of what the other services being provided are?

20. Appendix L. I = am=20 curious about the fact that this architecture is completely agnostic of = the PHY,=20 yet it can provide such functions as centralized RF management (which = cannot be=20 performed if one has no idea what they are dealing with).

[Lily] I would=20 not be able to address any = of the=20 comments for the individual = submissions as these are not part of = the=20 draft. We will = remove all=20 these Appendix sections in the final=20 document.

------_=_NextPart_001_01C47422.F8D1D22E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jul 29 14:22:38 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29532 for ; Thu, 29 Jul 2004 14:22:37 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54BF91FF8B; Thu, 29 Jul 2004 14:08:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FD1720693; Thu, 29 Jul 2004 14:08:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 00B5220693 for ; Thu, 29 Jul 2004 14:07:56 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 959741FF8B for ; Thu, 29 Jul 2004 14:07:53 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TINoHE005336 for ; Thu, 29 Jul 2004 18:23:50 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TIO7VJ016125 for ; Thu, 29 Jul 2004 18:24:18 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072911220506029 for ; Thu, 29 Jul 2004 11:22:05 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jul 2004 11:21:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47598.D11CD868" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01A80CBC@orsmsx408> Thread-Topic: CAPWAP Architecture Taxonomy v04 is ready for WG review Thread-Index: AcR1mNDYWiKihHcpTROGSdNcff+DwQ== From: "Yang, Lily L" To: X-OriginalArrivalTime: 29 Jul 2004 18:21:08.0724 (UTC) FILETIME=[D1B8BB40:01C47598] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG review Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 29 Jul 2004 11:21:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C47598.D11CD868 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all - =20 V04 of the CAPWAP Architecture Taxonomy is ready for WG review and we also like to request WG last call on it. Please check it out here at: http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-04.txt, before it is available through IETF repository. =20 This revision is mostly motivated by the comments posted by Pat and the discussions afterward on the mailing list. We also took this opportunity to remove all the appendix data and hence greatly shortened the length of the document to only 40 pages long now.=20 =20 V04 is a minor revision over 03, with mostly clarification changes, and a few corrections. To help you review the document, I provide a detailed change log from v03 to v04 below.=20 =20 The Design Team feel the taxonomy document has been matured a lot since last IETF meeting, and has been thoroughly reviewed by both IEEE 802.11 and IETF members since May, and we feel that it is ready for WG last call.=20 =20 Thanks, =20 Lily (Editor) =20 =20 --------------------- Detailed change log from v03 to v04 ------------ =20 In the rough order of significance:=20 =20 1) Section 1.3 "Terminology Used in this Document" For "Split MAC Architecture":=20 [old]"...implement the delay sensitive MAC services (like the control frame processing) for IEEE 802.11, while tunneling all the management and data frames to AC for centralized processing." =20 [new]"...implement the delay sensitive MAC services (including all control frames and some management frames) for IEEE 802.11, while tunneling all the remaining management and data frames to AC for centralized processing." =20 2) Section 3.2 "Security" (note: for autonomous architecture) [old]"As per problem #4 (in problem statement), the only security issue in this architecture is mutual authentication between the WTP and the Ethernet infrastructure to ensure that WTPs cannot be easily stolen and deployed in unprotected networks. This can be ensured by existing mechanisms such as, for instance, 802.1x between the WTP and the Ethernet switch it plugs into." =20 [new]One of the security issues in this architecture is the need for mutual authentication between the WTP and the Ethernet infrastructure. This can be ensured by existing mechanisms such as, 802.1x between the WTP and the Ethernet switch it plugs into. Another security issue with this architecture is the very fact that the WTP is most likely not under lock and key, but does contain secret information in order to communicate with the backend systems, such as AAA, SNMP, etc. Due to the common management method used by IT personel of pushing a "template" to all similar devices, theft of such a device would potentially compromise the wired network.=20 =20 3) Section 4 "Centralized WLAN Architecture":=20 At the end of first paragraph, delete "A Network Management Station can be considered part of the Access Controller, but typically the latter contains additional functionality beyond that of the former. " =20 Instead, add the following to the end of last paragraph "The AC(s) may also choose to implement some of the control functions locally while providing interfaces to access other global network management functions which are typically implemented on separate boxes, such as a SNMP Network Management Station and an AAA backend server (e.g., Radius Authentication Server)." =20 4) Section 4.5 "Remote MAC" First paragraph, delete ", and improves WTP manageability" at the end. =20 5) Section 4.6 "Comparisons of Local MAC, Split MAC and Remote MAC" Added the following paragraph at the end of this section: =20 "Each of the three architectural variants may be advantageous in certain aspects for certain deployment scenarious. While Local MAC retains most of the STAs state information at the local WTPs, Remote MAC centralizes most of the state into the backend AC. Split MAC sits somewhat in the middle of that spectrum, keeping some state information locally at the WTPs, and the rest centrally at the AC. Many factors should be taken into account to determine the exact balance desired between centralized v.s. decentralized state. The impact of such balance on network manageability is currently a matter of dispute within the technical community. " =20 6) Section 5 "Distributed Mesh Architecture" 3rd paragraph: [old]Any global configuration or policy change can be better served in a coordinated fashion if an AC exists. For example, a centralized management entity can be used to update every mesh node's default configuration; it may also be more desirable to leave certain functions (such as user authentication) to a centralized AC (Access Controller), with an alternative being to distribute them across the mesh nodes. =20 [new] Some global configuration or policy change may be better served in a coordinated fashion if some form of Access Controller (AC) exists in the mesh network, even if not the full blown version of the AC as defined in the Centralized WLAN Architecture. For example, a centralized management entity can be used to update every mesh node's default configuration; it may also be more desirable to leave certain functions such as user authentication to a single centralized end point (such as a RADIUS server), but mesh networks allows the possibility of each mesh AP to directly talk to the RADIUS server. This reduces single point of failure and takes advantage of the client distribution in the network. =20 7) Section 4.1 old title "Interconnection Topology between WTPs and ACs" is changed to "Interconnection between WTPs and ACs". Throughout the document, "topology" (when referred to L2 or L3 connection) is replaced with either "connection" or "interconnectivity". =20 8) 4.2 old title "Overview of Three Centralized WLAN Architectures" is changed to "Overview of Three Centralized WLAN Architecture Variants" =20 9) 5.1 "Security" (note: for mesh) Added "Each node that is part of the mesh must be fully trusted for the mesh to be secure. " in the first paragraph. =20 10) removed all appendix sections & references to the individual architecture submissions =20 11) Editorial changes (to fix typos, grammar, better sentence/paragraph flows) throughout the document. =20 =20 ------_=_NextPart_001_01C47598.D11CD868 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all = –

 

V04 of the CAPWAP = Architecture Taxonomy is ready for WG review and we also like to request WG last call = on it.

Please check it out here = at:

h= ttp://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-04.txt, before it is available through IETF = repository.

 

This revision is mostly = motivated by the comments posted by Pat and the discussions afterward on the mailing = list. We also took this opportunity to remove all the appendix data and hence = greatly shortened the length of the document to only 40 pages long now. =

 

V04 is a minor revision = over 03, with mostly clarification changes, and a few corrections. To help you = review the document, I provide a detailed change log from v03 to v04 =  below.

 

The Design Team feel the = taxonomy document has been matured a lot since last IETF meeting, and has been thoroughly reviewed by both IEEE 802.11 and IETF members since May, and = we feel that it is ready for WG last call.

 

Thanks,

 

Lily = (Editor)

 

 

--------------------- = Detailed change log from v03 to v04 ------------

 

In the rough order of = significance:

 

1) Section 1.3 = "Terminology Used in this Document"

For "Split MAC Architecture": =

[old]“…implement= the delay sensitive MAC services (like the control frame processing) for = IEEE 802.11, while tunneling all the management and data frames to AC for centralized processing.”

 

[new]“…implement= the delay sensitive MAC services (including all control frames and some = management frames) for IEEE 802.11, while tunneling all the remaining management = and data frames to AC for centralized = processing.”

 

2) Section 3.2 = "Security" (note: for autonomous architecture)

[old]"As per problem = #4 (in problem statement), the only security issue in this architecture is = mutual authentication between the WTP and the Ethernet infrastructure to ensure = that WTPs cannot be easily stolen and deployed in unprotected networks. This = can be ensured by existing mechanisms such as, for instance, 802.1x between the = WTP and the Ethernet switch it plugs = into."

 

[new]One of the security = issues in this architecture is the need for mutual authentication between the WTP = and the Ethernet infrastructure. This can be ensured by existing mechanisms such = as, 802.1x between the WTP and the Ethernet switch it plugs into. Another = security issue with this architecture is the very fact that the WTP is most = likely not under lock and key, but does contain secret information in order to = communicate with the backend systems, such as AAA, SNMP, etc. Due to the common = management method used by IT personel of pushing a "template" to all = similar devices, theft of such a device would potentially compromise the wired = network.

 

3) Section 4 = "Centralized WLAN Architecture":

At the end of first = paragraph, delete "A Network Management Station can be considered part of the = Access Controller, but typically the latter contains additional functionality = beyond that of the former. "

 

Instead, add the following = to the end of last paragraph "The AC(s) may also choose to implement some = of the control functions locally while providing interfaces to access other = global network management functions which are typically implemented on separate = boxes, such as a SNMP Network Management Station and an AAA backend server = (e.g., Radius Authentication Server)."

 

4) Section 4.5 "Remote MAC" First paragraph, delete ", and improves WTP = manageability" at the end.

 

5) Section 4.6 = "Comparisons of Local MAC, Split MAC and Remote MAC"

Added the following = paragraph at the end of this section:

 

"Each of the three architectural variants may be advantageous in certain aspects for = certain deployment scenarious. While Local MAC retains most of the STAs state information at the local WTPs, Remote MAC centralizes most of the state = into the backend AC. Split MAC sits somewhat in the middle of that spectrum, = keeping some state information locally at the WTPs, and the rest centrally at = the AC. Many factors should be taken into account to determine the exact balance desired between centralized v.s. decentralized state. The impact of such balance on network manageability is currently a matter of dispute within = the technical community. "

 

6) Section 5 = “Distributed Mesh Architecture” 3rd paragraph:

[old]Any global = configuration or policy

   change can be = better served in a coordinated fashion if an AC = exists.

   For example, a centralized management entity can be used to = update

   every mesh = node's default configuration; it may also be more

   desirable to = leave certain functions (such as user authentication) = to

   a centralized = AC (Access Controller), with an alternative being = to

   distribute = them across the mesh nodes.

 

[new] Some global = configuration or policy

   change may be = better served in a coordinated fashion if some form = of

   Access = Controller (AC) exists in the mesh network, even if not the

   full blown = version of the AC as defined in the Centralized WLAN

   = Architecture.  For example, a centralized management entity can = be

   used to update = every mesh node's default configuration; it may = also

   be more = desirable to leave certain functions such as user

   authentication = to a single centralized end point (such as a RADIUS

   server), but = mesh networks allows the possibility of each mesh AP = to

   directly talk = to the RADIUS server.  This reduces single point = of

   failure and = takes advantage of the client distribution in the

   = network.

 

7) Section 4.1 old title “Interconnection Topology between WTPs and ACs” is changed = to “Interconnection between WTPs and = ACs”.

Throughout the document, “topology” (when referred to L2 or L3 connection) is = replaced with either “connection” or “interconnectivity”. =

 

8) 4.2 old title = "Overview of Three Centralized WLAN Architectures" is changed to "Overview = of Three Centralized WLAN Architecture = Variants"

 

9) 5.1 "Security" = (note: for mesh)

Added "Each node that = is part of the mesh must be fully trusted for the mesh to be secure. " in = the first paragraph.

 

10) removed all appendix = sections & references to the individual architecture = submissions

 

11) Editorial changes (to = fix typos, grammar, better sentence/paragraph flows) throughout the = document.

 

 

------_=_NextPart_001_01C47598.D11CD868-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Jul 29 15:59:54 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05527 for ; Thu, 29 Jul 2004 15:59:53 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 443DC21627; Thu, 29 Jul 2004 15:41:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2CF76208BC; Thu, 29 Jul 2004 15:41:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B812B20940 for ; Thu, 29 Jul 2004 15:41:00 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id B48DB208BC for ; Thu, 29 Jul 2004 15:40:58 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i6TJuxHE026918 for ; Thu, 29 Jul 2004 19:56:59 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i6TJvPVH002282 for ; Thu, 29 Jul 2004 19:57:27 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004072912552318707 for ; Thu, 29 Jul 2004 12:55:23 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jul 2004 12:55:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C475A5.FBCF970C" Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01A80E39@orsmsx408> Thread-Topic: v04 CAPWAP draft and change log posted on www.capwap.org Thread-Index: AcR1pft1S3697a2+RLmhIAQxQF1iHQ== From: "Yang, Lily L" To: X-OriginalArrivalTime: 29 Jul 2004 19:55:23.0170 (UTC) FILETIME=[FC08B820:01C475A5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] v04 CAPWAP draft and change log posted on www.capwap.org Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 29 Jul 2004 12:55:22 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C475A5.FBCF970C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to Dave, now we have the v04 draft and the change log from v03 to v04 at the web site now. http://www.capwap.org/ =20 =20 ------_=_NextPart_001_01C475A5.FBCF970C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to Dave, now we have the v04 draft and the = change log from v03 to v04 at the web site now.

http://www.capwap.org/

 

 

------_=_NextPart_001_01C475A5.FBCF970C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 30 19:35:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08464 for ; Fri, 30 Jul 2004 19:35:43 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52A0020AA8; Fri, 30 Jul 2004 19:21:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DBC4F20894; Fri, 30 Jul 2004 19:21:05 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3034D20894 for ; Fri, 30 Jul 2004 19:20:43 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id A332D20856 for ; Fri, 30 Jul 2004 19:20:40 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6UNZ7N08476; Sat, 31 Jul 2004 02:35:07 +0300 (EET DST) X-Scanned: Sat, 31 Jul 2004 02:34:19 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i6UNYJOQ030965; Sat, 31 Jul 2004 02:34:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 000ym6ZH; Sat, 31 Jul 2004 02:34:17 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6UNYFu21965; Sat, 31 Jul 2004 02:34:15 +0300 (EET DST) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Jul 2004 18:33:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4768D.9E314A30" Subject: RE: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG review Message-ID: Thread-Topic: CAPWAP Architecture Taxonomy v04 is ready for WG review Thread-Index: AcR1mNDYWiKihHcpTROGSdNcff+DwQA8dL1w From: To: , Cc: , , X-OriginalArrivalTime: 30 Jul 2004 23:33:31.0147 (UTC) FILETIME=[9F7D45B0:01C4768D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 30 Jul 2004 16:33:28 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4768D.9E314A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lily- =20 Thanks to you and the design team for V04 of the architecture taxonomy = draft. The WG process requires documents to be submitted in to the = internet-drafts repository 2 weeks prior to an IETF meeting, in order to = discuss it at the WG meeting. SInce the DT has placed the draft in an = accessible location (see link below) and petitioned the AD and the = Chairs, unless the WG has any objections we will proceed to discuss the = latest 04 version of the taxonomy draft at the CAPWAP WG meeting next = week in San Diego. =20 Additionally, we cannot officially go into WGLC with a draft that has = not been accepted into the internet-drafts repository yet, so the WG LC = cannot officially begin until after August 9th. However, we can still = use the WG list to comment on the draft and we encourage the WG to = review v04 and submit comments as they arise. =20 Thanks, Dorothy and Mani =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On = Behalf Of ext Yang, Lily L Sent: Thursday, July 29, 2004 11:21 AM To: capwap@frascone.com Subject: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG = review Hi, all - =20 V04 of the CAPWAP Architecture Taxonomy is ready for WG review and we = also like to request WG last call on it. Please check it out here at: http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-04.txt, before it = is available through IETF repository. =20 This revision is mostly motivated by the comments posted by Pat and the = discussions afterward on the mailing list. We also took this opportunity = to remove all the appendix data and hence greatly shortened the length = of the document to only 40 pages long now.=20 =20 V04 is a minor revision over 03, with mostly clarification changes, and = a few corrections. To help you review the document, I provide a detailed = change log from v03 to v04 below.=20 =20 The Design Team feel the taxonomy document has been matured a lot since = last IETF meeting, and has been thoroughly reviewed by both IEEE 802.11 = and IETF members since May, and we feel that it is ready for WG last = call.=20 =20 Thanks, =20 Lily (Editor) =20 =20 --------------------- Detailed change log from v03 to v04 ------------ =20 In the rough order of significance:=20 =20 1) Section 1.3 "Terminology Used in this Document" For "Split MAC Architecture":=20 [old]"...implement the delay sensitive MAC services (like the control = frame processing) for IEEE 802.11, while tunneling all the management = and data frames to AC for centralized processing." =20 [new]"...implement the delay sensitive MAC services (including all = control frames and some management frames) for IEEE 802.11, while = tunneling all the remaining management and data frames to AC for = centralized processing." =20 2) Section 3.2 "Security" (note: for autonomous architecture) [old]"As per problem #4 (in problem statement), the only security issue = in this architecture is mutual authentication between the WTP and the = Ethernet infrastructure to ensure that WTPs cannot be easily stolen and = deployed in unprotected networks. This can be ensured by existing = mechanisms such as, for instance, 802.1x between the WTP and the = Ethernet switch it plugs into." =20 [new]One of the security issues in this architecture is the need for = mutual authentication between the WTP and the Ethernet infrastructure. = This can be ensured by existing mechanisms such as, 802.1x between the = WTP and the Ethernet switch it plugs into. Another security issue with = this architecture is the very fact that the WTP is most likely not under = lock and key, but does contain secret information in order to = communicate with the backend systems, such as AAA, SNMP, etc. Due to the = common management method used by IT personel of pushing a "template" to = all similar devices, theft of such a device would potentially compromise = the wired network.=20 =20 3) Section 4 "Centralized WLAN Architecture":=20 At the end of first paragraph, delete "A Network Management Station can = be considered part of the Access Controller, but typically the latter = contains additional functionality beyond that of the former. " =20 Instead, add the following to the end of last paragraph "The AC(s) may = also choose to implement some of the control functions locally while = providing interfaces to access other global network management functions = which are typically implemented on separate boxes, such as a SNMP = Network Management Station and an AAA backend server (e.g., Radius = Authentication Server)." =20 4) Section 4.5 "Remote MAC" First paragraph, delete ", and improves WTP = manageability" at the end. =20 5) Section 4.6 "Comparisons of Local MAC, Split MAC and Remote MAC" Added the following paragraph at the end of this section: =20 "Each of the three architectural variants may be advantageous in certain = aspects for certain deployment scenarious. While Local MAC retains most = of the STAs state information at the local WTPs, Remote MAC centralizes = most of the state into the backend AC. Split MAC sits somewhat in the = middle of that spectrum, keeping some state information locally at the = WTPs, and the rest centrally at the AC. Many factors should be taken = into account to determine the exact balance desired between centralized = v.s. decentralized state. The impact of such balance on network = manageability is currently a matter of dispute within the technical = community. " =20 6) Section 5 "Distributed Mesh Architecture" 3rd paragraph: [old]Any global configuration or policy change can be better served in a coordinated fashion if an AC exists. For example, a centralized management entity can be used to update every mesh node's default configuration; it may also be more desirable to leave certain functions (such as user authentication) to a centralized AC (Access Controller), with an alternative being to distribute them across the mesh nodes. =20 [new] Some global configuration or policy change may be better served in a coordinated fashion if some form of Access Controller (AC) exists in the mesh network, even if not the full blown version of the AC as defined in the Centralized WLAN Architecture. For example, a centralized management entity can be used to update every mesh node's default configuration; it may also be more desirable to leave certain functions such as user authentication to a single centralized end point (such as a RADIUS server), but mesh networks allows the possibility of each mesh AP to directly talk to the RADIUS server. This reduces single point of failure and takes advantage of the client distribution in the network. =20 7) Section 4.1 old title "Interconnection Topology between WTPs and ACs" = is changed to "Interconnection between WTPs and ACs". Throughout the document, "topology" (when referred to L2 or L3 = connection) is replaced with either "connection" or "interconnectivity". = =20 8) 4.2 old title "Overview of Three Centralized WLAN Architectures" is = changed to "Overview of Three Centralized WLAN Architecture Variants" =20 9) 5.1 "Security" (note: for mesh) Added "Each node that is part of the mesh must be fully trusted for the = mesh to be secure. " in the first paragraph. =20 10) removed all appendix sections & references to the individual = architecture submissions =20 11) Editorial changes (to fix typos, grammar, better sentence/paragraph = flows) throughout the document. =20 =20 ------_=_NextPart_001_01C4768D.9E314A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Lily-
 
Thanks=20 to you and the design team for V04 of the architecture taxonomy=20 draft.    The WG process requires documents to be = submitted in to=20 the internet-drafts repository 2 weeks prior to an IETF meeting, in = order to=20 discuss it at the WG meeting.  SInce the DT has placed the draft in = an=20 accessible location (see link below) and petitioned the AD and the = Chairs,=20 unless the WG has any objections we will proceed to discuss the latest = 04=20 version of the taxonomy draft at the CAPWAP WG meeting next week in San=20 Diego.
 
Additionally, we cannot officially go into WGLC with a draft = that has not=20 been accepted into the internet-drafts repository yet, so the WG LC = cannot=20 officially begin until after August = 9th.    However, we=20 can still use the WG list to comment on the draft and we encourage the = WG to=20 review v04 and submit comments as they arise.
 
Thanks,
Dorothy and Mani
 
-----Original Message-----
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com]On Behalf Of ext Yang, Lily=20 L
Sent: Thursday, July 29, 2004 11:21 AM
To:=20 capwap@frascone.com
Subject: [Capwap] CAPWAP Architecture = Taxonomy=20 v04 is ready for WG review

Hi, all=20 –

 

V04 of the CAPWAP = Architecture=20 Taxonomy is ready for WG review and we also like to request WG last = call on=20 it.

Please check it out here = at:

ht= tp://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-04.txt,=20 before it is available through IETF = repository.

 

This revision is mostly = motivated=20 by the comments posted by Pat and the discussions afterward on the = mailing=20 list. We also took this opportunity to remove all the appendix data = and hence=20 greatly shortened the length of the document to only 40 pages long = now.=20

 

V04 is a minor revision = over 03,=20 with mostly clarification changes, and a few corrections. To help you = review=20 the document, I provide a detailed change log from v03 to v04 =  below.=20

 

The Design Team feel the = taxonomy=20 document has been matured a lot since last IETF meeting, and has been=20 thoroughly reviewed by both IEEE 802.11 and IETF members since May, = and we=20 feel that it is ready for WG last call.

 

Thanks,

 

Lily=20 (Editor)

 

 

--------------------- = Detailed=20 change log from v03 to v04 ------------

 

In the rough order of=20 significance:

 

1) Section 1.3 = "Terminology Used=20 in this Document"

For "Split MAC = Architecture":=20

[old]“…implement the delay=20 sensitive MAC services (like the control frame processing) for IEEE = 802.11,=20 while tunneling all the management and data frames to AC for = centralized=20 processing.”

 

[new]“…implement the delay=20 sensitive MAC services (including all control frames and some = management=20 frames) for IEEE 802.11, while tunneling all the remaining management = and data=20 frames to AC for centralized = processing.”

 

2) Section 3.2 = "Security" (note:=20 for autonomous architecture)

[old]"As per problem #4 = (in=20 problem statement), the only security issue in this architecture is = mutual=20 authentication between the WTP and the Ethernet infrastructure to = ensure that=20 WTPs cannot be easily stolen and deployed in unprotected networks. = This can be=20 ensured by existing mechanisms such as, for instance, 802.1x between = the WTP=20 and the Ethernet switch it plugs into."

 

[new]One of the security = issues in=20 this architecture is the need for mutual authentication between the = WTP and=20 the Ethernet infrastructure. This can be ensured by existing = mechanisms such=20 as, 802.1x between the WTP and the Ethernet switch it plugs into. = Another=20 security issue with this architecture is the very fact that the WTP is = most=20 likely not under lock and key, but does contain secret information in = order to=20 communicate with the backend systems, such as AAA, SNMP, etc. Due to = the=20 common management method used by IT personel of pushing a "template" = to all=20 similar devices, theft of such a device would potentially compromise = the wired=20 network.

 

3) Section 4 = "Centralized WLAN=20 Architecture":

At the end of first = paragraph,=20 delete "A Network Management Station can be considered part of the = Access=20 Controller, but typically the latter contains additional functionality = beyond=20 that of the former. "

 

Instead, add the = following to the=20 end of last paragraph "The AC(s) may also choose to implement some of = the=20 control functions locally while providing interfaces to access other = global=20 network management functions which are typically implemented on = separate=20 boxes, such as a SNMP Network Management Station and an AAA backend = server=20 (e.g., Radius Authentication Server)."

 

4) Section 4.5 "Remote = MAC" First=20 paragraph, delete ", and improves WTP manageability" at the=20 end.

 

5) Section 4.6 = "Comparisons of=20 Local MAC, Split MAC and Remote MAC"

Added the following = paragraph at=20 the end of this section:

 

"Each of the three = architectural=20 variants may be advantageous in certain aspects for certain deployment = scenarious. While Local MAC retains most of the STAs state information = at the=20 local WTPs, Remote MAC centralizes most of the state into the backend = AC.=20 Split MAC sits somewhat in the middle of that spectrum, keeping some = state=20 information locally at the WTPs, and the rest centrally at the AC. = Many=20 factors should be taken into account to determine the exact balance = desired=20 between centralized v.s. decentralized state. The impact of such = balance on=20 network manageability is currently a matter of dispute within the = technical=20 community. "

 

6) Section 5 = “Distributed Mesh=20 Architecture” 3rd paragraph:

[old]Any global = configuration or=20 policy

   change can = be better=20 served in a coordinated fashion if an AC = exists.

   For = example, a=20 centralized management entity can be used to=20 update

   every mesh = node's=20 default configuration; it may also be = more

   desirable = to leave=20 certain functions (such as user authentication)=20 to

   a = centralized AC=20 (Access Controller), with an alternative being = to

   distribute = them=20 across the mesh nodes.

 

[new] Some global = configuration or=20 policy

   change may = be better=20 served in a coordinated fashion if some form = of

   Access = Controller=20 (AC) exists in the mesh network, even if not = the

   full blown = version of=20 the AC as defined in the Centralized WLAN

   = Architecture. =20 For example, a centralized management entity can=20 be

   used to = update every=20 mesh node's default configuration; it may = also

   be more = desirable to=20 leave certain functions such as user

   = authentication to a=20 single centralized end point (such as a = RADIUS

   server), = but mesh=20 networks allows the possibility of each mesh AP=20 to

   directly = talk to the=20 RADIUS server.  This reduces single point = of

   failure and = takes=20 advantage of the client distribution in = the

  =20 network.

 

7) Section 4.1 old title = “Interconnection Topology between WTPs and ACs” is changed = to “Interconnection=20 between WTPs and ACs”.

Throughout the document, = “topology” (when referred to L2 or L3 connection) is = replaced with either=20 “connection” or “interconnectivity”. =

 

8) 4.2 old title = "Overview of=20 Three Centralized WLAN Architectures" is changed to "Overview of Three = Centralized WLAN Architecture Variants"

 

9) 5.1 "Security" (note: = for=20 mesh)

Added "Each node that is = part of=20 the mesh must be fully trusted for the mesh to be secure. " in the = first=20 paragraph.

 

10) removed all appendix = sections=20 & references to the individual architecture=20 submissions

 

11) Editorial changes = (to fix=20 typos, grammar, better sentence/paragraph flows) throughout the=20 document.

 

 

------_=_NextPart_001_01C4768D.9E314A30-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Jul 30 19:40:44 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08772 for ; Fri, 30 Jul 2004 19:40:39 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C02F4208A8; Fri, 30 Jul 2004 19:26:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12F5E20A69; Fri, 30 Jul 2004 19:26:06 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 966D820A69 for ; Fri, 30 Jul 2004 19:25:43 -0400 (EDT) Received: from AIREMAIL.airespace.com (da001d3897.stl-mo.osd.concentric.net [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 97CA7208A8 for ; Fri, 30 Jul 2004 19:25:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4768E.F226535E" Subject: RE: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG review Message-ID: <55749BC69138654EBBC4C50BA4F55610020C43F0@AIREMAIL.airespace.com> Thread-Topic: CAPWAP Architecture Taxonomy v04 is ready for WG review Thread-Index: AcR1mNDYWiKihHcpTROGSdNcff+DwQA8dL1wAAEOYi4= From: "Pat R. Calhoun" To: , , Cc: , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 30 Jul 2004 16:42:24 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C4768E.F226535E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I do not object - let's discuss the draft next week. =20 And thanks to the DT for a great job. =20 PatC ________________________________ From: capwap-admin@frascone.com on behalf of Dorothy.Gellert@nokia.com Sent: Fri 7/30/2004 4:33 PM To: lily.l.yang@intel.com; capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com Subject: RE: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG = review Hi Lily- =20 Thanks to you and the design team for V04 of the architecture taxonomy = draft. The WG process requires documents to be submitted in to the = internet-drafts repository 2 weeks prior to an IETF meeting, in order to = discuss it at the WG meeting. SInce the DT has placed the draft in an = accessible location (see link below) and petitioned the AD and the = Chairs, unless the WG has any objections we will proceed to discuss the = latest 04 version of the taxonomy draft at the CAPWAP WG meeting next = week in San Diego. =20 Additionally, we cannot officially go into WGLC with a draft that has = not been accepted into the internet-drafts repository yet, so the WG LC = cannot officially begin until after August 9th. However, we can still = use the WG list to comment on the draft and we encourage the WG to = review v04 and submit comments as they arise. =20 Thanks, Dorothy and Mani =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On = Behalf Of ext Yang, Lily L Sent: Thursday, July 29, 2004 11:21 AM To: capwap@frascone.com Subject: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG = review =09 =09 Hi, all - =20 V04 of the CAPWAP Architecture Taxonomy is ready for WG review and we = also like to request WG last call on it. Please check it out here at: http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-04.txt, before = it is available through IETF repository. =20 This revision is mostly motivated by the comments posted by Pat and the = discussions afterward on the mailing list. We also took this opportunity = to remove all the appendix data and hence greatly shortened the length = of the document to only 40 pages long now.=20 =20 V04 is a minor revision over 03, with mostly clarification changes, and = a few corrections. To help you review the document, I provide a detailed = change log from v03 to v04 below.=20 =20 The Design Team feel the taxonomy document has been matured a lot since = last IETF meeting, and has been thoroughly reviewed by both IEEE 802.11 = and IETF members since May, and we feel that it is ready for WG last = call.=20 =20 Thanks, =20 Lily (Editor) =20 =20 --------------------- Detailed change log from v03 to v04 ------------ =20 In the rough order of significance:=20 =20 1) Section 1.3 "Terminology Used in this Document" For "Split MAC Architecture":=20 [old]"...implement the delay sensitive MAC services (like the control = frame processing) for IEEE 802.11, while tunneling all the management = and data frames to AC for centralized processing." =20 [new]"...implement the delay sensitive MAC services (including all = control frames and some management frames) for IEEE 802.11, while = tunneling all the remaining management and data frames to AC for = centralized processing." =20 2) Section 3.2 "Security" (note: for autonomous architecture) [old]"As per problem #4 (in problem statement), the only security issue = in this architecture is mutual authentication between the WTP and the = Ethernet infrastructure to ensure that WTPs cannot be easily stolen and = deployed in unprotected networks. This can be ensured by existing = mechanisms such as, for instance, 802.1x between the WTP and the = Ethernet switch it plugs into." =20 [new]One of the security issues in this architecture is the need for = mutual authentication between the WTP and the Ethernet infrastructure. = This can be ensured by existing mechanisms such as, 802.1x between the = WTP and the Ethernet switch it plugs into. Another security issue with = this architecture is the very fact that the WTP is most likely not under = lock and key, but does contain secret information in order to = communicate with the backend systems, such as AAA, SNMP, etc. Due to the = common management method used by IT personel of pushing a "template" to = all similar devices, theft of such a device would potentially compromise = the wired network.=20 =20 3) Section 4 "Centralized WLAN Architecture":=20 At the end of first paragraph, delete "A Network Management Station can = be considered part of the Access Controller, but typically the latter = contains additional functionality beyond that of the former. " =20 Instead, add the following to the end of last paragraph "The AC(s) may = also choose to implement some of the control functions locally while = providing interfaces to access other global network management functions = which are typically implemented on separate boxes, such as a SNMP = Network Management Station and an AAA backend server (e.g., Radius = Authentication Server)." =20 4) Section 4.5 "Remote MAC" First paragraph, delete ", and improves WTP = manageability" at the end. =20 5) Section 4.6 "Comparisons of Local MAC, Split MAC and Remote MAC" Added the following paragraph at the end of this section: =20 "Each of the three architectural variants may be advantageous in = certain aspects for certain deployment scenarious. While Local MAC = retains most of the STAs state information at the local WTPs, Remote MAC = centralizes most of the state into the backend AC. Split MAC sits = somewhat in the middle of that spectrum, keeping some state information = locally at the WTPs, and the rest centrally at the AC. Many factors = should be taken into account to determine the exact balance desired = between centralized v.s. decentralized state. The impact of such balance = on network manageability is currently a matter of dispute within the = technical community. " =20 6) Section 5 "Distributed Mesh Architecture" 3rd paragraph: [old]Any global configuration or policy change can be better served in a coordinated fashion if an AC = exists. For example, a centralized management entity can be used to update every mesh node's default configuration; it may also be more desirable to leave certain functions (such as user authentication) = to a centralized AC (Access Controller), with an alternative being to distribute them across the mesh nodes. =20 [new] Some global configuration or policy change may be better served in a coordinated fashion if some form of Access Controller (AC) exists in the mesh network, even if not the full blown version of the AC as defined in the Centralized WLAN Architecture. For example, a centralized management entity can be used to update every mesh node's default configuration; it may also be more desirable to leave certain functions such as user authentication to a single centralized end point (such as a RADIUS server), but mesh networks allows the possibility of each mesh AP to directly talk to the RADIUS server. This reduces single point of failure and takes advantage of the client distribution in the network. =20 7) Section 4.1 old title "Interconnection Topology between WTPs and = ACs" is changed to "Interconnection between WTPs and ACs". Throughout the document, "topology" (when referred to L2 or L3 = connection) is replaced with either "connection" or "interconnectivity". = =20 8) 4.2 old title "Overview of Three Centralized WLAN Architectures" is = changed to "Overview of Three Centralized WLAN Architecture Variants" =20 9) 5.1 "Security" (note: for mesh) Added "Each node that is part of the mesh must be fully trusted for the = mesh to be secure. " in the first paragraph. =20 10) removed all appendix sections & references to the individual = architecture submissions =20 11) Editorial changes (to fix typos, grammar, better sentence/paragraph = flows) throughout the document. =20 =20 ------_=_NextPart_001_01C4768E.F226535E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
I do not = object - let's =0A= discuss the draft next week.
=0A=
 
=0A=
And thanks to the DT for a = great =0A= job.
=0A=
 
=0A=
PatC
=0A=

=0A=
=0A= From: capwap-admin@frascone.com on = behalf of =0A= Dorothy.Gellert@nokia.com
Sent: Fri 7/30/2004 4:33 = PM
To: =0A= lily.l.yang@intel.com; capwap@frascone.com
Cc: = bwijnen@lucent.com; =0A= mmani@avaya.com; david.kessens@nokia.com
Subject: RE: [Capwap] = CAPWAP =0A= Architecture Taxonomy v04 is ready for WG review

=0A=
=0A=
Hi =0A= Lily-
=0A=
 
=0A=
Thanks =0A= to you and the design team for V04 of the architecture taxonomy =0A= draft.    The WG process requires documents to be = submitted in to =0A= the internet-drafts repository 2 weeks prior to an IETF meeting, in = order to =0A= discuss it at the WG meeting.  SInce the DT has placed the draft in = an =0A= accessible location (see link below) and petitioned the AD and the = Chairs, =0A= unless the WG has any objections we will proceed to discuss the latest = 04 =0A= version of the taxonomy draft at the CAPWAP WG meeting next week in San =0A= Diego.
=0A=
 
=0A=
Additionally, we cannot officially go into WGLC with a draft = that has not =0A= been accepted into the internet-drafts repository yet, so the WG LC = cannot =0A= officially begin until after August = 9th.    However, we =0A= can still use the WG list to comment on the draft and we encourage the = WG to =0A= review v04 and submit comments as they arise.
=0A=
 
=0A=
Thanks,
=0A=
Dorothy and Mani
=0A=
 
=0A=
=0A=
-----Original Message-----
From: = capwap-admin@frascone.com =0A= [mailto:capwap-admin@frascone.com]On Behalf Of ext Yang, Lily =0A= L
Sent: Thursday, July 29, 2004 11:21 AM
To: =0A= capwap@frascone.com
Subject: [Capwap] CAPWAP Architecture = Taxonomy =0A= v04 is ready for WG review

=0A=
=0A=

Hi, all = –

=0A=

 

=0A=

V04 of the CAPWAP = Architecture =0A= Taxonomy is ready for WG review and we also like to request WG last = call on =0A= it.

=0A=

Please check it out here =0A= at:

=0A=

ht= tp://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-04.txt, =0A= before it is available through IETF repository.

=0A=

 

=0A=

This revision is mostly = motivated =0A= by the comments posted by Pat and the discussions afterward on the = mailing =0A= list. We also took this opportunity to remove all the appendix data = and hence =0A= greatly shortened the length of the document to only 40 pages long = now. =0A=

=0A=

 

=0A=

V04 is a minor revision = over 03, =0A= with mostly clarification changes, and a few corrections. To help you = review =0A= the document, I provide a detailed change log from v03 to v04 =  below. =0A=

=0A=

 

=0A=

The Design Team feel the = taxonomy =0A= document has been matured a lot since last IETF meeting, and has been =0A= thoroughly reviewed by both IEEE 802.11 and IETF members since May, = and we =0A= feel that it is ready for WG last call.

=0A=

 

=0A=

Thanks,

=0A=

 

=0A=

Lily = (Editor)

=0A=

 

=0A=

 

=0A=

--------------------- = Detailed =0A= change log from v03 to v04 ------------

=0A=

 

=0A=

In the rough order of =0A= significance:

=0A=

 

=0A=

1) Section 1.3 = "Terminology Used =0A= in this Document"

=0A=

For "Split MAC = Architecture": =0A=

=0A=

[old]“…implement the delay =0A= sensitive MAC services (like the control frame processing) for IEEE = 802.11, =0A= while tunneling all the management and data frames to AC for = centralized =0A= processing.”

=0A=

 

=0A=

[new]“…implement the delay =0A= sensitive MAC services (including all control frames and some = management =0A= frames) for IEEE 802.11, while tunneling all the remaining management = and data =0A= frames to AC for centralized processing.”

=0A=

 

=0A=

2) Section 3.2 = "Security" (note: =0A= for autonomous architecture)

=0A=

[old]"As per problem #4 = (in =0A= problem statement), the only security issue in this architecture is = mutual =0A= authentication between the WTP and the Ethernet infrastructure to = ensure that =0A= WTPs cannot be easily stolen and deployed in unprotected networks. = This can be =0A= ensured by existing mechanisms such as, for instance, 802.1x between = the WTP =0A= and the Ethernet switch it plugs into."

=0A=

 

=0A=

[new]One of the security = issues in =0A= this architecture is the need for mutual authentication between the = WTP and =0A= the Ethernet infrastructure. This can be ensured by existing = mechanisms such =0A= as, 802.1x between the WTP and the Ethernet switch it plugs into. = Another =0A= security issue with this architecture is the very fact that the WTP is = most =0A= likely not under lock and key, but does contain secret information in = order to =0A= communicate with the backend systems, such as AAA, SNMP, etc. Due to = the =0A= common management method used by IT personel of pushing a "template" = to all =0A= similar devices, theft of such a device would potentially compromise = the wired =0A= network.

=0A=

 

=0A=

3) Section 4 = "Centralized WLAN =0A= Architecture":

=0A=

At the end of first = paragraph, =0A= delete "A Network Management Station can be considered part of the = Access =0A= Controller, but typically the latter contains additional functionality = beyond =0A= that of the former. "

=0A=

 

=0A=

Instead, add the = following to the =0A= end of last paragraph "The AC(s) may also choose to implement some of = the =0A= control functions locally while providing interfaces to access other = global =0A= network management functions which are typically implemented on = separate =0A= boxes, such as a SNMP Network Management Station and an AAA backend = server =0A= (e.g., Radius Authentication Server)."

=0A=

 

=0A=

4) Section 4.5 "Remote = MAC" First =0A= paragraph, delete ", and improves WTP manageability" at the =0A= end.

=0A=

 

=0A=

5) Section 4.6 = "Comparisons of =0A= Local MAC, Split MAC and Remote MAC"

=0A=

Added the following = paragraph at =0A= the end of this section:

=0A=

 

=0A=

"Each of the three = architectural =0A= variants may be advantageous in certain aspects for certain deployment =0A= scenarious. While Local MAC retains most of the STAs state information = at the =0A= local WTPs, Remote MAC centralizes most of the state into the backend = AC. =0A= Split MAC sits somewhat in the middle of that spectrum, keeping some = state =0A= information locally at the WTPs, and the rest centrally at the AC. = Many =0A= factors should be taken into account to determine the exact balance = desired =0A= between centralized v.s. decentralized state. The impact of such = balance on =0A= network manageability is currently a matter of dispute within the = technical =0A= community. "

=0A=

 

=0A=

6) Section 5 = “Distributed Mesh =0A= Architecture” 3rd paragraph:

=0A=

[old]Any global = configuration or =0A= policy

=0A=

   change can = be better =0A= served in a coordinated fashion if an AC exists.

=0A=

   For = example, a =0A= centralized management entity can be used to update

=0A=

   every mesh = node's =0A= default configuration; it may also be more

=0A=

   desirable = to leave =0A= certain functions (such as user authentication) to

=0A=

   a = centralized AC =0A= (Access Controller), with an alternative being to

=0A=

   distribute = them =0A= across the mesh nodes.

=0A=

 

=0A=

[new] Some global = configuration or =0A= policy

=0A=

   change may = be better =0A= served in a coordinated fashion if some form of

=0A=

   Access = Controller =0A= (AC) exists in the mesh network, even if not the

=0A=

   full blown = version of =0A= the AC as defined in the Centralized WLAN

=0A=

   = Architecture.  =0A= For example, a centralized management entity can be

=0A=

   used to = update every =0A= mesh node's default configuration; it may also

=0A=

   be more = desirable to =0A= leave certain functions such as user

=0A=

   = authentication to a =0A= single centralized end point (such as a RADIUS

=0A=

   server), = but mesh =0A= networks allows the possibility of each mesh AP to

=0A=

   directly = talk to the =0A= RADIUS server.  This reduces single point of

=0A=

   failure and = takes =0A= advantage of the client distribution in the

=0A=

   =0A= network.

=0A=

 

=0A=

7) Section 4.1 old title =0A= “Interconnection Topology between WTPs and ACs” is changed = to “Interconnection =0A= between WTPs and ACs”.

=0A=

Throughout the document, =0A= “topology” (when referred to L2 or L3 connection) is = replaced with either =0A= “connection” or “interconnectivity”. =

=0A=

 

=0A=

8) 4.2 old title = "Overview of =0A= Three Centralized WLAN Architectures" is changed to "Overview of Three =0A= Centralized WLAN Architecture Variants"

=0A=

 

=0A=

9) 5.1 "Security" (note: = for =0A= mesh)

=0A=

Added "Each node that is = part of =0A= the mesh must be fully trusted for the mesh to be secure. " in the = first =0A= paragraph.

=0A=

 

=0A=

10) removed all appendix = sections =0A= & references to the individual architecture = submissions

=0A=

 

=0A=

11) Editorial changes = (to fix =0A= typos, grammar, better sentence/paragraph flows) throughout the =0A= document.

=0A=

 

=0A=

 

------_=_NextPart_001_01C4768E.F226535E-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap