From xml-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 1 05:40:25 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E5128C229 for ; Wed, 1 Oct 2008 05:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWnLqIvXM0r6 for ; Wed, 1 Oct 2008 05:40:12 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id ECB3D3A6E99 for ; Wed, 1 Oct 2008 05:30:53 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0C6F143040C for ; Wed, 1 Oct 2008 05:30:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: frascone.com mailing list memberships reminder From: xml-owner@frascone.com X-No-Archive: yes Message-ID: Date: Wed, 01 Oct 2008 05:30:10 -0700 Precedence: bulk X-BeenThere: xml@frascone.com X-Mailman-Version: 2.1.9 List-Id: Diameter XML Dictionary Design Team List -- CLOSED -- ARCHIVES ONLY X-List-Administrivia: yes To: capwap-archive@lists.ietf.org Errors-To: xml-bounces+capwap-archive=lists.ietf.org@frascone.com This is a monthly reminder about your frascone.com mailing list memberships. It shows the lists you are subscribed to, your passwords, and a Web page URL you can use to manage your subscriptions. Visit the Web page URL shown below to unsubscribe, change your e-mail address, temporarily disable your subscription for a vacation, set digest-style delivery, and so on. You can also use e-mail to make changes. For more info, send a message to the '-request' address of the list (for example, xml-request@frascone.com) containing just the word 'help' in the message body. An e-mail message will be sent to you with instructions. Here is the subscription information for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com ugimni http://lists.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 7 01:41:05 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161093A6955 for ; Tue, 7 Oct 2008 01:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.383 X-Spam-Level: *** X-Spam-Status: No, score=3.383 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_50=0.001, CN_BODY_35=0.339, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_83=0.6, MIME_CHARSET_FARAWAY=2.45, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl6EDx0bziTq for ; Tue, 7 Oct 2008 01:41:00 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 01D3128C127 for ; Tue, 7 Oct 2008 01:40:59 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2EC764301BC for ; Tue, 7 Oct 2008 01:41:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id DB4C9D04067 for ; Tue, 7 Oct 2008 01:41:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B31F9361007B for ; Tue, 7 Oct 2008 01:41:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4E7C93610076 for ; Tue, 7 Oct 2008 01:40:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Sender first seen 2 mons 12 days 20:40:49 ago / dynamic or unknown reverse DNS) Received: from huawei-3com.com (unknown [221.12.31.13]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 7 Oct 2008 01:40:57 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8D007G81KWW1@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 07 Oct 2008 16:43:44 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8D00AFA1KW6H@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 07 Oct 2008 16:43:44 +0800 (CST) Received: from unknown (HELO s00338) ([10.154.68.123]) by mailsecurity.h3c.com with ESMTP; Tue, 07 Oct 2008 16:38:19 +0800 Date: Tue, 07 Oct 2008 16:40:48 +0800 From: young In-reply-to: <02d201c927bf$75d68680$0600a8c0@china.huawei.com> To: capwap@frascone.com Message-id: <000001c92858$662abdc0$7b449a0a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook, Build 10.0.6838 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Thread-index: AckestCXZzuEYPpHQMuYjTfXjTQDeQALG7RgAFhg0+AB0PDCgAAOoKbwACYcJiA= Cc: chelliot@cisco.com, yozhang@gmail.com Subject: [Capwap] The answer to question:How to handle data type difference of Mac Type and tunnel mode in the MIBs X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0076241228==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0076241228== Content-type: multipart/alternative; boundary="Boundary_(ID_WWmo0A1pKyWxnBCIVS9/sA)" This is a multi-part message in MIME format. --Boundary_(ID_WWmo0A1pKyWxnBCIVS9/sA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable =A1=A1 HI,=20 The new version of MIB drafts will use the method suggested by David to close the issue : How to handle data type difference of Mac Type and tunnel mode in the = MIBs =A1=A1=A1=A1The description of question and answer to it are as = followed. =20 Regards RIchard =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: David Harrington [mailto:ietfdbh@comcast.net]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA10=D4=C26=C8=D5 22:26 =CA=D5=BC=FE=C8=CB: 'young'; dromasca@avaya.com =B3=AD=CB=CD: 'Yong Zhang'; chelliot@cisco.com =D6=F7=CC=E2: RE: kindly give some suggestion for this question =20 Hi, =20 My advice remains the same. =20 If you know the enumeration in the protocol is not likely to change in = the future, and my impression is that it will not, then you can represent = the enumerated values in a BITS type in the MIB, so you can gain the benefit = of consistent types for the MAC type and tunnel modes. =20 dbh =20 _____ =20 From: young [mailto:young@h3c.com]=20 Sent: Monday, October 06, 2008 3:34 AM To: 'David Harrington'; dromasca@avaya.com Cc: 'Yong Zhang'; chelliot@cisco.com Subject: kindly give some suggestion for this question Hi, kindly give some suggestion for this question: How to handle = data type difference of Mac Type and tunnel mode in the MIBs I gave more explain about my question in my previous email ( it is below) I want to close this issue in the new version. For new version, we have done lots of changes for readability and minimize the gap between MIB drafts and Protocol. It already passes the tools of Nits, spell and smilint. We plan to publish them within this week. =20 Regards Richard =B7=A2=BC=FE=C8=CB: young [mailto:young@h3c.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA9=D4=C227=C8=D5 9:59 =CA=D5=BC=FE=C8=CB: 'David Harrington' =B3=AD=CB=CD: 'capwap@frascone.com'; 'Yong Zhang'; chelliot@cisco.com =D6=F7=CC=E2: =B4=F0=B8=B4: [Capwap] How to handle data type difference = of Mac Type and tunnel mode in the MIBs? =20 Hi, Sorry, I have not made my questions clear.=20 The problem is caused by difference between base and 802.11 = binding protocol, not by MIBs themselves.=20 In them, The Mac Type and tunnel mode use different type:Base protocol = use BITS, while binding protocol is enumerated. =20 For MIB design, I think the valid design is to define TCs for MAC type and tunnel mode in the Base MIBs. When 802.11 binding MIB defines MIB objects of MAC type and tunnel Mode for a specific WLAN network, These objects will be defined by those TCs defined in the Base = MIBs, But How to handle the data type difference cause by protocols = (base and 802.11 binding protocol) =20 Regards Richard =20 But in the base protocol and dot11 binding protocol, The Mac Type and = tunnel mode for a=20 Use different type. How to handle this case in the MIB? Please give some suggestion. =20 =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: David Harrington [mailto:ietfdbh@comcast.net]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2008=C4=EA9=D4=C225=C8=D5 15:33 =CA=D5=BC=FE=C8=CB: 'young'; capwap@frascone.com =B3=AD=CB=CD: chelliot@cisco.com; 'Yong Zhang' =D6=F7=CC=E2: RE: [Capwap] How to handle data type difference of Mac = Type and tunnel mode in the MIBs? =20 Hi, =20 If I understand the issue properly, your voncern is the difference in = types, and changing the type of one of these would solev the problem. =20 A BITS type could be used to represent the MacType. This BITS type could represent local or split by setting only one bit, and it can be used to represent "both" by setting two bits. =20 I will note that the tunnelmode is extensible - new BITs can be added to support new types, and multiple types can be supported on a device. In comparison, MacType can never be expanded beyond local and split-mic = modes the way it is currently defined. I don't know that anybody will ever = invent an alternative to local and split, but if they do, your enumeration will = not be able to represent it very easily (to add a new mode "foo", you would = need to define foo(4), foo+local(5), foo+split(6), foo+local+split(7). And = then if you define a new mode bar(n), you would need to grow your = enumerations combinatorially. Using BITS means adding one BIT definition. =20 dbh =20 =20 _____ =20 From: young [mailto:young@h3c.com]=20 Sent: Thursday, September 25, 2008 5:03 AM To: capwap@frascone.com Cc: chelliot@cisco.com; 'Yong Zhang' Subject: [Capwap] How to handle data type difference of Mac Type and = tunnel mode in the MIBs? Hi,=20 the Mac Type and tunnel mode is defined in the base protocol.=20 And the dot11 binding protocol use it for a WLAN network. Currently, Base MIB defines TCs for Mac Type and tunnel mode as = followed, and Dot11 MIB IMPORTs them and define objects based on them for a WLAN network. I think this way is valid. If each binding MIBs separately defines TC of = MAC and tunnel mode, it is not aright way. The should use a common TC. But in the base protocol and dot11 binding protocol, The Mac Type and = tunnel mode Use different type. Base protocol use BITS, while binding MIB is enumerated. How to handle this case in the MIB? Please give some suggestion. =20 In the Base MIB it defines TCs for them: CapwapBaseWtpTunnelMode ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the tunneling modes of operation that are supported by the WTP. The possible value could be: unused(0) - This bit is unused localBridging(1) - Local Bridging Mode, dot3Tunnel(2) - 802.3 Frame Tunnel Mode, nativeTunnel(3) - Native Frame Tunnel Mode." REFERENCE "Section 4.6.42. of CAPWAP Protocol Specification, RFC xxx." SYNTAX BITS { unused(0), localBridging(1), dot3Tunnel(2), nativeTunnel(3) } =20 CapwapBaseWtpMacType ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the MAC mode of operation supported by the WTP. The possible value could be: localMAC(0) - Local-MAC Mode, splitMAC(1) - Split-MAC Mode." both(2) - Both Local-MAC and Split-MAC." REFERENCE "Section 4.6.46. of CAPWAP Protocol Specification, RFC xxx." SYNTAX INTEGER { localMAC(0), splitMAC(1), both(2) } =20 In the dot11 MIB, defines objects based on the TCs. capwapDot11WtpMacType OBJECT-TYPE SYNTAX CapwapWtpMacType MAX-ACCESS read-create STATUS current DESCRIPTION "Represents whether the WTP should run the WLAN in Local or Split MAC modes." REFERENCE "Section 6.1. of CAPWAP Protocol Binding for IEEE 802.11, RFC xxx." ::=3D { capwapDot11WlanConfigEntry 3 } =20 capwapDot11WtpTunnelMode OBJECT-TYPE SYNTAX CapwapWtpTunnelMode MAX-ACCESS read-create STATUS current DESCRIPTION "Represents the frame tunneling type to be used for 802.11 data frames from all stations associated with the WLAN." REFERENCE "Section 6.1. of CAPWAP Protocol Binding for IEEE 802.11, RFC xxx." ::=3D { capwapDot11WlanConfigEntry 4 } =20 Regards Richard --Boundary_(ID_WWmo0A1pKyWxnBCIVS9/sA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

   =  =A1=A1 HI,

The new version = of MIB drafts will use the method suggested by David to close the issue = :

How to handle data type difference of Mac Type and = tunnel mode in the MIBs

  =A1=A1=A1=A1The description = of question and answer to it are as followed.

 

        =   Regards

        =   RIchard

 

-----=D3=CA=BC=FE=D4=AD= =BC=FE-----
=B7=A2=BC=FE=C8=CB: David = Harrington [mailto:ietfdbh@comcast.net]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2008=C4=EA10=D4=C26=C8=D5 22:26
=CA=D5=BC=FE=C8=CB: = 'young'; dromasca@avaya.com
=B3=AD=CB=CD: 'Yong = Zhang'; chelliot@cisco.com
=D6=F7=CC=E2: RE: kindly = give some suggestion for this question

 

Hi,

 <= /p>

My advice remains the = same.

 <= /p>

If you know the enumeration in the = protocol is not likely to change in the future, and my impression is that it will = not, then you can represent the enumerated values in a BITS type in the MIB, so = you can gain the benefit of consistent types for the MAC type and tunnel = modes.

 <= /p>

dbh

 <= /p>

From: young [mailto:young@h3c.com]
Sent: Monday, October 06, 2008 3:34 AM
To: 'David Harrington'; dromasca@avaya.com
Cc: 'Yong Zhang'; chelliot@cisco.com
Subject: kindly give some suggestion for this question

     Hi, kindly give = some suggestion for this question: How to handle data type difference of Mac = Type and tunnel mode in the MIBs

     I gave more explain about my question in my previous email ( it is = below)

I want to close this issue in the = new version.

     For new version, = we have done lots of changes for readability and minimize the gap between MIB = drafts and Protocol.

     It already passes = the tools of Nits, spell and smilint. We plan to publish them within = this week.

    

     Regards

     Richard


=B7=A2=BC=FE=C8=CB: young = [mailto:young@h3c.com]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2008=C4=EA9=D4=C227=C8=D5 9:59
=CA=D5=BC=FE=C8=CB: = 'David Harrington'
=B3=AD=CB=CD: = 'capwap@frascone.com'; 'Yong Zhang'; chelliot@cisco.com
=D6=F7=CC=E2: = =B4=F0=B8=B4: [Capwap] How to handle data type difference of Mac Type and tunnel mode in the = MIBs?

 

       = Hi,

      Sorry, I = have not made my questions clear.

      The problem = is caused by difference between base and 802.11 binding protocol, not by = MIBs themselves.

In them, The Mac Type and tunnel = mode use different type:Base protocol use BITS, while binding protocol is = enumerated.

 

       For = MIB design, I think the valid design is to define TCs for MAC type and = tunnel mode in the Base MIBs.

      When 802.11 binding MIB defines MIB objects of MAC type and tunnel Mode for a = specific WLAN network,

      These = objects will be defined by  those TCs defined in the Base = MIBs,

      But How to = handle the data type difference cause by protocols (base and 802.11 binding = protocol)

   

     = Regards

     = Richard

 

But in the base protocol and = dot11 binding protocol, The Mac Type and tunnel mode for a

Use different = type.

How to handle this case in = the MIB?

Please give some = suggestion.

 

 

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: David = Harrington [mailto:ietfdbh@comcast.net]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2008=C4=EA9=D4=C225=C8=D5 15:33
=CA=D5=BC=FE=C8=CB: = 'young'; capwap@frascone.com
=B3=AD=CB=CD: = chelliot@cisco.com; 'Yong Zhang'
=D6=F7=CC=E2: RE: = [Capwap] How to handle data type difference of Mac Type and tunnel mode in the = MIBs?

 

Hi,=

 

If I understand = the issue properly, your voncern is the difference in types, and changing the type = of one of these would solev the problem.

 

A BITS type = could be used to represent the MacType. This BITS type could represent local = or split by setting only one bit, and it can be used to represent = "both" by setting two bits.

 

I will note that = the tunnelmode is extensible - new BITs can be added to support new types, = and multiple types can be supported on a device. In comparison, MacType can = never be expanded beyond local and split-mic modes the way it is currently = defined. I don't know that anybody will ever invent an alternative to local and = split, but if they do, your enumeration will not be able to represent it very = easily (to add a new mode "foo", you would need to define foo(4), = foo+local(5), foo+split(6), foo+local+split(7). And then if you define a new mode = bar(n), you would need to grow your enumerations combinatorially. Using BITS means = adding one BIT definition.

 

dbh=

 

 

From: young [mailto:young@h3c.com]
Sent: Thursday, September 25, 2008 5:03 AM
To: = capwap@frascone.com
Cc: chelliot@cisco.com; = 'Yong Zhang'
Subject: [Capwap] How to = handle data type difference of Mac Type and tunnel mode in the = MIBs?

Hi,

the Mac Type and tunnel mode = is defined in the base protocol.

And the dot11 binding = protocol use it for a WLAN network.

Currently, Base MIB defines = TCs for Mac Type and tunnel mode as followed, and Dot11 MIB

IMPORTs them and define = objects based on them for a WLAN network.

I think this way is valid. = If each binding MIBs separately defines TC of MAC and

tunnel mode, it is not = aright way. The should use a common TC.

But in the base protocol and = dot11 binding protocol, The Mac Type and tunnel mode

Use different = type.

Base protocol use BITS, = while binding MIB is enumerated.

How to handle this case in = the MIB?

Please give some = suggestion.

 

In the Base MIB it defines = TCs for them:

CapwapBaseWtpTunnelMode = ::=3D TEXTUAL-CONVENTION

    STATUS      current

    = DESCRIPTION

     = ;   "Represents the tunneling modes of operation that = are

     = ;    supported by the WTP.

     = ;    The possible value could be:

     = ;     unused(0)        - This bit is = unused

     = ;     localBridging(1) - Local Bridging Mode,

     = ;     dot3Tunnel(2)    - 802.3 Frame Tunnel = Mode,

        =   nativeTunnel(3)  - Native Frame Tunnel = Mode."

    REFERENCE

     = ;   "Section 4.6.42. of CAPWAP Protocol Specification, RFC = xxx."

    SYNTAX      BITS { unused(0),

     = ;            =       localBridging(1),

     = ;            =       dot3Tunnel(2),

     = ;            =       nativeTunnel(3) }

 

CapwapBaseWtpMacType ::=3D TEXTUAL-CONVENTION

    STATUS      current

    = DESCRIPTION

     = ;   "Represents the MAC mode of operation supported by the = WTP.

     = ;    The possible value could be:

     = ;     localMAC(0) - Local-MAC Mode,

        =   splitMAC(1) - Split-MAC Mode."

        =   both(2)     - Both Local-MAC and Split-MAC."

    = REFERENCE

     = ;   "Section 4.6.46. of CAPWAP Protocol Specification, RFC = xxx."

    SYNTAX      INTEGER { localMAC(0), splitMAC(1), both(2) }

 

In the dot11 MIB, defines objects based on the TCs.

capwapDot11WtpMacType OBJECT-TYPE

    SYNTAX      CapwapWtpMacType

    MAX-ACCESS  read-create

    STATUS      current

    DESCRIPTION

     = ;   "Represents whether the WTP should run the WLAN = in

     = ;    Local or Split MAC modes."

    REFERENCE

     = ;   "Section 6.1. of CAPWAP Protocol Binding for IEEE = 802.11,

     = ;    RFC xxx."

    ::=3D { capwapDot11WlanConfigEntry 3 }

 

capwapDot11WtpTunnelMode OBJECT-TYPE

    SYNTAX      = CapwapWtpTunnelMode

    MAX-ACCESS  read-create

    STATUS      current

    DESCRIPTION

     = ;   "Represents the frame tunneling type to be used for 802.11 = data

     = ;    frames from all stations associated with the = WLAN."

    REFERENCE

     = ;   "Section 6.1. of CAPWAP Protocol Binding for IEEE = 802.11,

     = ;    RFC xxx."

    ::=3D { capwapDot11WlanConfigEntry 4 }

 

Regards

Richard

--Boundary_(ID_WWmo0A1pKyWxnBCIVS9/sA)-- --===============0076241228== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0076241228==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 7 07:01:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA3C3A6B28 for ; Tue, 7 Oct 2008 07:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG+c9Zfuy1IZ for ; Tue, 7 Oct 2008 07:01:34 -0700 (PDT) Received: from amy.tigertech.net (amy.tigertech.net [216.93.176.60]) by core3.amsl.com (Postfix) with ESMTP id 8DB463A6951 for ; Tue, 7 Oct 2008 07:01:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by amy.tigertech.net (Postfix) with ESMTP id E5239678252 for ; Tue, 7 Oct 2008 07:01:38 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0C41C1C40F7D for ; Tue, 7 Oct 2008 07:01:08 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 1DC38440006 for ; Tue, 7 Oct 2008 07:01:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 0A36419EE77 for ; Tue, 7 Oct 2008 07:01:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 3920919EE11 for ; Tue, 7 Oct 2008 07:01:02 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from pass-seymour.com (marussyr001.pass-seymour.com [12.33.96.185]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 7 Oct 2008 07:01:01 -0700 (PDT) Received: from ([172.16.5.211]) by Marussyr001.pass-seymour.com with ESMTP id 5202449.49357383; Tue, 07 Oct 2008 09:52:11 -0400 From: mike.hines@ortronics.com To: capwap@frascone.com Message-ID: Date: Tue, 7 Oct 2008 10:00:42 -0400 X-MIMETrack: Serialize by Router on US-SYR-HUB-01/SRV/GRPLEG(Release 6.5.6|March 06, 2007) at 10/07/2008 10:00:44 AM MIME-Version: 1.0 Subject: [Capwap] Mike Hines/PSL/US is out of the office. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com I will be out of the office starting 10/06/2008 and will not return until 10/09/2008. In my absence, feel free to leave an e-mail or contact Rudy Montgelas at (860) 405-2969 / rudolph.montgelas@ortronics.com for immediate assistance. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 7 12:54:21 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1133A6B61 for ; Tue, 7 Oct 2008 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.352 X-Spam-Level: X-Spam-Status: No, score=-4.352 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5baY3GmaV1kx for ; Tue, 7 Oct 2008 12:54:20 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C8FFD3A6A89 for ; Tue, 7 Oct 2008 12:54:20 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 69BC61C40F4E for ; Tue, 7 Oct 2008 12:54:59 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 4F03C440006 for ; Tue, 7 Oct 2008 12:54:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 350C91CD483 for ; Tue, 7 Oct 2008 12:54:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id AC43B1CD482 for ; Tue, 7 Oct 2008 12:54:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 7 Oct 2008 12:54:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,374,1220227200"; d="scan'208";a="93125254" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 07 Oct 2008 19:54:47 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m97Jslfu018326 for ; Tue, 7 Oct 2008 12:54:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m97JslUE023854 for ; Tue, 7 Oct 2008 19:54:47 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 12:54:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 12:54:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206993AAD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 216: Need to define range for Radio ID field Thread-Index: Ackotnd96wN4pEBFSFSZh4I2DDPlNg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 07 Oct 2008 19:54:47.0681 (UTC) FILETIME=[8D50C710:01C928B6] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Capwap] Issue 216: Need to define range for Radio ID field X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, Yong raised the following issue: I have a question on the radio ID. Does it like the wlan ID with a start value 1, and has valid value range (1..255)? The answer is between one and 31, and the limitation is due to the fact that the RID field in the CAPWAP Header is 5 bits. I believe there is value in simply adding the "one to 31" limitation to all references in the CAPWAP Spec. CAPWAP Chairs and IESG members, given the document is in IESG review, is it possible to address this issue? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 7 12:56:37 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7923A68BD for ; Tue, 7 Oct 2008 12:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.337 X-Spam-Level: X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOZauxnHHYEq for ; Tue, 7 Oct 2008 12:56:36 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E9B083A681A for ; Tue, 7 Oct 2008 12:56:36 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2F8021C40F4F for ; Tue, 7 Oct 2008 12:57:04 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 95247440006 for ; Tue, 7 Oct 2008 12:56:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 882F91CD486 for ; Tue, 7 Oct 2008 12:56:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 4EBC71CD484 for ; Tue, 7 Oct 2008 12:56:58 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 7 Oct 2008 12:56:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,374,1220227200"; d="scan'208";a="170613549" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Oct 2008 19:56:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m97Juwg2005589 for ; Tue, 7 Oct 2008 12:56:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m97Juv54029871 for ; Tue, 7 Oct 2008 19:56:58 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 12:56:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 12:56:05 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206993AB0@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WTP Descriptor length is incorrect Thread-Index: AckotruDqf4Kv098SGaUMBvw97+Ivw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 07 Oct 2008 19:56:49.0265 (UTC) FILETIME=[D5C90610:01C928B6] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Capwap] WTP Descriptor length is incorrect X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, Yong raised the following issue: 4.6.40. You added a new "Num Encrypt", but did no change the len field. It should be >= 33 now. I suspect most people would figure this out, but it would be good to address the issue in the document. Chairs & IESG members, can this be addressed in the spec at this point? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 7 12:57:36 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092203A6A44 for ; Tue, 7 Oct 2008 12:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlLhNMmWOLcz for ; Tue, 7 Oct 2008 12:57:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EE8F53A681A for ; Tue, 7 Oct 2008 12:57:30 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6036E1C40F56 for ; Tue, 7 Oct 2008 12:57:56 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id D8B91440006 for ; Tue, 7 Oct 2008 12:57:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id CCF691A0083 for ; Tue, 7 Oct 2008 12:57:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id A082019FDF9 for ; Tue, 7 Oct 2008 12:57:50 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 7 Oct 2008 12:57:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,374,1220227200"; d="scan'208";a="93126592" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 07 Oct 2008 19:57:50 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m97Jvn5T024321 for ; Tue, 7 Oct 2008 12:57:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m97JvnYL000647 for ; Tue, 7 Oct 2008 19:57:49 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Oct 2008 12:57:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Oct 2008 12:57:29 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206993AB4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 217: Invalid reference to Configuration Status Message Thread-Index: Ackotu2lUnwc+AuTReWSc0p2D/BxNg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 07 Oct 2008 19:57:49.0657 (UTC) FILETIME=[F9C81C90:01C928B6] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Capwap] Issue 217: Invalid reference to Configuration Status Message X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, The following issue was raised by Yong: Binding doc. still use "Configuration Status Message" instead of "Configuration Status Request Message". I believe this to be a very minor change, and am unsure whether we can address the issue given it is in IESG review. Chairs? IESG? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 9 14:26:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7A43A6AD4 for ; Thu, 9 Oct 2008 14:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.379 X-Spam-Level: X-Spam-Status: No, score=-4.379 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8T7my-xgA8C for ; Thu, 9 Oct 2008 14:26:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E497A3A6ABB for ; Thu, 9 Oct 2008 14:26:55 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C78D943045E for ; Thu, 9 Oct 2008 14:27:04 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 9AF38440006 for ; Thu, 9 Oct 2008 14:26:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 701B41CD48E for ; Thu, 9 Oct 2008 14:26:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 2DA0F1CD486 for ; Thu, 9 Oct 2008 14:26:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx3.tigertech.net (Postfix) with ESMTP for ; Thu, 9 Oct 2008 14:26:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,385,1220227200"; d="scan'208";a="89001277" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Oct 2008 21:26:59 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m99LQwMd019189 for ; Thu, 9 Oct 2008 14:26:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m99LQwh8009255 for ; Thu, 9 Oct 2008 21:26:58 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 14:26:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 14:26:47 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206994532@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 219: Encoding of MAC Address in X.509 certificate needs to be clear Thread-Index: AckqVbwgVU1PPWgsR/KlWacxWYf0QA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 09 Oct 2008 21:26:58.0380 (UTC) FILETIME=[C2B1F8C0:01C92A55] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Capwap] Issue 219: Encoding of MAC Address in X.509 certificate needs to be clear X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, The following issue was raised during the IESG Review: >> Beyond the core of Chris' discuss, there are some interoperability > concerns that should be addressed. The common name >> attribute is a directoryString, which can be encoded using any of > several different string types. As described, the >> MAC address can always be encoded using a PrintableString. While I > would suggest verifying this against the installed >> base, the specification should indicate which string type is used >> with > the common name attribute to represent the MAC >> address. Fair enough, and I see that we were not very specific in this regard. I believe the text should read: CAPWAP implementations MUST support certificates where the common name (CN) for both the WTP and AC is the MAC address of that device. The MAC address MUST be encoded in the PrintableString format, using the well recognized MAC address format of 01:23:45:67:89:ab. The CN field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. This seemingly unconventional use of the CN field is consistent with other standards that rely on device certificates that are provisioned during the manufacturing process, such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX [WiMAX]. The commenter has agreed with the resolution. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 9 14:29:09 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B32A3A6AB5 for ; Thu, 9 Oct 2008 14:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.365 X-Spam-Level: X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQtmbeOjgd5S for ; Thu, 9 Oct 2008 14:29:08 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 743BF3A67FC for ; Thu, 9 Oct 2008 14:29:08 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 24B074304A8 for ; Thu, 9 Oct 2008 14:29:09 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 526C3440006 for ; Thu, 9 Oct 2008 14:29:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 473B61D54C6 for ; Thu, 9 Oct 2008 14:29:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id F0A641D53F2 for ; Thu, 9 Oct 2008 14:29:02 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx3.tigertech.net (Postfix) with ESMTP for ; Thu, 9 Oct 2008 14:29:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,385,1220227200"; d="scan'208";a="93913250" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2008 21:29:02 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m99LSxit010023 for ; Thu, 9 Oct 2008 14:28:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m99LSxuH016262 for ; Thu, 9 Oct 2008 21:28:59 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 14:28:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 14:28:49 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206994535@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 220: AC Trust of WTP Image Thread-Index: AckqVgSxSIYSlXd1S6Smf7Hj/SZYZA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 09 Oct 2008 21:28:59.0486 (UTC) FILETIME=[0AE147E0:01C92A56] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Capwap] Issue 220: AC Trust of WTP Image X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com >> Discuss: >> I believe this document needs to acknowledge a lying endpoint >> problem, > especially with respect to firmware update. Specifically: >> >> The firmware update aspects of the CAPWAP protocol specification >> place > a great deal of faith in the WTP. Specifically, the AC is trusting > the WTP to assert the current firmware update, and to indicate whether > the update has been installed. (This is consistent with efforts in > NEA where we specifically excluded the lying endpoint problem, but I > recall that it was somewhat controversial.) >> >> However, there is nothing in the CAPWAP protocol specification to > indicate this level of trust in the WTP. I believe that a discussion > of the trust model, and its limitations, should appear in this > document. I would suggest introducing this concept in section 9, and > expanding it in the security considerations. > > OK - we can add such language to cover the concern you raise: > > > 9. Device Management Operations > > This section defines CAPWAP operations responsible for debugging, > gathering statistics, logging, and firmware management. The > management operations defined in this section are used by the AC to > either push/pull information to/from the WTP, or request that the > WTP > reboot. This section does not deal with the management of the AC > per > se, and assumes that the AC is operational and configured. > > 12.9. WTP Firmware > > The CAPWAP protocol defines a mechanism by which the AC downloads > new > firmware to the WTP. During the session establishment process, the > WTP provides information about its current firmware to the AC. The > AC then decides whether the WTP's firmware needs to be updated. It > is important to note that the CAPWAP specification makes the > explicit > assumption that the WTP is providing the correct firmware version > to > the AC, and is therefore not lying. Further, during the firmware > download process, the CAPWAP protocol does not provide any > mechanisms > to recognize whether the WTP is actually storing the firmware for > future use. > The commenter has agreed with the proposed text. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 9 14:31:16 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0703A6A07 for ; Thu, 9 Oct 2008 14:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.352 X-Spam-Level: X-Spam-Status: No, score=-4.352 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHaR05PmXp3j for ; Thu, 9 Oct 2008 14:31:16 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id F3BEE3A68DB for ; Thu, 9 Oct 2008 14:31:15 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C093D4304D1 for ; Thu, 9 Oct 2008 14:31:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4A7D0440006 for ; Thu, 9 Oct 2008 14:31:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3FA0236100B6 for ; Thu, 9 Oct 2008 14:31:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D635436100C5 for ; Thu, 9 Oct 2008 14:31:02 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 9 Oct 2008 14:31:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,385,1220227200"; d="scan'208";a="172138357" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2008 21:31:00 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m99LV1qp028343 for ; Thu, 9 Oct 2008 14:31:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m99LV0CP017117 for ; Thu, 9 Oct 2008 21:31:00 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 14:31:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Oct 2008 14:30:01 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206994539@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 221: Inconsistency of use of Session ID Thread-Index: AckqVi/XKS/dAO7zSO2PPMdvhhkwLw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 09 Oct 2008 21:31:00.0847 (UTC) FILETIME=[53377FF0:01C92A56] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Capwap] Issue 221: Inconsistency of use of Session ID X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com >> Is there a conflict between the guidance given in NAT Considerations > Case 2 (Section 11, paragraph 2, last sentence) and the guidance in > section 12.2 "Session ID Security"? >> >> From section 11: >> >> The CAPWAP Data Check state, >> which >> establishes the data plane connection and communicates the CAPWAP >> Data Channel Keepalive, includes the Session Identifier message >> element, which is used to bind the control and data plane. Use of >> the Session Identifier message element enables the AC to match the >> control and data plane flows from multiple WTPs behind the same >> NAT >> system (multiple WTPs sharing the same IP address). >> >> From section 12: >> >> For example, an AC MUST NOT associate decrypted > DTLS >> control packets with a particular WTP session based solely on the >> Session ID in the packet header. Instead, identification should >> be >> done based on which DTLS session decrypted the packet. Otherwise > one >> authenticated WTP could spoof another authenticated WTP by >> altering >> the Session ID in the encrypted CAPWAP header. > > I see. Well, both of these sections are covering different cases. The > first is to cover the correlation of the control and data plane - > which is why the Session Identifier exists. The second one is > different, which is to differentiate different control plane packets. > That said, it does make sense to ensure that we have some consistency > in the use of the Session ID field. The text would look like: > > > 11. NAT Considerations > [...] > The CAPWAP Data > Check state, which establishes the data plane connection and > communicates the CAPWAP Data Channel Keepalive, includes the > Session > Identifier message element, which is used to bind the control and > data plane. Use of the Session Identifier message element enables > the AC to match the control and data plane flows from multiple WTPs > behind the same NAT system (multiple WTPs sharing the same IP > address). CAPWAP implementations MUST also use DTLS session > information on any encrypted CAPWAP channel to validate the source > of > both the control and data plane, as described in Section 12.2. > The commenter has agreed with the proposed resolution. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 07:22:54 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8BA3A6A34 for ; Fri, 10 Oct 2008 07:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.41 X-Spam-Level: X-Spam-Status: No, score=-4.41 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UYECixKei5p for ; Fri, 10 Oct 2008 07:22:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 84EF73A69C5 for ; Fri, 10 Oct 2008 07:22:48 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7D8F61C40F7A for ; Fri, 10 Oct 2008 07:23:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C6AA2440006 for ; Fri, 10 Oct 2008 07:23:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B8999361008D for ; Fri, 10 Oct 2008 07:23:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 56CB2361009E for ; Fri, 10 Oct 2008 07:23:27 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 07:23:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="172639973" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Oct 2008 14:23:21 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9AENLtT029650 for ; Fri, 10 Oct 2008 07:23:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9AENLKp024973 for ; Fri, 10 Oct 2008 14:23:21 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 07:23:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 07:23:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20699471E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 223: Provide reasoning for MAC Address in CN Field Thread-Index: Ackq478KsV9LRobqRR6+XVAwHAes2w== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 10 Oct 2008 14:23:21.0359 (UTC) FILETIME=[BF6219F0:01C92AE3] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Capwap] Issue 223: Provide reasoning for MAC Address in CN Field X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com During the IESG review, there were a few comments raised about the use of the MAC Address in the X.509 certificate Common Name (CN) field. There were two agreements made during this time, the first was to provide references to other standards that were making use of this convention (e.g., Packet Cable, WiMAX, DOCSIS). The second was to include some text about the reasoning for using the MAC Address in the CN Field vs. some other (more appropriate) identifier. After a few back and forths, we agreed on the following text: 2.4.4.3. Certificate Usage [...] CAPWAP implementations MUST support certificates where the common name (CN) for both the WTP and AC is the MAC address of that device. The MAC address MUST be encoded in the PrintableString format, using the well recognized MAC address format of 01:23:45:67:89:ab. The CN field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. This seemingly unconventional use of the CN field is consistent with other standards that rely on device certificates that are provisioned during the manufacturing process, such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX [WiMAX]. See Section 12.8 for more information on the use of the MAC Address in the CN field. 12.8. Use of MAC Address in CN Field The CAPWAP protocol is an evolution of an existing protocol [I-D.ohara-capwap-lwapp] which is implemented on a large number of already deployed ACs and WTPs. Everyone of these devices have an existing X.509 certificate, which is provisioned at manufacturing time. These X.509 certificates use the device's MAC Address in the Common Name (CN) field. It is well understood that encoding the MAC Address in the CN field is less than optimal, and using the SubjectAltName field would be preferable. However, at the time of publication, there is no URN specification that allows for the MAC Address to be used in the SubjectAltName field. As such a specification is published by the IETG, future versions of the CAPWAP protocol MAY require support for the new URN scheme. 17.2. Informational References [...] [PacketCable] "PacketCable Security Specification PKT-SP-SEC-I12- 050812", August 2005, . [CableLabs] "OpenCable System Security Specification OC-SP-SEC-I07- 061031", October 2006, . [WiMAX] "WiMAX Forum X.509 Device Certificate Profile Approved Specification V1.0.1", April 2008, . _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 08:01:31 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB633A69FF for ; Fri, 10 Oct 2008 08:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmIsLYabVZG7 for ; Fri, 10 Oct 2008 08:01:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 634833A6939 for ; Fri, 10 Oct 2008 08:01:30 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EC42D1C40F70 for ; Fri, 10 Oct 2008 08:02:02 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 90546440006 for ; Fri, 10 Oct 2008 08:01:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 7254519F6C5 for ; Fri, 10 Oct 2008 08:01:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 2E6F919F40F for ; Fri, 10 Oct 2008 08:01:57 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx3.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 08:01:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="89368151" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2008 15:01:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9AF12P3017211 for ; Fri, 10 Oct 2008 08:01:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9AF120a005951 for ; Fri, 10 Oct 2008 15:01:02 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 08:01:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 08:01:01 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206994742@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20684AB08@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 215: Sequence number questions Thread-Index: AckfK9UN6ZT30aMpSiO6Q8OKrtJXfQLvPG4A References: <4FF84B0BC277FF45AA27FE969DD956A20684AB08@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 10 Oct 2008 15:01:02.0450 (UTC) FILETIME=[03193520:01C92AE9] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Capwap] Issue 215: Sequence number questions X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com The following exchange occurred after the text below was agreed upon: > It is also possible to become out of sync with this if the sender of > requests do what is not recommend and aborts transmission > 16 times. Then the sender and receiver will have there sequence number > windows out of sync. I don't think there is a significant issue here. > But a warning about this might with the SHOULD NOT abort sentence may > provide good motivation. OK, I would propose adding the last sentence at the end of the paragraph below, which I believe is sufficient with the SHOULD NOT statement: 4.5.3. Retransmissions [...] If the sender stops retransmitting a Request message before reaching MaxRetransmit retransmissions (which leads to transition to DTLS Teardown, as described in Section 2.3.1), it cannot know whether the recipient received and processed the Request or not. In most situations, the sender SHOULD NOT do this, and instead continue retransmitting until a Response message is received, or transition to DTLS Teardown occurs. However, if the sender does decide to continue the connection with a new or modified Request message, the new message MUST have a new Sequence Number, and be treated as a new Request message by the receiver. Note that there is a high chance that both the WTP and the AC's sequence numbers will become out of sync. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, September 25, 2008 9:29 AM To: capwap@frascone.com Subject: [Capwap] Issue 215: Sequence number questions All, The following comment was raised during the IESG Review: > > Section 4.5.3: > > > > If an older Request message (with smaller > > Sequence Number modulo 32) is received, it MUST be ignored. > > > > Smaller is not super obvious here. I would interpret it as > > (Last_nr-15)%32 to (Last_nr-1)%32. Saying something like that might > > be clearer on which sequence numbers that are okay. > Got it. How about the following: Implementations MUST keep track of the Sequence Number of the last received Request message, and MUST cache the corresponding Response message. If a retransmission with the same Sequence Number is received, the cached Response message MUST be retransmitted without re-processing the Request. If an older Request message is received, meaning one where the sequence number is smaller, it MUST be ignored. A newer Request message, meaning one whose sequence number is larger, is processed as usual. Note: A sequence number is considered "smaller" when s1 is smaller than s2 modulo 256 if and only if (s1s2 and (s1-s2)>128) PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 08:11:48 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0393A68B6 for ; Fri, 10 Oct 2008 08:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.385 X-Spam-Level: X-Spam-Status: No, score=-4.385 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK0+ULFKhUMk for ; Fri, 10 Oct 2008 08:11:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2A6BA3A6829 for ; Fri, 10 Oct 2008 08:11:48 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 34EDC1C40F39 for ; Fri, 10 Oct 2008 08:12:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C50B4440006 for ; Fri, 10 Oct 2008 08:12:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B66C836100A8 for ; Fri, 10 Oct 2008 08:12:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 71B1A3610060 for ; Fri, 10 Oct 2008 08:12:21 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 08:12:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="107828053" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2008 15:12:21 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9AFCL2h009562 for ; Fri, 10 Oct 2008 08:12:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9AFCKrO010834 for ; Fri, 10 Oct 2008 15:12:20 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 08:12:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 08:12:18 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206994752@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 225: Need to provide clarity on use of ports to support middleboxes Thread-Index: Ackq6pXsNonKADlPSpqoJxwtMC12YQ== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 10 Oct 2008 15:12:19.0846 (UTC) FILETIME=[96DBA260:01C92AEA] Authentication-Results: sj-dkim-2; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Capwap] Issue 225: Need to provide clarity on use of ports to support middleboxes X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, During the IESG review, the following issue was raised: > Section 11 and 9: > > Another issue with NATs that my read through don't think is covered in > enough detail is the importance of the source address for the CA->WTP > Image Data Request messages. They need to be sent from the CA control > channel destination port on which it received the Image Data Request > from the WTP. And it needs to send to the source address present in that > download initiating request. > > For the CA behind NAT the same applies for the WTP data upload. The issue being raised is that the WTP and the AC need to ensure that they are responding back on the same port on which a request was received. This is necessary for NAT traversal. I have proposed the following text, which the commenter agreed with: 3. CAPWAP Transport [...] In order for CAPWAP to be compatible with potential middleboxes in the network, CAPWAP implementations MUST send return traffic from the same port on which it received traffic from a given peer. Further, any unsolicited requests generated by a CAPWAP node MUST be sent on the same port. 11. NAT Considerations [...] In order for CAPWAP to be compatible with potential middleboxes in the network, CAPWAP implementations MUST send return traffic from the same port on which it received traffic from a given peer. Further, any unsolicited requests generated by a CAPWAP node MUST be sent on the same port. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 08:43:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37C13A69C9 for ; Fri, 10 Oct 2008 08:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.395 X-Spam-Level: X-Spam-Status: No, score=-4.395 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Neiz0hW5ghO2 for ; Fri, 10 Oct 2008 08:43:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 925F63A6977 for ; Fri, 10 Oct 2008 08:43:37 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 951061C407EC for ; Fri, 10 Oct 2008 08:44:24 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id CFCEE440023 for ; Fri, 10 Oct 2008 08:44:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 9DA5C19F8B1 for ; Fri, 10 Oct 2008 08:44:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 5249719F8AF for ; Fri, 10 Oct 2008 08:44:18 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx3.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 08:44:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="89391232" Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2008 15:44:17 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id m9AFiGjc004269 for ; Fri, 10 Oct 2008 08:44:16 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9AFiE0r009148 for ; Fri, 10 Oct 2008 15:44:16 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 08:42:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 08:42:34 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206994786@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 226: Only the encryption keys should be sent to the WTP Thread-Index: Ackq7tC9bVkLGOSPSVeaMgNbEIFhZA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 10 Oct 2008 15:42:35.0705 (UTC) FILETIME=[D131BA90:01C92AEE] Authentication-Results: sj-dkim-5; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); Subject: [Capwap] Issue 226: Only the encryption keys should be sent to the WTP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, During the IESG review, the following issue was raised: > When TKIP or CCMP encryption is used, and WTP does the encryption, it > obviously needs the key (TK) for TKIP or CCMP. However, currently the > AC also sends two other keys, the EAPOL Key Confirmation Key (KCK) and > Key Encryption Key (KEK), to the WTP, even though the WTP does not > seem to need these keys for anything. The principle of least > privilege would suggest that the AC shouldn't send these keys. Why > not send just the needed keys? Or does the WTP need the KCK/KEK > for something? Looking into this issue deeper, we agreed that we do not need to include the KEK and KCK. In fact, the spec should have said TK, not PTK. That said, I believe that in addition to that change, we could improve the spec to ensure interoperability. I would therefore recommend the following changes: 6.1. IEEE 802.11 Add WLAN [...] Key: A Session Key, whose length is known via the key length field, used to provide data privacy. For encryption schemes that employ a separate encryption key for unicast and multicast traffic, the key included here only applies to multicast frames, and the cipher suite is specified in an accompanied RSN Information Element. In these scenarios, the key and cipher information is communicated via the Add Station message element, see Section 4.6.8 in [I-D.ietf-capwap-protocol-specification] and the IEEE 802.11 Station Session Key message element, see Section 6.15. When used with WEP, the key field includes the broadcast key. When used with CCMP, the Key field includes the 128-bit Group Temporal Key. When used with TKIP, the Key field includes the 256-bit Group Temporal Key (which consists of a 128-bit key used as input for TKIP key mixing, and two 64-bit keys used for Michael). 6.15. IEEE 802.11 Station Session Key [...] Key: The pairwise key the WTP is to use when encrypting traffic to/ from the station. The format of the keys differ based on the crypto algorithm used. For unicast WEP keys, the Key field consists of the actual unicast encryption key (note, this is used when WEP is used in conjunction with 802.1X, and therefore a unicast encryption key exists). When used with CCMP, the Key field includes the 128-bit Temporal Key. When used with TKIP, the Key field includes the 256-bit Temporal Key (which consists of a 128-bit key used as input for TKIP key mixing, and two 64-bit keys used for Michael). 6.21. IEEE 802.11 Update WLAN [...] Key: A Session Key, whose length is known via the key length field, used to provide data privacy. For static WEP keys, which is true when the 'Key Status' bit is set to one, this key is used for both unicast and multicast traffic. For encryption schemes that employ a separate encryption key for unicast and multicast traffic, the key included here only applies to multicast data, and the cipher suite is specified in an accompanied RSN Information Element. In these scenarios, the key, and cipher information, is communicated via the Add Station message element, see Section 4.6.8 in [I-D.ietf-capwap-protocol-specification]. When used with WEP, the key field includes the broadcast key. When used with CCMP, the Key field includes the 128-bit Group Temporal Key. When used with TKIP, the Key field includes the 256-bit Group Temporal Key (which consists of a 128-bit key used as input for TKIP key mixing, and two 64-bit keys used for Michael). PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 08:46:19 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4673A6ADF for ; Fri, 10 Oct 2008 08:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQXBG7zQuuFg for ; Fri, 10 Oct 2008 08:46:18 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6193E3A69C9 for ; Fri, 10 Oct 2008 08:46:18 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6EFE61C40F65 for ; Fri, 10 Oct 2008 08:47:05 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 568E9440006 for ; Fri, 10 Oct 2008 08:46:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 3CBC119F8B4 for ; Fri, 10 Oct 2008 08:46:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id E213A19F8BB for ; Fri, 10 Oct 2008 08:46:56 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx3.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 08:46:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="107838360" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2008 15:46:56 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9AFkuEI025048 for ; Fri, 10 Oct 2008 08:46:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9AFkuZQ011370 for ; Fri, 10 Oct 2008 15:46:56 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 08:46:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 08:46:54 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20699478E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 226: Only the encryption keys should be sent to the WTP Thread-Index: Ackq7tC9bVkLGOSPSVeaMgNbEIFhZAAAGpZA From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 10 Oct 2008 15:46:54.0937 (UTC) FILETIME=[6BB56490:01C92AEF] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] Issue 226: Only the encryption keys should be sent to the WTP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com A follow on comment was made by the IESG, which is: > Figures 2, 5, and 6 also mention "PTK", and should be changed to either "TK" > or just "key" (since these figures are just illustrative examples, they don't > really have to contain all the details) Well... You've unfortunately (or fortunately) found another problem, and that's not just that the figures are incorrect, but the way they represented the message element was inconsistent with the current draft. I've taken the liberty to clean up the figure, and the associated text that describes what needs to be included in each message. 2.2.1. Split MAC [...] Client WTP AC Beacon <----------------------------- Probe Request ----------------------------( - )-------------------------> Probe Response <----------------------------- 802.11 AUTH/Association <---------------------------------------------------------> Station Configuration Request [Add Station (Station MAC Address), IEEE 802.11 Add Station (WLAN ID), IEEE 802.11 Session Key(Flag=A)] <--------------------------> 802.1X Authentication & 802.11 Key Exchange <---------------------------------------------------------> Station Configuration Request [Add Station(Station MAC Address), IEEE 802.11 Add Station (WLAN ID), IEEE 802.11 Station Session Key(Flag=C)] <--------------------------> 802.11 Action Frames <---------------------------------------------------------> 802.11 DATA (1) <---------------------------( - )-------------------------> Figure 2: Split MAC Message Flow [...] o Once the association is complete, the AC transmits a Station Configuration Request message, which includes an Add Station message element, to the WTP (see Section 4.6.8 in [I-D.ietf-capwap-protocol-specification]). In the above example, the WLAN was configured for IEEE 802.1X, and therefore the IEEE 802.11 Station Session Key is included with the flag field's 'A' bit set. [...] o If the WTP is providing encryption/decryption services, once the client has completed the IEEE 802.11 key exchange, the AC transmits another Station Configuration Request message, which includes: - An Add Station message element. - An IEEE 802.11 Add Station message element, which includes the WLAN Identifier the station has associated with. - An IEEE 802.11 Station Session Key message element, which includes the pairwise encryption key. - An IEEE 802.11 Information Element message element which includes the obust Security Network Information Element (RSNIE) to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP). o If the WTP is providing encryption/decryption services, once the client has completed the IEEE 802.11 key exchange, the AC transmits another Station Configuration Request message, which includes: - An Add Station message element. - An IEEE 802.11 Add Station message element, which includes the WLAN Identifier the station has associated with. - An IEEE 802.11 Station Session Key message element, which includes the pairwise encryption key. - An IEEE 802.11 Information Element message element which includes the Robust Security Network Information Element (RSNIE) to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP). o If the AC is providing encryption/decryption services, once the client has completed the IEEE 802.11 key exchange, the AC transmits another Station Configuration Request message, which includes: - An Add Station message element. - An IEEE 802.11 Add Station message element, which includes the WLAN Identifier the station has associated with. - An IEEE 802.11 Station Session Key message element with the flag fields' 'C' bit enabled (indicating that the AC will provide crypto services). [...] 2.2.2. Local MAC [...] Client WTP AC Beacon <----------------------------- Probe <----------------------------> 802.11 AUTH <----------------------------- 802.11 Association <---------------------------( - )-------------------------> Station Configuration Request [Add Station (Station MAC Address), IEEE 802.11 Add Station (WLAN ID), IEEE 802.11 Session Key(Flag=A)] <--------------------------> 802.1X Authentication & 802.11 Key Exchange <---------------------------------------------------------> Station Configuration Request [Add Station(Station MAC Address), IEEE 802.11 Add Station (WLAN ID), IEEE 802.11 Station session Key (Key=x), IEEE 802.11 Information Element(RSNIE(Pairwise Cipher=CCMP))] <--------------------------> 802.11 Action Frames <---------------------------------------------------------> 802.11 DATA <-----------------------------> Figure 5: Local MAC Message Flow [...] o Once the association is complete, the AC transmits a Station Configuration Request message, which includes the Add Station message element, to the WTP (see Section 4.6.8 in [I-D.ietf-capwap-protocol-specification]). In the above example, the WLAN was configured for IEEE 802.1X, and therefore the IEEE 802.11 Station Session Key is included with the flag field's 'A' bit set. [...] o The AC transmits another Station Configuration Request message, which includes: - An Add Station message element, which MAY include a Virtual LAN (VLAN) [IEEE.802-1Q.2005] name, which when present is used by the WTP to identify the VLAN on which the user's data frames are to be bridged. - An IEEE 802.11 Add Station message element, which includes the WLAN Identifier the station has associated with - An IEEE 802.11 Station Session Key message element, which includes the pairwise encryption key. - An IEEE 802.11 Information Element message element which includes the RSNIE to the WTP, stating the security policy to enforce for the client (in this case AES-CCMP). 2.3. Roaming Behavior [...] Figure 6 shows an example of a currently associated station moving from its "Old WTP" to a "New WTP". The figure is valid for multiple different security policies, including IEEE 802.1X and Wireless Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA]. In the event that key caching was employed, the 802.1X Authentication step would be eliminated. Note that the example represents one where crypto services are provided by the WTP, so in a case where the AC provided this function the last Station Configuration Request would be different. Client Old WTP New WTP AC Association Request/Response <--------------------------------------( - )--------------> Station Configuration Request [Add Station (Station MAC Address), IEEE 802.11 Add Station (WLAN ID), IEEE 802.11 Session Key(Flag=A)] <----------------> 802.1X Authentication (if no key cache entry exists) <--------------------------------------( - )--------------> 802.11 4-way Key Exchange <--------------------------------------( - )--------------> Station Configuration Request [Delete Station] <----------------------------------> Station Configuration Request [Add Station(Station MAC Address), IEEE 802.11 Add Station (WLAN ID), IEEE 802.11 Station session Key (Key=x), IEEE 802.11 Information Element(RSNIE(Pairwise Cipher=CCMP))] <----------------> Figure 6: Client Roaming Example PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Friday, October 10, 2008 8:43 AM To: capwap@frascone.com Subject: Issue 226: Only the encryption keys should be sent to the WTP All, During the IESG review, the following issue was raised: > When TKIP or CCMP encryption is used, and WTP does the encryption, it > obviously needs the key (TK) for TKIP or CCMP. However, currently the > AC also sends two other keys, the EAPOL Key Confirmation Key (KCK) and > Key Encryption Key (KEK), to the WTP, even though the WTP does not > seem to need these keys for anything. The principle of least > privilege would suggest that the AC shouldn't send these keys. Why > not send just the needed keys? Or does the WTP need the KCK/KEK for > something? Looking into this issue deeper, we agreed that we do not need to include the KEK and KCK. In fact, the spec should have said TK, not PTK. That said, I believe that in addition to that change, we could improve the spec to ensure interoperability. I would therefore recommend the following changes: 6.1. IEEE 802.11 Add WLAN [...] Key: A Session Key, whose length is known via the key length field, used to provide data privacy. For encryption schemes that employ a separate encryption key for unicast and multicast traffic, the key included here only applies to multicast frames, and the cipher suite is specified in an accompanied RSN Information Element. In these scenarios, the key and cipher information is communicated via the Add Station message element, see Section 4.6.8 in [I-D.ietf-capwap-protocol-specification] and the IEEE 802.11 Station Session Key message element, see Section 6.15. When used with WEP, the key field includes the broadcast key. When used with CCMP, the Key field includes the 128-bit Group Temporal Key. When used with TKIP, the Key field includes the 256-bit Group Temporal Key (which consists of a 128-bit key used as input for TKIP key mixing, and two 64-bit keys used for Michael). 6.15. IEEE 802.11 Station Session Key [...] Key: The pairwise key the WTP is to use when encrypting traffic to/ from the station. The format of the keys differ based on the crypto algorithm used. For unicast WEP keys, the Key field consists of the actual unicast encryption key (note, this is used when WEP is used in conjunction with 802.1X, and therefore a unicast encryption key exists). When used with CCMP, the Key field includes the 128-bit Temporal Key. When used with TKIP, the Key field includes the 256-bit Temporal Key (which consists of a 128-bit key used as input for TKIP key mixing, and two 64-bit keys used for Michael). 6.21. IEEE 802.11 Update WLAN [...] Key: A Session Key, whose length is known via the key length field, used to provide data privacy. For static WEP keys, which is true when the 'Key Status' bit is set to one, this key is used for both unicast and multicast traffic. For encryption schemes that employ a separate encryption key for unicast and multicast traffic, the key included here only applies to multicast data, and the cipher suite is specified in an accompanied RSN Information Element. In these scenarios, the key, and cipher information, is communicated via the Add Station message element, see Section 4.6.8 in [I-D.ietf-capwap-protocol-specification]. When used with WEP, the key field includes the broadcast key. When used with CCMP, the Key field includes the 128-bit Group Temporal Key. When used with TKIP, the Key field includes the 256-bit Group Temporal Key (which consists of a 128-bit key used as input for TKIP key mixing, and two 64-bit keys used for Michael). PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 08:59:25 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBB03A698C for ; Fri, 10 Oct 2008 08:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.372 X-Spam-Level: X-Spam-Status: No, score=-4.372 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ajXgPZc8OqW for ; Fri, 10 Oct 2008 08:59:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 934FD3A67B0 for ; Fri, 10 Oct 2008 08:59:23 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9F1051C40F63 for ; Fri, 10 Oct 2008 09:00:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 27A92440006 for ; Fri, 10 Oct 2008 09:00:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0D77236100CA for ; Fri, 10 Oct 2008 09:00:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2A64E36100BF for ; Fri, 10 Oct 2008 09:00:04 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 09:00:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="89400163" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2008 16:00:03 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9AG03Mi023757 for ; Fri, 10 Oct 2008 09:00:03 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m9AG02rv022218 for ; Fri, 10 Oct 2008 16:00:03 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 09:00:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 08:59:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2069947B2@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206993AB4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 217: Invalid reference to Configuration StatusMessage Thread-Index: Ackotu2lUnwc+AuTReWSc0p2D/BxNgCOkRcg References: <4FF84B0BC277FF45AA27FE969DD956A206993AB4@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 10 Oct 2008 16:00:00.0570 (UTC) FILETIME=[3FFB79A0:01C92AF1] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Capwap] Issue 217: Invalid reference to Configuration StatusMessage X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, Here is the proposed text for this issue: 5.7. Configuration Status Request Message The following IEEE 802.11 specific message elements MAY be included in the CAPWAP Configuration Status Request Message. More than one of each message element listed MAY be included. PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, October 07, 2008 12:57 PM To: capwap@frascone.com Subject: [Capwap] Issue 217: Invalid reference to Configuration StatusMessage All, The following issue was raised by Yong: Binding doc. still use "Configuration Status Message" instead of "Configuration Status Request Message". I believe this to be a very minor change, and am unsure whether we can address the issue given it is in IESG review. Chairs? IESG? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 09:00:53 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A3D3A6AD1 for ; Fri, 10 Oct 2008 09:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.361 X-Spam-Level: X-Spam-Status: No, score=-4.361 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVhLTos6Ww0X for ; Fri, 10 Oct 2008 09:00:52 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3F40D3A6A2A for ; Fri, 10 Oct 2008 09:00:52 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 544C11C40F5F for ; Fri, 10 Oct 2008 09:01:37 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 7B66F440006 for ; Fri, 10 Oct 2008 09:01:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 64C9519F92D for ; Fri, 10 Oct 2008 09:01:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 2513519F927 for ; Fri, 10 Oct 2008 09:01:32 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx3.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 09:01:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,390,1220227200"; d="scan'208";a="107843447" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2008 16:01:32 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9AG1VJc013522 for ; Fri, 10 Oct 2008 09:01:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9AG1QVF008093 for ; Fri, 10 Oct 2008 16:01:31 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Oct 2008 09:01:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 09:01:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2069947B9@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206993AB0@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] WTP Descriptor length is incorrect Thread-Index: AckotruDqf4Kv098SGaUMBvw97+IvwCOph5g References: <4FF84B0BC277FF45AA27FE969DD956A206993AB0@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 10 Oct 2008 16:01:29.0581 (UTC) FILETIME=[750979D0:01C92AF1] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Capwap] WTP Descriptor length is incorrect X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, Here is the proposed text for the issue: 4.6.40. WTP Descriptor [...] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Radios | Radios in use | Num Encrypt |Encryp Sub-Elmt| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encryption Sub-Element | Descriptor Sub-Element... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 39 for WTP Descriptor Length: >= 33 PatC -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, October 07, 2008 12:56 PM To: capwap@frascone.com Subject: [Capwap] WTP Descriptor length is incorrect All, Yong raised the following issue: 4.6.40. You added a new "Num Encrypt", but did no change the len field. It should be >= 33 now. I suspect most people would figure this out, but it would be good to address the issue in the document. Chairs & IESG members, can this be addressed in the spec at this point? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 12:44:10 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C957A3A690F for ; Fri, 10 Oct 2008 12:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU+2l9Q0-rgS for ; Fri, 10 Oct 2008 12:44:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A47693A67A1 for ; Fri, 10 Oct 2008 12:44:09 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6019F1C40F78 for ; Fri, 10 Oct 2008 12:44:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 90D81440006 for ; Fri, 10 Oct 2008 12:44:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6DF2E36100D2 for ; Fri, 10 Oct 2008 12:44:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 08CB936100C9 for ; Fri, 10 Oct 2008 12:44:19 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 12:44:18 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9AJi8uH013099; Fri, 10 Oct 2008 14:44:09 -0500 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Oct 2008 22:43:47 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Oct 2008 14:43:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 14:43:44 -0500 Message-ID: <2198383E1141814486F0B881B3260CF502D6C64C@daebe103.NOE.Nokia.com> In-reply-to: <4FF84B0BC277FF45AA27FE969DD956A20699471E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 223: Provide reasoning for MAC Address in CN Field Thread-Index: Ackq478KsV9LRobqRR6+XVAwHAes2wAKf+iQ References: <4FF84B0BC277FF45AA27FE969DD956A20699471E@xmb-sjc-235.amer.cisco.com> From: To: , X-OriginalArrivalTime: 10 Oct 2008 19:43:45.0996 (UTC) FILETIME=[8228E8C0:01C92B10] X-Nokia-AV: Clean Subject: Re: [Capwap] Issue 223: Provide reasoning for MAC Address in CN Field X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi All, Sorry I was not part of IESG review so if this repeats points raised there apologies... The uses of MAC as CN (or in general as an ID) were fine when the devices never moved and had no need for privacy concerns, and had no need to interwork with other networks because they were single mode access devices. The use of CN in WiMAX is primarily stemming from the early model of WiMAX as extension of cable, before WiMAX mobility. In mobile, multi access devices, the identifier(s) need to be treatable separately from the address(es) at all layers. Would we accept a slight change to the proposed text to emphasize the distinctions here: 2.4.4.3 [...] This seemingly unconventional use of the CN field is consistent with other standards that rely on device certificates that are provisioned during the manufacturing process, such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX [WiMAX]. 2.4.4.3 [...] This use of the MAC address as an identifier is consistent with other standards for wired or fixed wireless network devices, that rely on device certificates that are provisioned during the manufacturing process, such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX [WiMAX]. If changes along these lines would be acceptable, some similar change to 12.8 would be proposed. Best Regards, Michael -----Original Message----- From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: 10 October, 2008 07:23 To: capwap@frascone.com Subject: [Capwap] Issue 223: Provide reasoning for MAC Address in CN Field During the IESG review, there were a few comments raised about the use of the MAC Address in the X.509 certificate Common Name (CN) field. There were two agreements made during this time, the first was to provide references to other standards that were making use of this convention (e.g., Packet Cable, WiMAX, DOCSIS). The second was to include some text about the reasoning for using the MAC Address in the CN Field vs. some other (more appropriate) identifier. After a few back and forths, we agreed on the following text: 2.4.4.3. Certificate Usage [...] CAPWAP implementations MUST support certificates where the common name (CN) for both the WTP and AC is the MAC address of that device. The MAC address MUST be encoded in the PrintableString format, using the well recognized MAC address format of 01:23:45:67:89:ab. The CN field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. This seemingly unconventional use of the CN field is consistent with other standards that rely on device certificates that are provisioned during the manufacturing process, such as Packet Cable [PacketCable], Cable Labs [CableLabs] and WiMAX [WiMAX]. See Section 12.8 for more information on the use of the MAC Address in the CN field. 12.8. Use of MAC Address in CN Field The CAPWAP protocol is an evolution of an existing protocol [I-D.ohara-capwap-lwapp] which is implemented on a large number of already deployed ACs and WTPs. Everyone of these devices have an existing X.509 certificate, which is provisioned at manufacturing time. These X.509 certificates use the device's MAC Address in the Common Name (CN) field. It is well understood that encoding the MAC Address in the CN field is less than optimal, and using the SubjectAltName field would be preferable. However, at the time of publication, there is no URN specification that allows for the MAC Address to be used in the SubjectAltName field. As such a specification is published by the IETG, future versions of the CAPWAP protocol MAY require support for the new URN scheme. 17.2. Informational References [...] [PacketCable] "PacketCable Security Specification PKT-SP-SEC-I12- 050812", August 2005, . [CableLabs] "OpenCable System Security Specification OC-SP-SEC-I07- 061031", October 2006, . [WiMAX] "WiMAX Forum X.509 Device Certificate Profile Approved Specification V1.0.1", April 2008, . _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 19:45:33 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B644228C12C for ; Fri, 10 Oct 2008 19:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgmEo8OXcsG7 for ; Fri, 10 Oct 2008 19:45:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 198EF3A6ADA for ; Fri, 10 Oct 2008 19:45:31 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E5BF51C40F54 for ; Fri, 10 Oct 2008 19:45:53 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 6D433440006 for ; Fri, 10 Oct 2008 19:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 5AB451CD4CC for ; Fri, 10 Oct 2008 19:45:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 2C5A01CD4C9 for ; Fri, 10 Oct 2008 19:45:50 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx3.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 19:45:50 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id BF9C23A69F4; Fri, 10 Oct 2008 19:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081011024501.BF9C23A69F4@core3.amsl.com> Date: Fri, 10 Oct 2008 19:45:01 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D Action:draft-ietf-capwap-base-mib-01.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Base MIB Author(s) : Y. Shi, et al. Filename : draft-ietf-capwap-base-mib-01.txt Pages : 53 Date : 2008-10-10 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-base-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-base-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-10194334.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 10 20:01:05 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8935B3A6898 for ; Fri, 10 Oct 2008 20:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRAaThtgsefS for ; Fri, 10 Oct 2008 20:01:04 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id BD1223A69A8 for ; Fri, 10 Oct 2008 20:00:54 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D564F1C40F53 for ; Fri, 10 Oct 2008 20:00:53 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 497C7440006 for ; Fri, 10 Oct 2008 20:00:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 3C7671CD4C9 for ; Fri, 10 Oct 2008 20:00:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 0F2DB1CD4BB for ; Fri, 10 Oct 2008 20:00:50 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx3.tigertech.net (Postfix) with ESMTP for ; Fri, 10 Oct 2008 20:00:50 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id B3E3E3A699E; Fri, 10 Oct 2008 20:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081011030001.B3E3E3A699E@core3.amsl.com> Date: Fri, 10 Oct 2008 20:00:01 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D Action:draft-ietf-capwap-802dot11-mib-01.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Binding MIB for IEEE 802.11 Author(s) : Y. Shi, et al. Filename : draft-ietf-capwap-802dot11-mib-01.txt Pages : 24 Date : 2008-10-10 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol for IEEE 802.11 wireless binding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-802dot11-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-802dot11-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-10194604.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Oct 12 19:12:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AB63A6B5A for ; Sun, 12 Oct 2008 19:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[AWL=1.999, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFx+oDUmrDNy for ; Sun, 12 Oct 2008 19:12:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A95033A69A5 for ; Sun, 12 Oct 2008 19:12:55 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 822A01C40300 for ; Sun, 12 Oct 2008 19:12:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D503BD04067 for ; Sun, 12 Oct 2008 19:12:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C9F1E34ACA8F for ; Sun, 12 Oct 2008 19:12:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 8CE5034ACA85 for ; Sun, 12 Oct 2008 19:12:39 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Sender first seen 2 mons 18 days 14:12:29 ago / dynamic or unknown reverse DNS) Received: from huawei-3com.com (unknown [221.12.31.56]) by mx1.tigertech.net (Postfix) with ESMTP for ; Sun, 12 Oct 2008 19:12:38 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8N00CPNNAG1V@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 13 Oct 2008 10:08:49 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8N00BRCLVMY8@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 13 Oct 2008 09:38:11 +0800 (CST) Received: from unknown (HELO s00338) ([10.154.68.129]) by mailsecurity.h3c.com with ESMTP; Mon, 13 Oct 2008 09:34:16 +0800 Date: Mon, 13 Oct 2008 09:37:14 +0800 From: young To: capwap@frascone.com Message-id: <000001c92cd4$3918b820$81449a0a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook, Build 10.0.6838 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Thread-index: Acks1Dgj5QwBKjaEQc2+Wg5Aar/TTA== Subject: [Capwap] The change logs of CAPWAP-BASE-MIB X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441337278==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0441337278== Content-type: multipart/alternative; boundary="Boundary_(ID_LNRZET6Geo/9hjo31JULyQ)" This is a multi-part message in MIME format. --Boundary_(ID_LNRZET6Geo/9hjo31JULyQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, here gives summary of changes in the new version of CAPWAP-BASE-MIB: ---------------------------------------------------------------------------- ------------------- For 5. Overview section Update the design objectives of the MIB drafts, to make it more clear. For example, update "- To work well under centralized architectures, and provide a way to centrally manage and control wireless network by SNMP" with "- To implement an architecture that uses SNMP for the management and control of wireless networks, answering the operators requirements for centralized management, whatever the deployment or configuration of the network devices (centralized, distributed, or some mix)" For 6.1. Textual Conventions It is reduplicate with 9. Definitions, so it is removed. For 7.2. Relationship to the IF-MIB Add some words to explain: 'WTP Virtual Radio Interface' provides a way to configure radio's parameters and query radio's traffic statistics, and reuse the MIBs defined by a specific wireless binding technology. The interface SHOULD be modeled as an ifEntry and provide appropriate interface information. For 7.3. Relationship to the ENTITY-MIB Add some words to make the Relationship with ENTITY-MIB more clear. For example, add some words like "By combining the MIBs, operators could query AC and WTP's status and properties. For example, they could get WTP's current status through CAPWAP-BASE-MIB, and WTP's software revision information through ENTITY-MIB. For 9. Definitions section: 1) Use capwapBase as prefix for objects and TC. 2) For TCs, there are changed and use "TC" characters as suffix. 3) Add DISPLAY-HINT for TCs involved. 4) As per latest protocol draft, update the reference part, DESCRIPTION part, value scope and so on of each MIB objects, and make them consistent with latest protocol draft. Lots of small changes happened. 5) To improve readability of MIB object name, we replace "WTP" with "Wtp","AC"with "Ac"..... For example, we rename "capwapWTPState" as "capwapBaseWtpState" 6) We used to use capwapWTPACNameList to provide AC name list info. Now, we use capwapBaseAcNameListTable to replace it and it is able to support more AC name items. 7) Fix some syntax error, for example, capwapBaseStationVlanName should use SnmpAdminString type. 8) All notification objects use capwapBaseNtf as prefix. ---------------------------------------------------------------------------- ---------------------------------- Regards Richard --Boundary_(ID_LNRZET6Geo/9hjo31JULyQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, here gives summary of changes in the new version of CAPWAP-BASE-MIB:

-----------------------------------------------------------------------------------------------

 

For 5.  Overview section

Update the design objectives of the MIB drafts, to make it more clear.

For example, update "- To work well under centralized architectures, and

   provide a way to centrally manage and control wireless network by SNMP"

   with

   "- To implement an architecture that uses SNMP for the management and

   control of wireless networks, answering the operators requirements

   for centralized management, whatever the deployment or configuration

   of the network devices (centralized, distributed, or some mix)"

  

For 6.1.  Textual Conventions

It is reduplicate with 9.  Definitions, so it is removed.

 

For 7.2.  Relationship to the IF-MIB

Add some words to explain:  'WTP Virtual Radio Interface' provides

   a way to configure radio's parameters and query radio's traffic

   statistics, and reuse the MIBs defined by a specific wireless binding

   technology.  The interface SHOULD be modeled as an ifEntry and

 provide appropriate interface information.

 

For 7.3.  Relationship to the ENTITY-MIB

Add some words to make the Relationship with ENTITY-MIB more clear.

For example, add some words like "By combining the MIBs, operators

could query AC and WTP's status and properties. 

For example, they could get WTP's current status through

CAPWAP-BASE-MIB, and WTP's software revision information through ENTITY-MIB.

 

 

For 9.  Definitions section:

1) Use capwapBase as prefix for objects and TC.

2) For TCs, there are changed and use "TC" characters as suffix.

3) Add  DISPLAY-HINT for TCs involved.

4) As per latest protocol draft, update the reference part, DESCRIPTION part, value scope

   and so on of each MIB objects, and make them consistent with latest protocol draft.

   Lots of small changes happened.

5) To improve readability of MIB object name, we replace "WTP" with "Wtp","AC"with "Ac".....

   For example, we rename  "capwapWTPState"   as "capwapBaseWtpState"

6) We used to use capwapWTPACNameList to provide AC name list info.

   Now, we use capwapBaseAcNameListTable to replace it and it is able to

   support more AC name items.

7) Fix some syntax error, for example, capwapBaseStationVlanName should

   use SnmpAdminString type.

8) All notification objects use capwapBaseNtf as prefix.

--------------------------------------------------------------------------------------------------------------

 

Regards

Richard

 

--Boundary_(ID_LNRZET6Geo/9hjo31JULyQ)-- --===============0441337278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0441337278==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Oct 12 19:13:14 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD413A6B5B for ; Sun, 12 Oct 2008 19:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=3.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFy9OvNDOPtW for ; Sun, 12 Oct 2008 19:13:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3EFBC3A6B53 for ; Sun, 12 Oct 2008 19:13:09 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 52C291C40F41 for ; Sun, 12 Oct 2008 19:13:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 65918D04067 for ; Sun, 12 Oct 2008 19:12:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 59F4034ACA8D for ; Sun, 12 Oct 2008 19:12:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6960F34ACA85 for ; Sun, 12 Oct 2008 19:12:41 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Sender first seen 2 mons 18 days 14:12:29 ago / dynamic or unknown reverse DNS) Received: from huawei-3com.com (unknown [221.12.31.56]) by mx1.tigertech.net (Postfix) with ESMTP for ; Sun, 12 Oct 2008 19:12:40 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8N00CPNNAG1V@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 13 Oct 2008 10:08:53 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8N00BS8M7PYD@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 13 Oct 2008 09:45:26 +0800 (CST) Received: from unknown (HELO s00338) ([10.154.68.129]) by mailsecurity.h3c.com with ESMTP; Mon, 13 Oct 2008 09:41:31 +0800 Date: Mon, 13 Oct 2008 09:44:31 +0800 From: young To: capwap@frascone.com Message-id: <000501c92cd5$3cf141f0$81449a0a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook, Build 10.0.6838 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Thread-index: Acks1TyglaDhU+umRFGs4sly9AMCHA== Subject: [Capwap] Thc change logs of CAPWAP-DOT11-MIB X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1153627202==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1153627202== Content-type: multipart/alternative; boundary="Boundary_(ID_bxSP5D8yuXfDi9ouPflS/Q)" This is a multi-part message in MIME format. --Boundary_(ID_bxSP5D8yuXfDi9ouPflS/Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT The summary of changes made in the new version of CAPWAP-DOT11-MIB ---------------------------------------------------------------------------- ------------------- In the entire drafts, we replaced "IEEE 802.11 MIB standard" with "the MIBs defined in IEEE 802.11 standard and its amendments." Because amendments of 802.11 standard also give MIB definitions. For 5. Overview Update the description about How configuration for a specific Wlan id is done. 6.1. Textual Conventions It is reduplicate with 9. Definitions, so it is removed. For 7.2. Relationship to the IF-MIB Add some words to describe the function of 'WLAN Service Interface' and 'WLAN BSS Interface' For 7.3. Relationship to CAPWAP-BASE-MIB Add some words to describe the function of CAPWAP-BASE-MIB and CAPWAP-DOT11-MIB For 7.4. Relationship to the MIB defined in IEEE 802.11 standard and its amendments Changes is to clarify that CAPWAP-DOT11-MIB could support MIB object not involved in the capwap binding protocol's TLVs. We added: In the 802.11 binding document [I-D.ietf-capwap-protocol-binding- ieee80211], it involves a part of MIB objects defined by IEEE 802.11 standard and its amendments. Although CAPWAP-DOT11-MIB uses the 802.11 binding document as a reference, it could reuse all the MIB objects defined by IEEE 802.11 standard and its amendments , and not limited by the scope of the 802.11 binding document. For 8. Example of CAPWAP-DOT11-MIB Usage Add some words to give the summary of interface's function. For 9. Definitions section: 1) Make changes and ensure capwapDot11 as common prefix for all objects and TC. 2) For TCs, there are changed and use "TC" characters as suffix. 3) Add DISPLAY-HINT for TCs involved. 4) To improve readability of MIB object name, we replace "WLAN" with "Wlan","BSS"with "Bss"..... For example, we rename "capwapDot11WLANBSSIfIndex" as "capwapDot11WlanBssIfIndex" 5) Update the DESCRIPTION of capwapDot11WlanServiceIfIndex. 6) Update the DESCRIPTION of capwapDot11WlanBssIfIndex. 7) Fix some syntax error, for example, capwapBaseStationVlanName should use SnmpAdminString type. 8) Add the persistent description for capwapDot11WlanConfigTable ---------------------------------------------------------------------------- ------------------- Regards Richard --Boundary_(ID_bxSP5D8yuXfDi9ouPflS/Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

The summary of changes made in the new version of CAPWAP-DOT11-MIB

-----------------------------------------------------------------------------------------------

In the entire drafts, we replaced  "IEEE 802.11 MIB standard" with "the MIBs defined

   in IEEE 802.11 standard and its amendments." Because amendments of 802.11 standard also

   give MIB definitions.

  

For 5.  Overview

Update the description about How configuration for a specific Wlan id is done.

 

6.1.  Textual Conventions

It is reduplicate with 9.  Definitions, so it is removed.

 

For 7.2.  Relationship to the IF-MIB

Add some words to describe the function of  'WLAN Service Interface' and 'WLAN BSS Interface'

 

For 7.3.  Relationship to CAPWAP-BASE-MIB

Add some words to describe the function of CAPWAP-BASE-MIB and CAPWAP-DOT11-MIB

 

For 7.4.  Relationship to the MIB defined in IEEE 802.11 standard and its

      amendments

Changes is to clarify that CAPWAP-DOT11-MIB could support MIB object not involved in the

capwap binding protocol’s TLVs.

We added:

   In the 802.11 binding document [I-D.ietf-capwap-protocol-binding-

   ieee80211], it involves a part of MIB objects defined by IEEE 802.11

   standard and its amendments.  Although CAPWAP-DOT11-MIB uses the

   802.11 binding document as a reference, it could reuse all the MIB

   objects defined by IEEE 802.11 standard and its amendments , and not

   limited by the scope of the 802.11 binding document.

 

For 8.  Example of CAPWAP-DOT11-MIB Usage

Add some words to give the summary of interface's function.

 

For 9.  Definitions section:

1) Make changes and ensure capwapDot11 as common prefix for all objects and TC.

2) For TCs, there are changed and use "TC" characters as suffix.

3) Add  DISPLAY-HINT for TCs involved.

4) To improve readability of MIB object name, we replace "WLAN" with "Wlan","BSS"with "Bss".....

   For example, we rename  "capwapDot11WLANBSSIfIndex"   as "capwapDot11WlanBssIfIndex"

5) Update the DESCRIPTION of  capwapDot11WlanServiceIfIndex.

6) Update the DESCRIPTION of  capwapDot11WlanBssIfIndex.

7) Fix some syntax error, for example, capwapBaseStationVlanName should

   use SnmpAdminString type.

8) Add the persistent description for capwapDot11WlanConfigTable

-----------------------------------------------------------------------------------------------

 

Regards

Richard

--Boundary_(ID_bxSP5D8yuXfDi9ouPflS/Q)-- --===============1153627202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1153627202==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Oct 12 19:45:39 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492C63A67DD for ; Sun, 12 Oct 2008 19:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=2.817, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rJgNuERrym1 for ; Sun, 12 Oct 2008 19:45:38 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 27FB83A67AD for ; Sun, 12 Oct 2008 19:45:38 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AB16B1C40F4A for ; Sun, 12 Oct 2008 19:46:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 04C46D04067 for ; Sun, 12 Oct 2008 19:46:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id D833134ACA8E for ; Sun, 12 Oct 2008 19:46:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0329334ACA85 for ; Sun, 12 Oct 2008 19:46:04 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Sender first seen 2 mons 18 days 14:45:53 ago / dynamic or unknown reverse DNS) Received: from huawei-3com.com (unknown [221.12.31.56]) by mx1.tigertech.net (Postfix) with ESMTP for ; Sun, 12 Oct 2008 19:46:02 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8N00KWZP2SHN@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 13 Oct 2008 10:47:17 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8N00B5JP2SYD@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 13 Oct 2008 10:47:16 +0800 (CST) Received: from unknown (HELO s00338) ([10.154.68.129]) by mailsecurity.h3c.com with ESMTP; Mon, 13 Oct 2008 10:43:23 +0800 Date: Mon, 13 Oct 2008 10:46:22 +0800 From: young To: capwap@frascone.com Message-id: <000001c92cdd$e1267bc0$81449a0a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook, Build 10.0.6838 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Thread-index: Acks3eDOJ/530MunQlODRCYjZenQvw== Cc: yozhang@gmail.com, chelliot@cisco.com Subject: [Capwap] The open issues we have in the MIB drafts X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1278738742==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1278738742== Content-type: multipart/alternative; boundary="Boundary_(ID_zxmMwBRFIxgfGihNs2ijvg)" This is a multi-part message in MIME format. --Boundary_(ID_zxmMwBRFIxgfGihNs2ijvg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Here are open issues we have till now: 1) The MAX-ACCESS property of MIB objects Which objects should use write access right? In the CAPWAP-DOT11-MIB, We defines some objects with write access right as the IEEE MIBs usually defines Some objects with write access right to support configuration operation. So we think the design of CAPWAP-DOT11-MIB as an 802.11 binding should keep Consistent with IEEE MIBs. We think current design of it is OK. So this question is mainly for CAPWAP-BASE-MIB. I think it is a common rule in the IETF MIBs To define most objects with read access right, and objects with write access right are Rarely defined. Considering of configuration operation is an important function of CAPWAP protocol, so We should define some objects with write access right? This idea is right? If it is correct, kindly suggest which object (TLV) should support write access right? 2) As per the section of "4.7. CAPWAP Protocol Timers" and "4.8. CAPWAP Protocol Variables" in the base protocol, which timer or Variables is necessary to operator and should be defined in the CAPWAP-BASE-MIB? Whether requires MIB to cover all of them? As SNMP agent is only required in the AC, how about we only cover variables or timer on the AC? Any other open issues? We plan to close all these open issue in the next version released. Regards Richard --Boundary_(ID_zxmMwBRFIxgfGihNs2ijvg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Here are open issues we have till now:

1)       The MAX-ACCESS property of MIB objects

Which objects should use write access right?  In the CAPWAP-DOT11-MIB,

We defines some objects with write access right as the IEEE MIBs usually defines

Some objects with write access right to support configuration operation.

So we think the design of CAPWAP-DOT11-MIB as an 802.11 binding should keep

Consistent with IEEE MIBs.  We think current design of it is OK.

 

So this question is mainly for CAPWAP-BASE-MIB. I think it is a common rule in the IETF MIBs

To define most objects with read access right, and objects with write access right are

Rarely defined.

Considering of configuration operation is an important function of CAPWAP protocol, so

We should define some objects with write access right? This idea is right?

If it is correct, kindly suggest which object (TLV) should support write access right?

 

2) As per the section of  "4.7.  CAPWAP Protocol Timers" and "4.8. 

CAPWAP Protocol Variables" in the base protocol, which timer or Variables is necessary to

operator and should be defined in the CAPWAP-BASE-MIB? Whether requires MIB to cover all of them?

As SNMP agent is only required in the AC, how about we only cover variables or timer on the AC?

 

Any other open issues?

We plan to close all these open issue in the next version released.

 

 

Regards

Richard

--Boundary_(ID_zxmMwBRFIxgfGihNs2ijvg)-- --===============1278738742== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1278738742==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 13 08:00:41 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479B23A6A00 for ; Mon, 13 Oct 2008 08:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWNuBV5IgA3U for ; Mon, 13 Oct 2008 08:00:40 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 477CB3A69AB for ; Mon, 13 Oct 2008 08:00:40 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6A4924303AC for ; Mon, 13 Oct 2008 08:01:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 65341440006 for ; Mon, 13 Oct 2008 08:01:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 586AF34ACFE7 for ; Mon, 13 Oct 2008 08:01:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 5793C34ACFE4 for ; Mon, 13 Oct 2008 08:01:01 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 13 Oct 2008 08:01:01 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA06.westchester.pa.mail.comcast.net with comcast id SEM51a0031GhbT856F0rVp; Mon, 13 Oct 2008 15:00:51 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id SF0w1a00R4HwxpC3TF0xLG; Mon, 13 Oct 2008 15:00:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=y7SVtUTkFrEA:10 a=ShBMIDrR8e8A:10 a=A3zM3OWv25TrCuBvXlQA:9 a=eY6GF27G1Diy9c2s0-8A:7 a=65kYeDmdxpYPsfajewtfAOwjXCMA:4 a=UrVzQrUuqIYA:10 a=PtetwI6Pm4AA:10 a=MSl-tDqOz04A:10 a=JfD0Fch1gWkA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'young'" , References: <000001c92cdd$e1267bc0$81449a0a@h3c.huawei3com.com> Date: Mon, 13 Oct 2008 11:00:56 -0400 Message-ID: <00d701c92d44$7f6c4d80$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acks3eDOJ/530MunQlODRCYjZenQvwAYZuLg In-Reply-To: <000001c92cdd$e1267bc0$81449a0a@h3c.huawei3com.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: chelliot@cisco.com, yozhang@gmail.com Subject: Re: [Capwap] The open issues we have in the MIB drafts X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi, I have not reviewed your latest MIBs (and do not plan to), but I have some general recommendations in response to your questions. I would find it much easier to respond to your messages inline if you used plain text format rather than HTML format. ________________________________ From: young [mailto:young@h3c.com] Sent: Sunday, October 12, 2008 10:46 PM To: capwap@frascone.com Cc: yozhang@gmail.com; chelliot@cisco.com Subject: [Capwap] The open issues we have in the MIB drafts Hi, Here are open issues we have till now: 1) The MAX-ACCESS property of MIB objects Which objects should use write access right? In the CAPWAP-DOT11-MIB, We defines some objects with write access right as the IEEE MIBs usually defines Some objects with write access right to support configuration operation. So we think the design of CAPWAP-DOT11-MIB as an 802.11 binding should keep Consistent with IEEE MIBs. We think current design of it is OK. dbh> Some vendors support write-access in their agents. It therefore makes sense to define as read-write any object that could be effectively used to configure the CAPWAP environment. Put another way, if it makes sense for an object to be writable in an environment where SNMP SETs are supported, then make the object read-write so the operators in that environment can write to the objects. If you make the objects read-only, then, even if the agent supports SNMP SETs, the operators will not be able to write to them, which would be a bad thing for those operators. You can define multiple groups for conformance - such as 1) one group for read-only objects, which can be used to monitor a system, 2) a second conformance group for read-write objects, which can be used to actively configure a system, and 3) a third group providing read-only support for the read-write objects; these could be used to monitor the configuration, but not modify the configuration. There are many recent standard MIB modules that allow read-only mode for read-write objects; check some recent RFCs that contain MIB modules. So this question is mainly for CAPWAP-BASE-MIB. I think it is a common rule in the IETF MIBs To define most objects with read access right, and objects with write access right are Rarely defined. Considering of configuration operation is an important function of CAPWAP protocol, so We should define some objects with write access right? This idea is right? If it is correct, kindly suggest which object (TLV) should support write access right? 2) As per the section of "4.7. CAPWAP Protocol Timers" and "4.8. CAPWAP Protocol Variables" in the base protocol, which timer or Variables is necessary to operator and should be defined in the CAPWAP-BASE-MIB? Whether requires MIB to cover all of them? As SNMP agent is only required in the AC, how about we only cover variables or timer on the AC? dbh> The AC is only one end of the relationship. It is often the case when trying to determine fauilts or performance, that comparing the counters from the two sides of the relationship reveals useful information. It can be useful to passively monitor how each side is configured to locate mismatched configurations. When used for active configuration, it might be necessary to configure both sides of a relationship before the configuration can work. So you might want to consider whether it will be important for both sides to collect information about the relationship, or to configure both sides of the relationship to make the relation viable. If it is unlikely that both sides will support an SNMP agent, then you might want the one side that is likely to have an SNMP agent to monitor information about the itself **and** other side of the relationship. It might extract useful information from fields in the CAPWAP messages, and store the information in a MIB so a manager application can see what seems to be happening, at least from the standpoint of the single agent. (You can compare this to me working with you and an engineer that only speaks Chinese; since I don't speak Chinese, and the Chinese engineer does not speak English, it would be helpful if you, who understands both languages, could write the weekly status report telling me what he is doing ;-) Any other open issues? We plan to close all these open issue in the next version released. Regards Richard _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 13 18:38:27 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1CE3A6ADD for ; Mon, 13 Oct 2008 18:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.177 X-Spam-Level: **** X-Spam-Status: No, score=4.177 tagged_above=-999 required=5 tests=[AWL=-2.611, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3eVh3lsmCGF for ; Mon, 13 Oct 2008 18:38:26 -0700 (PDT) Received: from amy.tigertech.net (amy.tigertech.net [216.93.176.60]) by core3.amsl.com (Postfix) with ESMTP id 404473A6A4A for ; Mon, 13 Oct 2008 18:38:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by amy.tigertech.net (Postfix) with ESMTP id B12856780F1 for ; Mon, 13 Oct 2008 18:38:13 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A770D430577 for ; Mon, 13 Oct 2008 18:37:43 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id D8A45D04067 for ; Mon, 13 Oct 2008 18:37:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id BF37A1CD483 for ; Mon, 13 Oct 2008 18:37:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 9E4CC1CD482 for ; Mon, 13 Oct 2008 18:37:37 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Sender first seen 2 mons 19 days 13:37:27 ago / dynamic or unknown reverse DNS) Received: from huawei-3com.com (unknown [221.12.31.13]) by mx3.tigertech.net (Postfix) with ESMTP for ; Mon, 13 Oct 2008 18:37:36 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8P001QKGNO31@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 14 Oct 2008 09:40:36 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8P000ENGNNZR@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 14 Oct 2008 09:40:35 +0800 (CST) Received: from unknown (HELO s00338) ([10.154.68.129]) by mailsecurity.h3c.com with ESMTP; Tue, 14 Oct 2008 09:34:55 +0800 Date: Tue, 14 Oct 2008 09:37:57 +0800 From: young In-reply-to: <00d701c92d44$7f6c4d80$0600a8c0@china.huawei.com> To: 'David Harrington' Message-id: <000001c92d9d$7ce46cb0$81449a0a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook, Build 10.0.6838 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Thread-index: Acks3eDOJ/530MunQlODRCYjZenQvwAYZuLgABd6bSA= Cc: chelliot@cisco.com, capwap@frascone.com, yozhang@gmail.com Subject: [Capwap] =?gb2312?b?tPC4tDogIFRoZSBvcGVuIGlzc3VlcyB3ZSBoYXZlIGlu?= =?gb2312?b?IHRoZSBNSUIgZHJhZnRz?= X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com RGVhciBEYXZpZDoKCkkgZ290IHlvdXIgcG9pbnQsIGFuZCB0aGVzZSBnZW5lcmFsIHN1Z2dlc3Rp b25zIGFyZSB2ZXJ5IGhlbHBmdWwuIFNvbWV0aW1lLAp3ZSB3b3JyeSBhYm91dCB3aGV0aGVyIHdl IGRvIGRlc2lnbiBpbiBhIGNvcnJlY3QgZGlyZWN0aW9uLiBXaXRoIGl0LCB3ZSB3aWxsCmZpZ3Vy ZSBvdXQgdGhlIGFjY2VzcyByaWdodCBvZiBvYmplY3RzIGFuZCBjb25zaWRlciBIb3cgdG8gZGVm aW5lIG9iamVjdHMKZm9yIHRpbWVyIGFuZCB2YXJpYWJsZS4KClRoYW5rcyBhIGxvdApSZWdhcmRz ClJpY2hhcmQKCi0tLS0t08q8/tStvP4tLS0tLQq3orz+yMs6IERhdmlkIEhhcnJpbmd0b24gW21h aWx0bzppZXRmZGJoQGNvbWNhc3QubmV0XSAKt6LLzcqxvOQ6IDIwMDjE6jEw1MIxM8jVIDIzOjAx CsrVvP7IyzogJ3lvdW5nJzsgY2Fwd2FwQGZyYXNjb25lLmNvbQqzrcvNOiB5b3poYW5nQGdtYWls LmNvbTsgY2hlbGxpb3RAY2lzY28uY29tCtb3zOI6IFJFOiBbQ2Fwd2FwXSBUaGUgb3BlbiBpc3N1 ZXMgd2UgaGF2ZSBpbiB0aGUgTUlCIGRyYWZ0cwoKSGksCiAKSSBoYXZlIG5vdCByZXZpZXdlZCB5 b3VyIGxhdGVzdCBNSUJzIChhbmQgZG8gbm90IHBsYW4gdG8pLCBidXQgSSBoYXZlCnNvbWUgZ2Vu ZXJhbCByZWNvbW1lbmRhdGlvbnMgaW4gcmVzcG9uc2UgdG8geW91ciBxdWVzdGlvbnMuCgpJIHdv dWxkIGZpbmQgaXQgbXVjaCBlYXNpZXIgdG8gcmVzcG9uZCB0byB5b3VyIG1lc3NhZ2VzIGlubGlu ZSBpZiB5b3UKdXNlZCBwbGFpbiB0ZXh0IGZvcm1hdCByYXRoZXIgdGhhbiBIVE1MIGZvcm1hdC4K CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKCUZyb206IHlvdW5nIFttYWlsdG86 eW91bmdAaDNjLmNvbV0gCglTZW50OiBTdW5kYXksIE9jdG9iZXIgMTIsIDIwMDggMTA6NDYgUE0K CVRvOiBjYXB3YXBAZnJhc2NvbmUuY29tCglDYzogeW96aGFuZ0BnbWFpbC5jb207IGNoZWxsaW90 QGNpc2NvLmNvbQoJU3ViamVjdDogW0NhcHdhcF0gVGhlIG9wZW4gaXNzdWVzIHdlIGhhdmUgaW4g dGhlIE1JQiBkcmFmdHMKCQoJCgoJSGksIAoKCUhlcmUgYXJlIG9wZW4gaXNzdWVzIHdlIGhhdmUg dGlsbCBub3c6CgoJMSkgICAgICAgVGhlIE1BWC1BQ0NFU1MgcHJvcGVydHkgb2YgTUlCIG9iamVj dHMKCglXaGljaCBvYmplY3RzIHNob3VsZCB1c2Ugd3JpdGUgYWNjZXNzIHJpZ2h0PyAgIAoKCgkg SW4gdGhlIENBUFdBUC1ET1QxMS1NSUIsCgoJV2UgZGVmaW5lcyBzb21lIG9iamVjdHMgd2l0aCB3 cml0ZSBhY2Nlc3MgcmlnaHQgYXMgdGhlIElFRUUKTUlCcyB1c3VhbGx5IGRlZmluZXMKCglTb21l IG9iamVjdHMgd2l0aCB3cml0ZSBhY2Nlc3MgcmlnaHQgdG8gc3VwcG9ydCBjb25maWd1cmF0aW9u Cm9wZXJhdGlvbi4KCglTbyB3ZSB0aGluayB0aGUgZGVzaWduIG9mIENBUFdBUC1ET1QxMS1NSUIg YXMgYW4gODAyLjExCmJpbmRpbmcgc2hvdWxkIGtlZXAKCglDb25zaXN0ZW50IHdpdGggSUVFRSBN SUJzLiAgV2UgdGhpbmsgY3VycmVudCBkZXNpZ24gb2YgaXQgaXMKT0suCgoKZGJoPiBTb21lIHZl bmRvcnMgc3VwcG9ydCB3cml0ZS1hY2Nlc3MgaW4gdGhlaXIgYWdlbnRzLiBJdCB0aGVyZWZvcmUK bWFrZXMgc2Vuc2UgdG8gZGVmaW5lIGFzIHJlYWQtd3JpdGUgYW55IG9iamVjdCB0aGF0IGNvdWxk IGJlCmVmZmVjdGl2ZWx5IHVzZWQgdG8gY29uZmlndXJlIHRoZSBDQVBXQVAgZW52aXJvbm1lbnQu IFB1dCBhbm90aGVyIHdheSwKaWYgaXQgbWFrZXMgc2Vuc2UgZm9yIGFuIG9iamVjdCB0byBiZSB3 cml0YWJsZSBpbiBhbiBlbnZpcm9ubWVudCB3aGVyZQpTTk1QIFNFVHMgYXJlIHN1cHBvcnRlZCwg dGhlbiBtYWtlIHRoZSBvYmplY3QgcmVhZC13cml0ZSBzbyB0aGUKb3BlcmF0b3JzIGluIHRoYXQg ZW52aXJvbm1lbnQgY2FuIHdyaXRlIHRvIHRoZSBvYmplY3RzLiBJZiB5b3UgbWFrZQp0aGUgb2Jq ZWN0cyByZWFkLW9ubHksIHRoZW4sIGV2ZW4gaWYgdGhlIGFnZW50IHN1cHBvcnRzIFNOTVAgU0VU cywgdGhlCm9wZXJhdG9ycyB3aWxsIG5vdCBiZSBhYmxlIHRvIHdyaXRlIHRvIHRoZW0sIHdoaWNo IHdvdWxkIGJlIGEgYmFkCnRoaW5nIGZvciB0aG9zZSBvcGVyYXRvcnMuCgpZb3UgY2FuIGRlZmlu ZSBtdWx0aXBsZSBncm91cHMgZm9yIGNvbmZvcm1hbmNlIC0gc3VjaCBhcyAKMSkgb25lIGdyb3Vw IGZvciByZWFkLW9ubHkgb2JqZWN0cywgd2hpY2ggY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhCnN5 c3RlbSwgMikgYSBzZWNvbmQgY29uZm9ybWFuY2UgZ3JvdXAgZm9yIHJlYWQtd3JpdGUgb2JqZWN0 cywgd2hpY2gKY2FuIGJlIHVzZWQgdG8gYWN0aXZlbHkgY29uZmlndXJlIGEgc3lzdGVtLCBhbmQg CjMpIGEgdGhpcmQgZ3JvdXAgcHJvdmlkaW5nIHJlYWQtb25seSBzdXBwb3J0IGZvciB0aGUgcmVh ZC13cml0ZQpvYmplY3RzOyB0aGVzZSBjb3VsZCBiZSB1c2VkIHRvIG1vbml0b3IgdGhlIGNvbmZp Z3VyYXRpb24sIGJ1dCBub3QKbW9kaWZ5IHRoZSBjb25maWd1cmF0aW9uLiAKVGhlcmUgYXJlIG1h bnkgcmVjZW50IHN0YW5kYXJkIE1JQiBtb2R1bGVzIHRoYXQgYWxsb3cgcmVhZC1vbmx5IG1vZGUK Zm9yIHJlYWQtd3JpdGUgb2JqZWN0czsgY2hlY2sgc29tZSByZWNlbnQgUkZDcyB0aGF0IGNvbnRh aW4gTUlCCm1vZHVsZXMuCSAKCglTbyB0aGlzIHF1ZXN0aW9uIGlzIG1haW5seSBmb3IgQ0FQV0FQ LUJBU0UtTUlCLiBJIHRoaW5rIGl0IGlzCmEgY29tbW9uIHJ1bGUgaW4gdGhlIElFVEYgTUlCcyAK CglUbyBkZWZpbmUgbW9zdCBvYmplY3RzIHdpdGggcmVhZCBhY2Nlc3MgcmlnaHQsIGFuZCBvYmpl Y3RzCndpdGggd3JpdGUgYWNjZXNzIHJpZ2h0IGFyZQoKCVJhcmVseSBkZWZpbmVkLiAKCglDb25z aWRlcmluZyBvZiBjb25maWd1cmF0aW9uIG9wZXJhdGlvbiBpcyBhbiBpbXBvcnRhbnQKZnVuY3Rp b24gb2YgQ0FQV0FQIHByb3RvY29sLCBzbwoKCVdlIHNob3VsZCBkZWZpbmUgc29tZSBvYmplY3Rz IHdpdGggd3JpdGUgYWNjZXNzIHJpZ2h0PyBUaGlzCmlkZWEgaXMgcmlnaHQ/CgoJSWYgaXQgaXMg Y29ycmVjdCwga2luZGx5IHN1Z2dlc3Qgd2hpY2ggb2JqZWN0IChUTFYpIHNob3VsZApzdXBwb3J0 IHdyaXRlIGFjY2VzcyByaWdodD8KCgoJMikgQXMgcGVyIHRoZSBzZWN0aW9uIG9mICAiNC43LiAg Q0FQV0FQIFByb3RvY29sIFRpbWVycyIgYW5kCiI0LjguICAKCglDQVBXQVAgUHJvdG9jb2wgVmFy aWFibGVzIiBpbiB0aGUgYmFzZSBwcm90b2NvbCwgd2hpY2ggdGltZXIKb3IgVmFyaWFibGVzIGlz IG5lY2Vzc2FyeSB0byAKCglvcGVyYXRvciBhbmQgc2hvdWxkIGJlIGRlZmluZWQgaW4gdGhlIENB UFdBUC1CQVNFLU1JQj8gV2hldGhlcgpyZXF1aXJlcyBNSUIgdG8gY292ZXIgYWxsIG9mIHRoZW0/ IAoKCUFzIFNOTVAgYWdlbnQgaXMgb25seSByZXF1aXJlZCBpbiB0aGUgQUMsIGhvdyBhYm91dCB3 ZSBvbmx5CmNvdmVyIHZhcmlhYmxlcyBvciB0aW1lciBvbiB0aGUgQUM/CgpkYmg+IFRoZSBBQyBp cyBvbmx5IG9uZSBlbmQgb2YgdGhlIHJlbGF0aW9uc2hpcC4gSXQgaXMgb2Z0ZW4gdGhlIGNhc2UK d2hlbiB0cnlpbmcgdG8gZGV0ZXJtaW5lIGZhdWlsdHMgb3IgcGVyZm9ybWFuY2UsIHRoYXQgY29t cGFyaW5nIHRoZQpjb3VudGVycyBmcm9tIHRoZSB0d28gc2lkZXMgb2YgdGhlIHJlbGF0aW9uc2hp cCByZXZlYWxzIHVzZWZ1bAppbmZvcm1hdGlvbi4gSXQgY2FuIGJlIHVzZWZ1bCB0byBwYXNzaXZl bHkgbW9uaXRvciBob3cgZWFjaCBzaWRlIGlzCmNvbmZpZ3VyZWQgdG8gbG9jYXRlIG1pc21hdGNo ZWQgY29uZmlndXJhdGlvbnMuIFdoZW4gdXNlZCBmb3IgYWN0aXZlCmNvbmZpZ3VyYXRpb24sIGl0 IG1pZ2h0IGJlIG5lY2Vzc2FyeSB0byBjb25maWd1cmUgYm90aCBzaWRlcyBvZiBhCnJlbGF0aW9u c2hpcCBiZWZvcmUgdGhlIGNvbmZpZ3VyYXRpb24gY2FuIHdvcmsuIFNvIHlvdSBtaWdodCB3YW50 IHRvCmNvbnNpZGVyIHdoZXRoZXIgaXQgd2lsbCBiZSBpbXBvcnRhbnQgZm9yIGJvdGggc2lkZXMg dG8gY29sbGVjdAppbmZvcm1hdGlvbiBhYm91dCB0aGUgcmVsYXRpb25zaGlwLCBvciB0byBjb25m aWd1cmUgYm90aCBzaWRlcyBvZiB0aGUKcmVsYXRpb25zaGlwIHRvIG1ha2UgdGhlIHJlbGF0aW9u IHZpYWJsZS4KCklmIGl0IGlzIHVubGlrZWx5IHRoYXQgYm90aCBzaWRlcyB3aWxsIHN1cHBvcnQg YW4gU05NUCBhZ2VudCwgdGhlbiB5b3UKbWlnaHQgd2FudCB0aGUgb25lIHNpZGUgdGhhdCBpcyBs aWtlbHkgdG8gaGF2ZSBhbiBTTk1QIGFnZW50IHRvCm1vbml0b3IgaW5mb3JtYXRpb24gYWJvdXQg dGhlIGl0c2VsZiAqKmFuZCoqIG90aGVyIHNpZGUgb2YgdGhlCnJlbGF0aW9uc2hpcC4gSXQgbWln aHQgZXh0cmFjdCB1c2VmdWwgaW5mb3JtYXRpb24gZnJvbSBmaWVsZHMgaW4gdGhlCkNBUFdBUCBt ZXNzYWdlcywgYW5kIHN0b3JlIHRoZSBpbmZvcm1hdGlvbiBpbiBhIE1JQiBzbyBhIG1hbmFnZXIK YXBwbGljYXRpb24gY2FuIHNlZSB3aGF0IHNlZW1zIHRvIGJlIGhhcHBlbmluZywgYXQgbGVhc3Qg ZnJvbSB0aGUKc3RhbmRwb2ludCBvZiB0aGUgc2luZ2xlIGFnZW50LiAKCihZb3UgY2FuIGNvbXBh cmUgdGhpcyB0byBtZSB3b3JraW5nIHdpdGggeW91IGFuZCBhbiBlbmdpbmVlciB0aGF0IG9ubHkK c3BlYWtzIENoaW5lc2U7IHNpbmNlIEkgZG9uJ3Qgc3BlYWsgQ2hpbmVzZSwgYW5kIHRoZSBDaGlu ZXNlIGVuZ2luZWVyCmRvZXMgbm90IHNwZWFrIEVuZ2xpc2gsIGl0IHdvdWxkIGJlIGhlbHBmdWwg aWYgeW91LCB3aG8gdW5kZXJzdGFuZHMKYm90aCBsYW5ndWFnZXMsIGNvdWxkIHdyaXRlIHRoZSB3 ZWVrbHkgc3RhdHVzIHJlcG9ydCB0ZWxsaW5nIG1lIHdoYXQKaGUgaXMgZG9pbmcgOy0pCgoJQW55 IG90aGVyIG9wZW4gaXNzdWVzPwoKCVdlIHBsYW4gdG8gY2xvc2UgYWxsIHRoZXNlIG9wZW4gaXNz dWUgaW4gdGhlIG5leHQgdmVyc2lvbgpyZWxlYXNlZC4KCgkgCgoJIAoKCVJlZ2FyZHMKCglSaWNo YXJkCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KVG8gdW5zdWJzY3JpYmUgb3IgbW9kaWZ5IHlvdXIgc3Vic2NyaXB0aW9u IG9wdGlvbnMsIHBsZWFzZSB2aXNpdDoKaHR0cDovL2xpc3RzLmZyYXNjb25lLmNvbS9tYWlsbWFu L2xpc3RpbmZvL2NhcHdhcAoKQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vcGlw ZXJtYWlsL2NhcHdhcA== From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 14 15:30:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4E028C1FE for ; Tue, 14 Oct 2008 15:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94qbTTH6lTeT for ; Tue, 14 Oct 2008 15:30:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A157928C1FF for ; Tue, 14 Oct 2008 15:30:16 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 73E4F1C40F7D for ; Tue, 14 Oct 2008 15:31:05 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id ED18FD04067 for ; Tue, 14 Oct 2008 15:30:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DD6F534ADF4D for ; Tue, 14 Oct 2008 15:30:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A9ECA34ADE61 for ; Tue, 14 Oct 2008 15:30:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 14 Oct 2008 15:30:59 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id A2D0E28C1E6; Tue, 14 Oct 2008 15:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081014223001.A2D0E28C1E6@core3.amsl.com> Date: Tue, 14 Oct 2008 15:30:01 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D Action:draft-ietf-capwap-dhc-ac-option-02.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Access Controller DHCP Option Author(s) : P. Calhoun Filename : draft-ietf-capwap-dhc-ac-option-02.txt Pages : 12 Date : 2008-10-14 The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers it is to connect to. This document describes the DHCP options to be used by the CAPWAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-dhc-ac-option-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-dhc-ac-option-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-14152949.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 14 15:34:39 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8679D28C1F4 for ; Tue, 14 Oct 2008 15:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG78Nthy1azP for ; Tue, 14 Oct 2008 15:34:38 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A0F1828C1FE for ; Tue, 14 Oct 2008 15:34:38 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7E8801C40F5F for ; Tue, 14 Oct 2008 15:35:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id EB88AD04067 for ; Tue, 14 Oct 2008 15:35:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id CC7C634ADF4B for ; Tue, 14 Oct 2008 15:35:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6EF0934ADF4C for ; Tue, 14 Oct 2008 15:35:29 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 14 Oct 2008 15:35:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,410,1220227200"; d="scan'208";a="175172337" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2008 22:35:29 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m9EMZTOE016155 for ; Tue, 14 Oct 2008 15:35:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9EMZRFr010801 for ; Tue, 14 Oct 2008 22:35:29 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 15:35:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 15:35:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206A02CE7@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 227: Require proper DHCP client and server behavior Thread-Index: AckuTSUKoe3i0s49S4ylxKiH+u2/CA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 14 Oct 2008 22:35:23.0219 (UTC) FILETIME=[256F7230:01C92E4D] Authentication-Results: sj-dkim-4; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Capwap] Issue 227: Require proper DHCP client and server behavior X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com All, During the IESG review, there were some comments associated with whether some of the text in the draft should be changed from a SHOULD to a MUST. After review of the draft, the following comment was made: > All - I have a couple of concerns about simply changing the SHOULDs to MUSTs > in the paragraphs describing the DHCP (I'll use DHCP for DHCPv[46] throughout) > client and server behaviors. > > The first concern is about the timing of the DHCP client in the WTP device, > especially if the WTP function is instantiated in a device > after the DHCP client has completed its initial message exchange. > That is, the DHCP client may not know that the WTP will be instantiated at > some point, and may not know to ask for the CAPWAP AC option. > > It is possible for the WTP function, if it finds it does not have access to > the CAPWAP AC option info, to use a separate message (DHCPINFORM or > Information-Request) to obtain the information. I suggest the following text > for DHCPv4 and (with appropriate changes) > DHCPv6: > > A DHCPv4 client, acting on behalf of a CAPWAP WTP, MUST request the CAPWAP > AC DHCPv4 Option > in a Parameter Request List Option, as described in RFC 2131 and RFC 2132. > > I think this text allows for the case when the DHCP client is unaware of the > WTP, and the WTP function invokes DHCPINFORM/Information- Request later. > > The second concern is about the description of when the DHCP server should > respond with the CAPWAP AC option. The current text doesn't allow for DHCP > server policy to control the inclusion of the option in the response to the > client. This policy may work both ways - the server may have a policy to > return the option even if the client hasn't requested it, because the server > can determine that the device is a WTP and will need the option, or the server > may have a policy not to return the option to certain clients even if the > client lists the option in the PRL/ORO. Text to allow for server policy might > be: > > A DHCPv4 server returns the CAPWAP AC Option to the client if the server > policy is configured > appropriately and the server is configured with a list of CAPWAP AC > addresses. I have made the requested changes, and the resulting text looks like: 2. CAPWAP AC DHCPv4 Option [...] A DHCPv4 client, acting on behalf of a CAPWAP WTP, MUST request the CAPWAP AC DHCPv4 Option in a Parameter Request List Option, as described in [RFC2131] and [RFC2132]. A DHCPv4 server returns the CAPWAP AC Option to the client if the server policy is configured appropriately and the server is configured with a list of CAPWAP AC addresses. 3. CAPWAP AC DHCPv6 Option [...] A DHCPv6 client, acting on behalf of a CAPWAP WTP, MUST request the CAPWAP AC DHCPv6 Option in a Parameter Request List Option, as described in [RFC3315]. A DHCPv6 server returns the CAPWAP AC Option to the client if the server policy is configured appropriately and the server is configured with a list of CAPWAP AC addresses. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 15 02:39:03 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719833A68B5 for ; Wed, 15 Oct 2008 02:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.87 X-Spam-Level: X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ksu87-lD-yb for ; Wed, 15 Oct 2008 02:39:02 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4E76F3A6931 for ; Wed, 15 Oct 2008 02:39:02 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1BCF343024A for ; Wed, 15 Oct 2008 02:40:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id ABB33440006 for ; Wed, 15 Oct 2008 02:39:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9EC7434AE3FB for ; Wed, 15 Oct 2008 02:39:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id DCA5234AE3F5 for ; Wed, 15 Oct 2008 02:39:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.62 whitelisted by list.dnswl.org 5.2) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 15 Oct 2008 02:39:52 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3CC67201FF; Wed, 15 Oct 2008 11:36:36 +0200 (CEST) X-AuditID: c1b4fb3e-a8684bb000007a96-8d-48f5b9a4d95b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 20A142225E; Wed, 15 Oct 2008 11:36:36 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 11:36:35 +0200 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 11:36:35 +0200 Message-ID: <48F5B9A3.1040502@ericsson.com> Date: Wed, 15 Oct 2008 11:36:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: capwap X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 15 Oct 2008 09:36:35.0255 (UTC) FILETIME=[83CFBC70:01C92EA9] X-Brightmail-Tracker: AAAAAA== Cc: tsvwg Subject: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi CAPWAP and TSVWG, This email is to start off a public discussion about what support for ECN that the CAPWAP protocol (http://tools.ietf.org/wg/capwap/draft-ietf-capwap-protocol-specification/) should have. This is to resolve my Discuss. For the TSVWG people, the CAPWAP protocol is a control protocol of wireless termination point (WTP), like 802.11 access points, from access control (AC). The capwap protocol also have an option to tunnel the wireless frames within the protocol. It is in this context that the usage of ECN is relevant. The wireless frames will commonly carry IP packets. Thus CAPWAP is among other things an IP in IP tunneling protocol, although with some extra layers in between the two IP. So the issue here is what support of ECN should exist in the tunneling mechanism. ECN (RFC 3168) specifies two options for how tunnels can handle ECN, the full functionality option where ECN is enabled on the outer IP header and the relevant state at the tunnel egress is copied to the inner packet. The limited option where the outer header is set as ECN incapable. With the limited option what could have been a mark if the inner packet is ECN enabled becomes a packet drop thus lowering the utility of the ECN function. The ECN specification have the following wording in section 9.1.1: All IP tunnels MUST implement the limited-functionality option, and SHOULD support the full-functionality option. >From my perspective I haven't seen any strong arguments why the protocol should only support the limited option. CAPWAP is intended to be used in access networks, that is a common location for congestion. Thus, the usage of ECN within this network can have real positive impact on the user applications. Also ECN has been a part of IP at standard track level since 2001 and continue to ignore this part of the IP for easy of implementation does not help improve the Internet. Therefore I really think CAPWAP SHOULD support full ECN. And with SHOULD I see it as there need to be real good reasons why this shouldn't be supported. The complications with introducing the full ECN support option at this stage is two. One, there already exist implementations that uses this protocol as so far specified (although some updates will be required to cover other modifications found during the IETF last call and IESG review). These are likely to operate with limited option as the specification hasn't discussed ECN at all. Secondly, there is the interoperability issue between the tunnel ingress and egress if one is going to have this being configurable. The tunnel ingress needs to know the support for ECN handling at the tunnel egress. Thus the capwap protocol would need an extension to carry that information in each direction. The problem with a full functionality ingress and limited functionality egress is that packets that should have been marked or dropped comes through without indication of congestion. Thus, the best option to take the current implementations into account and allow for deployment of full functionality where possible would be to add additional signaling to the CAPWAP protocol to indicate the capability of the egress to the ingress and configure the ingress correctly. If this can be introduced in a manner that doesn't make current implementations barf, then a nice incremental deployment story exist. A second way to introduce full ECN functionality is simply to mandate it and live through a period with functionality failure towards any non specification compliant device. So the questions are: - Does they exist arguments that motivates support of limited ECN functionality only? - Further arguments why CAPWAP really should support ECN? - Am I over interpreting the requirement for supporting ECN? Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 16 09:44:09 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BD43A6B83 for ; Thu, 16 Oct 2008 09:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.431 X-Spam-Level: X-Spam-Status: No, score=-4.431 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C5+qfVKJjFV for ; Thu, 16 Oct 2008 09:44:08 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 61D0F3A6B62 for ; Thu, 16 Oct 2008 09:44:08 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9C46543067D for ; Thu, 16 Oct 2008 09:45:10 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D4020D04067 for ; Thu, 16 Oct 2008 09:44:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id BA694361002B for ; Thu, 16 Oct 2008 09:44:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 65E7C3610049 for ; Thu, 16 Oct 2008 09:44:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 16 Oct 2008 09:44:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,424,1220227200"; d="scan'208";a="91967111" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2008 16:44:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9GGihIN007533; Thu, 16 Oct 2008 09:44:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9GGihwI007126; Thu, 16 Oct 2008 16:44:43 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 09:44:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 09:44:40 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206A683C5@xmb-sjc-235.amer.cisco.com> In-Reply-To: <48F5B9A3.1040502@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] ECN support when tunneling user packets in CAPWAP Thread-Index: AckuqgKKxqm1aDQDTIinCLerYoIq9gAar9Xw References: <48F5B9A3.1040502@ericsson.com> From: "Pat Calhoun (pacalhou)" To: "Magnus Westerlund" , "capwap" X-OriginalArrivalTime: 16 Oct 2008 16:44:43.0371 (UTC) FILETIME=[7D88EBB0:01C92FAE] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tsvwg Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi Magnus, I continue to be concerned about the request to make ECN Full option suppor= t mandatory. Just to recap, the current spec currently reads: 4.5.2. Quality of Service [...] The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. When packets received from stations are encapsulated by the WTP, the ECN bits are set to zero (0) in the outer header. The WTP does not modify the ECN bits in the original station's packet header. This mode of operation is detailed as the "limited functionality option" in [RFC3168]. I believe that the text above is consistent with the requirement listed in = RFC 3168: All IP tunnels MUST implement the limited-functionality option, and SHOULD support the full-functionality option. I believe that requiring all CAPWAP implementations now support full-functi= onality today will require some significant changes to existing hardware th= at is shipping today, which I believe would not be in the best interest of = the Internet community. I would prefer we keep the text as-is, and re-exami= ne this question at the next version of the CAPWAP protocol. PatC -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] = Sent: Wednesday, October 15, 2008 2:37 AM To: capwap Cc: tsvwg Subject: [Capwap] ECN support when tunneling user packets in CAPWAP Hi CAPWAP and TSVWG, This email is to start off a public discussion about what support for ECN t= hat the CAPWAP protocol (http://tools.ietf.org/wg/capwap/draft-ietf-capwap-protocol-specification/) should have. This is to resolve my Discuss. For the TSVWG people, the CAPWAP protocol is a control protocol of wireless= termination point (WTP), like 802.11 access points, from access control (A= C). The capwap protocol also have an option to tunnel the wireless frames w= ithin the protocol. It is in this context that the usage of ECN is relevant= . The wireless frames will commonly carry IP packets. Thus CAPWAP is among = other things an IP in IP tunneling protocol, although with some extra layer= s in between the two IP. So the issue here is what support of ECN should exist in the tunneling mech= anism. ECN (RFC 3168) specifies two options for how tunnels can handle ECN,= the full functionality option where ECN is enabled on the outer IP header = and the relevant state at the tunnel egress is copied to the inner packet. = The limited option where the outer header is set as ECN incapable. With the= limited option what could have been a mark if the inner packet is ECN enab= led becomes a packet drop thus lowering the utility of the ECN function. Th= e ECN specification have the following wording in section 9.1.1: All IP tunnels MUST implement the limited-functionality option, and SHOULD support the full-functionality option. >From my perspective I haven't seen any strong arguments why the = >protocol should only support the limited option. CAPWAP is intended to be used in ac= cess networks, that is a common location for congestion. Thus, the usage of= ECN within this network can have real positive impact on the user applicat= ions. Also ECN has been a part of IP at standard track level since 2001 and= continue to ignore this part of the IP for easy of implementation does not= help improve the Internet. Therefore I really think CAPWAP SHOULD support = full ECN. And with SHOULD I see it as there need to be real good reasons wh= y this shouldn't be supported. The complications with introducing the full ECN support option at this stag= e is two. One, there already exist implementations that uses this protocol = as so far specified (although some updates will be required to cover other = modifications found during the IETF last call and IESG review). These are l= ikely to operate with limited option as the specification hasn't discussed = ECN at all. Secondly, there is the interoperability issue between the tunnel ingress an= d egress if one is going to have this being configurable. The tunnel ingres= s needs to know the support for ECN handling at the tunnel egress. Thus the capwap protocol would need an extension to carry that information = in each direction. The problem with a full functionality ingress and limite= d functionality egress is that packets that should have been marked or drop= ped comes through without indication of congestion. Thus, the best option to take the current implementations into account and = allow for deployment of full functionality where possible would be to add a= dditional signaling to the CAPWAP protocol to indicate the capability of th= e egress to the ingress and configure the ingress correctly. If this can be= introduced in a manner that doesn't make current implementations barf, the= n a nice incremental deployment story exist. A second way to introduce full ECN functionality is simply to mandate it an= d live through a period with functionality failure towards any non specific= ation compliant device. So the questions are: - Does they exist arguments that motivates support of limited ECN functiona= lity only? - Further arguments why CAPWAP really should support ECN? - Am I over interpreting the requirement for supporting ECN? Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 17 02:07:40 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3334528C0EA for ; Fri, 17 Oct 2008 02:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[AWL=-1.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdWbgs6TZTye for ; Fri, 17 Oct 2008 02:07:39 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 200703A6A2D for ; Fri, 17 Oct 2008 02:07:39 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C8A2043023B for ; Fri, 17 Oct 2008 02:08:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 62E77440006 for ; Fri, 17 Oct 2008 02:08:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 481B134AEEA0 for ; Fri, 17 Oct 2008 02:08:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 811AD34AEE9F for ; Fri, 17 Oct 2008 02:08:33 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.62 whitelisted by list.dnswl.org 5.2) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 17 Oct 2008 02:08:33 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4E1AC21A96; Fri, 17 Oct 2008 11:08:31 +0200 (CEST) X-AuditID: c1b4fb3e-a6e81bb000007a96-32-48f8560e121f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 87A3821874; Fri, 17 Oct 2008 11:08:30 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 11:08:22 +0200 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 11:08:22 +0200 Message-ID: <48F85606.4020205@ericsson.com> Date: Fri, 17 Oct 2008 11:08:22 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <48F5B9A3.1040502@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206A683C5@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206A683C5@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 17 Oct 2008 09:08:22.0156 (UTC) FILETIME=[E778D4C0:01C93037] X-Brightmail-Tracker: AAAAAA== Cc: capwap , tsvwg Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun (pacalhou) skrev: > Hi Magnus, > = > I continue to be concerned about the request to make ECN Full option supp= ort mandatory. Just to recap, the current spec currently reads: Please be clear that I haven't said that it is mandated to use. Only saying that it should be mandated to support in the protocol. I have suggested one way of accomplishing this that mandates it usage, but I have arrived at the conclusion that this may not be the best way of doing it. Considering the draft version implementations a signalling function seems an attractive way forward from my perspective. > = > > 4.5.2. Quality of Service > [...] > The IP header also includes the Explicit Congestion Notification > (ECN) bits [RFC3168]. When packets received from stations are > encapsulated by the WTP, the ECN bits are set to zero (0) in the > outer header. The WTP does not modify the ECN bits in the original > station's packet header. This mode of operation is detailed as the > "limited functionality option" in [RFC3168]. > > = > I believe that the text above is consistent with the requirement listed i= n RFC 3168: > = > > All IP tunnels MUST implement the limited-functionality option, and > SHOULD support the full-functionality option. > > = > I believe that requiring all CAPWAP implementations now support full-func= tionality today will require some significant changes to existing hardware = that is shipping today, which I believe would not be in the best interest o= f the Internet community. I would prefer we keep the text as-is, and re-exa= mine this question at the next version of the CAPWAP protocol. I am aware of these concerns, but how are this equipment going to handle all the other changes that has been introduced in the protocol as result of the IESG review? We already made changes to message handling state machine for example. So, from a standards point of view any implementation based on the draft two versions ago will not be compliant with the RFC. They might interoperate or they may not, I don't claim understanding of all the details of these changes. The reason for this discussion is to determine if my discuss is a reasonable one or not. For that we need the views of others. Best Regards Magnus -- = Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 17 09:30:23 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A523A6A9E for ; Fri, 17 Oct 2008 09:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l15CZNGml1NY for ; Fri, 17 Oct 2008 09:30:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B765628C0EF for ; Fri, 17 Oct 2008 09:30:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4F156430340 for ; Fri, 17 Oct 2008 09:31:27 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 8AF65440006 for ; Fri, 17 Oct 2008 09:31:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6F2543610064 for ; Fri, 17 Oct 2008 09:31:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 23DF8361005F for ; Fri, 17 Oct 2008 09:31:20 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.71 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 17 Oct 2008 09:31:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,432,1220227200"; d="scan'208";a="96355546" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2008 16:31:14 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9HGVEI1001262; Fri, 17 Oct 2008 09:31:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m9HGVERW024577; Fri, 17 Oct 2008 16:31:14 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Oct 2008 09:31:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 09:30:46 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206A688BD@xmb-sjc-235.amer.cisco.com> In-Reply-To: <48F85606.4020205@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] ECN support when tunneling user packets in CAPWAP Thread-Index: AckwN/OMhoja3U1rRZCH1Madf/Is/AAPQCng References: <48F5B9A3.1040502@ericsson.com><4FF84B0BC277FF45AA27FE969DD956A206A683C5@xmb-sjc-235.amer.cisco.com> <48F85606.4020205@ericsson.com> From: "Pat Calhoun (pacalhou)" To: "Magnus Westerlund" X-OriginalArrivalTime: 17 Oct 2008 16:31:14.0598 (UTC) FILETIME=[C5E1B460:01C93075] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap , tsvwg Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com >Pat Calhoun (pacalhou) skrev: >> Hi Magnus, >> >> I continue to be concerned about the request to make ECN Full option support mandatory. Just to recap, the current spec currently reads: > >Please be clear that I haven't said that it is mandated to use. Only saying that it >should be mandated to support in the protocol. I have suggested one way of accomplishing >this that mandates it usage, but I have arrived at the conclusion that this may not >be the best way of doing it. Considering the draft version implementations a signalling >function seems an attractive way forward from my perspective. > I'm unclear as to the difference between mandated to support and use. Whether it is used or not, we are stating that all implementations must implement the features and functions necessary to support the ECN full option. Where I am confused is that the MUST vs. SHOULD in RFC 3168 is only pertinent to implementations that claim interoperability with the said RFC. Nowhere does it explicitely state that all tunneling protocols MUST support the RFC. That said, I think following the recommendations in the RFC, which is a MUST for the limited option, and a SHOULD for a full option, is what the current text reads. I continue to be confused about why following the recommendations of the RFC is not sufficient. >> >> >> 4.5.2. Quality of Service >> [...] >> The IP header also includes the Explicit Congestion Notification >> (ECN) bits [RFC3168]. When packets received from stations are >> encapsulated by the WTP, the ECN bits are set to zero (0) in the >> outer header. The WTP does not modify the ECN bits in the original >> station's packet header. This mode of operation is detailed as the >> "limited functionality option" in [RFC3168]. >> >> >> I believe that the text above is consistent with the requirement listed in RFC 3168: >> >> >> All IP tunnels MUST implement the limited-functionality option, and >> SHOULD support the full-functionality option. >> >> >> I believe that requiring all CAPWAP implementations now support full-functionality >>today will require some significant changes to existing hardware that is shipping >>today, which I believe would not be in the best interest of the Internet community. >>I would prefer we keep the text as-is, and re-examine this question at the next version of the CAPWAP protocol. > >I am aware of these concerns, but how are this equipment going to handle all the >other changes that has been introduced in the protocol as result of the IESG >review? We already made changes to message handling state machine for example. >So, from a standards point of view any implementation based on the draft two >versions ago will not be compliant with the RFC. They might interoperate or they >may not, I don't claim understanding of all the details of these changes. The primary difference, Magnus, is that to date, none of the changes have affected the data plane. All of the changes, whether message element format or otherwise, have only affected the control plane, which is typically done in software. > >The reason for this discussion is to determine if my discuss is a reasonable one or >not. For that we need the views of others. > Agreed... PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 17 14:30:18 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A4D28C127 for ; Fri, 17 Oct 2008 14:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLeBs5hDFUJB for ; Fri, 17 Oct 2008 14:30:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 1723828C124 for ; Fri, 17 Oct 2008 14:30:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5AB751C40F37 for ; Fri, 17 Oct 2008 14:31:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C0CC1440006 for ; Fri, 17 Oct 2008 14:31:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AE69436100D0 for ; Fri, 17 Oct 2008 14:31:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 72F6336100CE for ; Fri, 17 Oct 2008 14:31:07 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Fri, 17 Oct 2008 14:31:07 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id ED2BE3A6B15; Fri, 17 Oct 2008 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081017213001.ED2BE3A6B15@core3.amsl.com> Date: Fri, 17 Oct 2008 14:30:01 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-protocol-binding-ieee80211-11.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Binding for IEEE 802.11 Author(s) : M. Montemurro, D. Stanley, P. Calhoun Filename : draft-ietf-capwap-protocol-binding-ieee80211-11.txt Pages : 83 Date : 2008-10-17 Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-binding-ieee80211-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-protocol-binding-ieee80211-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-17142504.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Oct 18 07:01:48 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E98D3A6974 for ; Sat, 18 Oct 2008 07:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE9qtXnQDnfC for ; Sat, 18 Oct 2008 07:01:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id CE2C63A68C6 for ; Sat, 18 Oct 2008 07:01:47 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9F3EB4303DA for ; Sat, 18 Oct 2008 07:02:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 88D0A440006 for ; Sat, 18 Oct 2008 07:02:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 72EDE3610100 for ; Sat, 18 Oct 2008 07:02:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 9548E36100FE for ; Sat, 18 Oct 2008 07:02:49 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from pass-seymour.com (marussyr001.pass-seymour.com [12.33.96.185]) by mx1.tigertech.net (Postfix) with ESMTP for ; Sat, 18 Oct 2008 07:02:49 -0700 (PDT) Received: from ([172.16.5.211]) by Marussyr001.pass-seymour.com with ESMTP id 5202449.50145025; Sat, 18 Oct 2008 09:53:35 -0400 From: mike.hines@ortronics.com To: capwap@frascone.com Message-ID: Date: Sat, 18 Oct 2008 10:02:24 -0400 X-MIMETrack: Serialize by Router on US-SYR-HUB-01/SRV/GRPLEG(Release 6.5.6|March 06, 2007) at 10/18/2008 10:02:26 AM MIME-Version: 1.0 Subject: [Capwap] Mike Hines/PSL/US is out of the office. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com I will be out of the office starting 10/16/2008 and will not return until 10/20/2008. In my absence, feel free to leave an e-mail or contact Rudy Montgelas at (860) 405-2969 / rudolph.montgelas@ortronics.com for immediate assistance. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 20 02:19:59 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F31C83A6A55 for ; Mon, 20 Oct 2008 02:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.838 X-Spam-Level: X-Spam-Status: No, score=-4.838 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQE+fxwel0YJ for ; Mon, 20 Oct 2008 02:19:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E6EF83A6A17 for ; Mon, 20 Oct 2008 02:19:54 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2E6A24301BD for ; Mon, 20 Oct 2008 02:21:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 4F21A440006 for ; Mon, 20 Oct 2008 02:20:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2FE7934AF3BF for ; Mon, 20 Oct 2008 02:20:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 930DB34AF384 for ; Mon, 20 Oct 2008 02:20:58 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.60 whitelisted by list.dnswl.org 5.2) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 20 Oct 2008 02:20:58 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0D8D020B79; Mon, 20 Oct 2008 11:20:57 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-c1-48fc4d78d763 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CF08020936; Mon, 20 Oct 2008 11:20:56 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 11:19:48 +0200 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Oct 2008 11:19:48 +0200 Message-ID: <48FC4D34.3090601@ericsson.com> Date: Mon, 20 Oct 2008 11:19:48 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <48F5B9A3.1040502@ericsson.com><4FF84B0BC277FF45AA27FE969DD956A206A683C5@xmb-sjc-235.amer.cisco.com> <48F85606.4020205@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206A688BD@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206A688BD@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 20 Oct 2008 09:19:48.0149 (UTC) FILETIME=[FF984E50:01C93294] X-Brightmail-Tracker: AAAAAA== Cc: capwap , tsvwg Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun (pacalhou) skrev: >> Pat Calhoun (pacalhou) skrev: >>> Hi Magnus, >>> >>> I continue to be concerned about the request to make ECN Full option > support mandatory. Just to recap, the current spec currently reads: >> Please be clear that I haven't said that it is mandated to use. Only > saying that it = >> should be mandated to support in the protocol. I have suggested one way > of accomplishing = >> this that mandates it usage, but I have arrived at the conclusion that > this may not = >> be the best way of doing it. Considering the draft version > implementations a signalling = >> function seems an attractive way forward from my perspective. >> > = > I'm unclear as to the difference between mandated to support and use. > Whether it is used > or not, we are stating that all implementations must implement the > features and functions > necessary to support the ECN full option. Where I am confused is that > the MUST vs. SHOULD > in RFC 3168 is only pertinent to implementations that claim > interoperability with the said > RFC. Nowhere does it explicitely state that all tunneling protocols MUST > support the RFC. > That said, I think following the recommendations in the RFC, which is a > MUST for the limited > option, and a SHOULD for a full option, is what the current text reads. > I continue to be > confused about why following the recommendations of the RFC is not > sufficient. It says SHOULD for full functionality. So the question is why CAPWAP protocols does not need implement full functionality? What is the so reason that you don't need to follow the recommendation that a SHOULD is? If this was a MAY then I would agree that just implementing the limited functionality makes you fully compliant. With a SHOULD it is much more unclear. Yes, you can in certain cases not implement it. However, what are those reasons. That is what my discuss is about. Do capwap have good enough reasons? Regarding the need to implement it is based on that all claiming support for IP also needs to support ECN. RFC 3168 (ECN) updates RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers). From that you can also find that there is a sequence of obsoletes and updates that lead back to the host requirement specs. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 20 10:46:06 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4492C3A6B11 for ; Mon, 20 Oct 2008 10:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeDI6n+wtiuG for ; Mon, 20 Oct 2008 10:46:05 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 175813A6B1D for ; Mon, 20 Oct 2008 10:45:52 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3CCB54304F6 for ; Mon, 20 Oct 2008 10:46:24 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 7DED9D04067 for ; Mon, 20 Oct 2008 10:46:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id A86AB19FE6E for ; Mon, 20 Oct 2008 10:46:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 76D9619FE6B for ; Mon, 20 Oct 2008 10:46:15 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx3.tigertech.net (Postfix) with ESMTP for ; Mon, 20 Oct 2008 10:46:15 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id 843BE3A6AF2; Mon, 20 Oct 2008 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081020174502.843BE3A6AF2@core3.amsl.com> Date: Mon, 20 Oct 2008 10:45:02 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-protocol-specification-14.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Specification Author(s) : M. Montemurro, D. Stanley, P. Calhoun Filename : draft-ietf-capwap-protocol-specification-14.txt Pages : 163 Date : 2008-10-20 This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP working group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specification-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-protocol-specification-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-20103439.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 20 18:04:33 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2423A6874 for ; Mon, 20 Oct 2008 18:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyWwe-TAwJWj for ; Mon, 20 Oct 2008 18:04:32 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 593C83A68F2 for ; Mon, 20 Oct 2008 18:04:32 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8863543067F for ; Mon, 20 Oct 2008 18:05:45 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2ADA2D04067 for ; Mon, 20 Oct 2008 18:05:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id E21D9361005B for ; Mon, 20 Oct 2008 18:05:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 820CB361001F for ; Mon, 20 Oct 2008 18:05:31 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (192.100.105.134 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 20 Oct 2008 18:05:31 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9L15Pgh016151; Mon, 20 Oct 2008 20:05:26 -0500 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 04:05:24 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Oct 2008 20:05:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 20:05:20 -0500 Message-ID: <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> In-reply-to: <48F5B9A3.1040502@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] ECN support when tunneling user packets in CAPWAP Thread-Index: AckuqgFYn4fmJ9KnSWyecBcfZqmTUgEbMmzQ References: <48F5B9A3.1040502@ericsson.com> From: To: , X-OriginalArrivalTime: 21 Oct 2008 01:05:22.0698 (UTC) FILETIME=[180576A0:01C93319] X-Nokia-AV: Clean Cc: tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi Magnus, = When we developed the capwap requirements years ago, we wanted to provide f= or the private corporate internel networks as well as implementations that = traverse open IP networks, resulting in some hardware inplementations that = target the closed network case. For this reason, we didn't require full = ECN support. = In order to address your concerns in light of our WG operating procedures, = and to prevent causing current implementations to barf, would you agree to = allow the spec to require the limited ECN functionality option with text to= note that full ECN functionality should be supported in environments that = run across the open internet? = We can then pursue your option to develop full ECN functionality in the nex= t release. = Would this approach meet your concerns? Best Regards, Dorothy = -----Original Message----- From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] = Sent: Wednesday, October 15, 2008 2:37 AM To: capwap Cc: tsvwg Subject: [Capwap] ECN support when tunneling user packets in CAPWAP Hi CAPWAP and TSVWG, This email is to start off a public discussion about what support for ECN t= hat the CAPWAP protocol (http://tools.ietf.org/wg/capwap/draft-ietf-capwap-protocol-specification/) should have. This is to resolve my Discuss. For the TSVWG people, the CAPWAP protocol is a control protocol of wireless= termination point (WTP), like 802.11 access points, from access control (A= C). The capwap protocol also have an option to tunnel the wireless frames w= ithin the protocol. It is in this context that the usage of ECN is relevant= . The wireless frames will commonly carry IP packets. Thus CAPWAP is among = other things an IP in IP tunneling protocol, although with some extra layer= s in between the two IP. So the issue here is what support of ECN should exist in the tunneling mech= anism. ECN (RFC 3168) specifies two options for how tunnels can handle ECN,= the full functionality option where ECN is enabled on the outer IP header = and the relevant state at the tunnel egress is copied to the inner packet. = The limited option where the outer header is set as ECN incapable. With the= limited option what could have been a mark if the inner packet is ECN enab= led becomes a packet drop thus lowering the utility of the ECN function. Th= e ECN specification have the following wording in section 9.1.1: All IP tunnels MUST implement the limited-functionality option, and SHOULD support the full-functionality option. >From my perspective I haven't seen any strong arguments why the = >protocol should only support the limited option. CAPWAP is intended to be used in ac= cess networks, that is a common location for congestion. Thus, the usage of= ECN within this network can have real positive impact on the user applicat= ions. Also ECN has been a part of IP at standard track level since 2001 and= continue to ignore this part of the IP for easy of implementation does not= help improve the Internet. Therefore I really think CAPWAP SHOULD support = full ECN. And with SHOULD I see it as there need to be real good reasons wh= y this shouldn't be supported. The complications with introducing the full ECN support option at this stag= e is two. One, there already exist implementations that uses this protocol = as so far specified (although some updates will be required to cover other = modifications found during the IETF last call and IESG review). These are l= ikely to operate with limited option as the specification hasn't discussed = ECN at all. Secondly, there is the interoperability issue between the tunnel ingress an= d egress if one is going to have this being configurable. The tunnel ingres= s needs to know the support for ECN handling at the tunnel egress. Thus the capwap protocol would need an extension to carry that information = in each direction. The problem with a full functionality ingress and limite= d functionality egress is that packets that should have been marked or drop= ped comes through without indication of congestion. Thus, the best option to take the current implementations into account and = allow for deployment of full functionality where possible would be to add a= dditional signaling to the CAPWAP protocol to indicate the capability of th= e egress to the ingress and configure the ingress correctly. If this can be= introduced in a manner that doesn't make current implementations barf, the= n a nice incremental deployment story exist. A second way to introduce full ECN functionality is simply to mandate it an= d live through a period with functionality failure towards any non specific= ation compliant device. So the questions are: - Does they exist arguments that motivates support of limited ECN functiona= lity only? - Further arguments why CAPWAP really should support ECN? - Am I over interpreting the requirement for supporting ECN? Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 20 19:23:25 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2475D3A6822 for ; Mon, 20 Oct 2008 19:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTgETFNMRU7Y for ; Mon, 20 Oct 2008 19:23:24 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 36E663A6816 for ; Mon, 20 Oct 2008 19:23:24 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8C0F743069F for ; Mon, 20 Oct 2008 19:24:37 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id A9EABD04067 for ; Mon, 20 Oct 2008 19:24:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 979891A11E1 for ; Mon, 20 Oct 2008 19:24:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 0D4B41A11E5 for ; Mon, 20 Oct 2008 19:24:30 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from cnshjsmin03.cn.alcatel-lucent.com (cnmailgate04.alcatel-sbell.com.cn [211.144.215.47]) by mx3.tigertech.net (Postfix) with ESMTP for ; Mon, 20 Oct 2008 19:24:29 -0700 (PDT) X-AuditID: ac189297-a8f7dbb000000fe5-3b-48fd3d2d68a8 Received: from cnshgsbhs01.ad4.ad.alcatel.com (unknown [172.24.146.145]) by cnshjsmin03.cn.alcatel-lucent.com (Symantec Mail Security) with ESMTP id 8AC60558002 for ; Tue, 21 Oct 2008 10:23:41 +0800 (HKT) Received: from CNSHGSMBS02.ad4.ad.alcatel.com ([172.24.146.172]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 21 Oct 2008 10:23:46 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C93324.0B131EB0" Date: Tue, 21 Oct 2008 10:23:45 +0800 Message-ID: <049668664A99234BA838F1A6739B0F6A0183ADB2@CNSHGSMBS02.ad4.ad.alcatel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-wen-capwap-wlan-vlan-00.txt Thread-Index: AckubkKrAXuLlu7SS3yx65qwx9yfPAEtVRqg From: "WEN Haibo" To: X-OriginalArrivalTime: 21 Oct 2008 02:23:46.0022 (UTC) FILETIME=[0B6BC060:01C93324] X-Brightmail-Tracker: AAAAAA== Cc: JAIN Sudhanshu Subject: [Capwap] FW: I-D Action:draft-wen-capwap-wlan-vlan-00.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C93324.0B131EB0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear all, Hope you could give some comments on this draft. Thank you very much! Best regards, Haibo=20 -----Original Message----- From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = Internet-Drafts@ietf.org Sent: 2008=C4=EA10=D4=C215=C8=D5 10:30 To: i-d-announce@ietf.org Subject: I-D Action:draft-wen-capwap-wlan-vlan-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : CAPWAP WLAN-VLAN Information Message Element Author(s) : H. Wen, S. JAIN Filename : draft-wen-capwap-wlan-vlan-00.txt Pages : 8 Date : 2008-10-14 In Control And Provisioning of Wireless Access Points Protocol, the = WLANs on the Wireless Termination Point are created by the Access = Controller with the appropriate setting. This document defines a mew = messages elements, i.e., WLAN-VLAN Information message element, which is = used to set WLAN-VLAN binding information on the WTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wen-capwap-wlan-vlan-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. ------_=_NextPart_001_01C93324.0B131EB0 Content-Type: application/octet-stream; name="draft-wen-capwap-wlan-vlan-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-wen-capwap-wlan-vlan-00.URL Content-Disposition: attachment; filename="draft-wen-capwap-wlan-vlan-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC13ZW4tY2Fwd2FwLXdsYW4tdmxhbi0wMC50eHQNCg== ------_=_NextPart_001_01C93324.0B131EB0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C93324.0B131EB0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 20 19:24:12 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5773A68FF for ; Mon, 20 Oct 2008 19:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsyqRxDT-o+O for ; Mon, 20 Oct 2008 19:24:11 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8FAE63A6816 for ; Mon, 20 Oct 2008 19:24:11 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 03EC14306DB for ; Mon, 20 Oct 2008 19:25:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 5ED47D04067 for ; Mon, 20 Oct 2008 19:25:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 4E343361005B for ; Mon, 20 Oct 2008 19:25:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 6325C361001F for ; Mon, 20 Oct 2008 19:25:17 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from cnshjsmin03.cn.alcatel-lucent.com (cnmailgate04.alcatel-sbell.com.cn [211.144.215.47]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 20 Oct 2008 19:25:17 -0700 (PDT) X-AuditID: ac189297-acf85bb000000fe5-ba-48fd3d5f128c Received: from cnshgsbhs01.ad4.ad.alcatel.com (unknown [172.24.146.145]) by cnshjsmin03.cn.alcatel-lucent.com (Symantec Mail Security) with ESMTP id 57B1D558003 for ; Tue, 21 Oct 2008 10:24:31 +0800 (HKT) Received: from CNSHGSMBS02.ad4.ad.alcatel.com ([172.24.146.172]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 21 Oct 2008 10:24:35 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C93324.28BCC06A" Date: Tue, 21 Oct 2008 10:24:35 +0800 Message-ID: <049668664A99234BA838F1A6739B0F6A0183ADB3@CNSHGSMBS02.ad4.ad.alcatel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-wen-capwap-station-ip-address-00.txt Thread-Index: AckucE8DOKWjHJZ3RGOspBgiK3JQHwEs8Iqg From: "WEN Haibo" To: X-OriginalArrivalTime: 21 Oct 2008 02:24:35.0820 (UTC) FILETIME=[291A52C0:01C93324] X-Brightmail-Tracker: AAAAAA== Cc: JAIN Sudhanshu Subject: [Capwap] FW: I-D Action:draft-wen-capwap-station-ip-address-00.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C93324.28BCC06A Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear all, Hope you could give some comments on this draft. Thank you very much! Best regards, Haibo=20 -----Original Message----- From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = Internet-Drafts@ietf.org Sent: 2008=C4=EA10=D4=C215=C8=D5 10:45 To: i-d-announce@ietf.org Subject: I-D Action:draft-wen-capwap-station-ip-address-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : CAPWAP Station IP Address Author(s) : H. Wen, S. JAIN Filename : draft-wen-capwap-station-ip-address-00.txt Pages : 8 Date : 2008-10-14 In Control And Provisioning of Wireless Access Points Protocol, the = Access Controller controls whether Wireless Termination Point should = forward the traffic for some specified station. This document defines a = mew messages elements, IEEE Station IP Address, which are used for = better control of station's access in local-MAC mode of CAPWAP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wen-capwap-station-ip-address-0= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. ------_=_NextPart_001_01C93324.28BCC06A Content-Type: application/octet-stream; name="draft-wen-capwap-station-ip-address-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-wen-capwap-station-ip-address-00.URL Content-Disposition: attachment; filename="draft-wen-capwap-station-ip-address-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC13ZW4tY2Fwd2FwLXN0YXRpb24taXAtYWRkcmVzcy0wMC50eHQNCg== ------_=_NextPart_001_01C93324.28BCC06A Content-Type: text/plain; name="ATT1097644.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1097644.txt Content-Disposition: attachment; filename="ATT1097644.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C93324.28BCC06A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C93324.28BCC06A-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 21 02:26:54 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09493A6B2A for ; Tue, 21 Oct 2008 02:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.924 X-Spam-Level: X-Spam-Status: No, score=-4.924 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcwUV4uGxwyZ for ; Tue, 21 Oct 2008 02:26:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 889123A6AA6 for ; Tue, 21 Oct 2008 02:26:51 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 387664301AC for ; Tue, 21 Oct 2008 02:28:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C3948D04067 for ; Tue, 21 Oct 2008 02:27:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A8D4334AF50B for ; Tue, 21 Oct 2008 02:27:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 1D75034AF4DB for ; Tue, 21 Oct 2008 02:27:56 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.60 whitelisted by list.dnswl.org 5.2) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 21 Oct 2008 02:27:56 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3D64620239; Tue, 21 Oct 2008 11:27:54 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-3d-48fda09a90a8 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 216A320AD6; Tue, 21 Oct 2008 11:27:54 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 11:26:05 +0200 Received: from [153.88.44.140] ([153.88.44.140]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 11:26:04 +0200 Message-ID: <48FDA02C.8080506@ericsson.com> Date: Tue, 21 Oct 2008 11:26:04 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Dorothy.Gellert@nokia.com References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> In-Reply-To: <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 21 Oct 2008 09:26:04.0838 (UTC) FILETIME=[0A883C60:01C9335F] X-Brightmail-Tracker: AAAAAA== Cc: capwap@frascone.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Dorothy.Gellert@nokia.com skrev: > Hi Magnus, = > = > When we developed the capwap requirements years ago, we wanted to provide= for the private corporate internel networks as well as implementations tha= t traverse open IP networks, resulting in some hardware inplementations tha= t target the closed network case. For this reason, we didn't require ful= l ECN support. = > = > In order to address your concerns in light of our WG operating procedures= , and to prevent causing current implementations to barf, would you agree t= o allow the spec to require the limited ECN functionality option with text = to note that full ECN functionality should be supported in environments tha= t run across the open internet? = > = > We can then pursue your option to develop full ECN functionality in the n= ext release. = > = > Would this approach meet your concerns? The problem is I don't see how this can be made interoperable. Otherwise it would be fine. To have the option we need signalling that indicate what the tunnel egress supports. Otherwise a full functionality ingress can send to a limited egress and the congestion information are dropped. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 21 07:02:24 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148E628C104 for ; Tue, 21 Oct 2008 07:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGlSzDyM0Pg3 for ; Tue, 21 Oct 2008 07:02:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 649C828C117 for ; Tue, 21 Oct 2008 07:02:22 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DE08E4305C7 for ; Tue, 21 Oct 2008 07:03:03 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 45EBBD04067 for ; Tue, 21 Oct 2008 07:03:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 303C919EB4A for ; Tue, 21 Oct 2008 07:03:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 55EB319EB62 for ; Tue, 21 Oct 2008 07:02:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from pass-seymour.com (marussyr001.pass-seymour.com [12.33.96.185]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 21 Oct 2008 07:02:57 -0700 (PDT) Received: from ([172.16.5.211]) by Marussyr001.pass-seymour.com with ESMTP id 5202449.50284479; Tue, 21 Oct 2008 09:56:04 -0400 From: mike.hines@ortronics.com To: capwap@frascone.com Message-ID: Date: Tue, 21 Oct 2008 10:02:40 -0400 X-MIMETrack: Serialize by Router on US-SYR-HUB-01/SRV/GRPLEG(Release 6.5.6|March 06, 2007) at 10/21/2008 10:02:42 AM MIME-Version: 1.0 Subject: [Capwap] Mike Hines/PSL/US is out of the office. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com I will be out of the office starting 10/21/2008 and will not return until 10/22/2008. In my absence, feel free to leave an e-mail or contact Rudy Montgelas at (860) 405-2969 / rudolph.montgelas@ortronics.com for immediate assistance. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 21 10:03:28 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B1C28C169 for ; Tue, 21 Oct 2008 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.442 X-Spam-Level: X-Spam-Status: No, score=-4.442 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Nq1iPPdYUrk for ; Tue, 21 Oct 2008 10:03:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 4DD4028C164 for ; Tue, 21 Oct 2008 10:03:21 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1B4CE4305EB for ; Tue, 21 Oct 2008 10:04:36 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id D83D5D04067 for ; Tue, 21 Oct 2008 10:04:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id BDBDD19F475 for ; Tue, 21 Oct 2008 10:04:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id B1DC819F4C2 for ; Tue, 21 Oct 2008 10:04:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 21 Oct 2008 10:04:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,458,1220227200"; d="scan'208";a="94091453" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2008 17:04:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9LH4NPM021558; Tue, 21 Oct 2008 10:04:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9LH4Nbg017742; Tue, 21 Oct 2008 17:04:23 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 10:04:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 10:04:22 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206AD29E1@xmb-sjc-235.amer.cisco.com> In-Reply-To: <48FDA02C.8080506@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] ECN support when tunneling user packets in CAPWAP Thread-Index: AckzX0+6CPXJ5leXTYewByOwCVJx7wAP1XoQ References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> From: "Pat Calhoun (pacalhou)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 21 Oct 2008 17:04:23.0080 (UTC) FILETIME=[10C2FA80:01C9339F] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > The problem is I don't see how this can be made interoperable. Otherwise it would be fine. To have the option we need > signalling that indicate what the tunnel egress supports. Otherwise a full functionality ingress can send to a limited > egress and the congestion information are dropped. But regardless of whether signalling is implemented, congestion information would be dropped. So having the WTP (or AC) send the information, and hope that the other end can support full functionality, is the best it can hope for. If the receiver were to signal it only does limited functionality, then chances are the sending party will not behave any differently anyhow. The only upside to signalling is to be able to display the peer's capabilities. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 22 01:42:00 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1083A6AFC for ; Wed, 22 Oct 2008 01:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu-cbAD800v5 for ; Wed, 22 Oct 2008 01:41:58 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E56913A6A89 for ; Wed, 22 Oct 2008 01:41:57 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 33386430226 for ; Wed, 22 Oct 2008 01:43:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id D81F7440006 for ; Wed, 22 Oct 2008 01:43:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C77F83610075 for ; Wed, 22 Oct 2008 01:43:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 17D733610074 for ; Wed, 22 Oct 2008 01:43:01 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (192.100.122.233 whitelisted by list.dnswl.org 13.2) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 22 Oct 2008 01:43:00 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9M8gYM8005448; Wed, 22 Oct 2008 11:42:56 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 11:42:53 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Oct 2008 03:42:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 03:42:49 -0500 Message-ID: <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFB1F2@daebe103.NOE.Nokia.com> In-reply-to: <48FDA02C.8080506@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] ECN support when tunneling user packets in CAPWAP Thread-Index: AckzX061xuV9fRIpQpuQ7Acqu3GWLQAvbsaQ References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> From: To: X-OriginalArrivalTime: 22 Oct 2008 08:42:49.0575 (UTC) FILETIME=[2A0C4770:01C93422] X-Nokia-AV: Clean Cc: capwap@frascone.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi Magnus and Capwap WG, As we've defined the capwap protocol, we have interoperability within the e= nterprise case, which has limited ECN functionality, but is RFC compliant. = Since there exist implementations within the WG community that will cause = hardware failure, we won't have any degree of interoperability if we were t= o postpone the binding specificaton until the SHOULD portion of RFC 3168 is= implemented. = Is there any support for the binding specifcation towards the enterprise ca= se so that we can support interoperability and resolve the final discuss? I encourge the WG to weigh in on this final discussion point. We are getti= ng few comments on the list and Magnus has taken the time to document and p= resent congestion concern and the use of ECN. = Best Regards, Dorothy -----Original Message----- From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] = Sent: Tuesday, October 21, 2008 2:26 AM To: Gellert Dorothy (Nokia-CIC/MtView) Cc: capwap@frascone.com; tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP Dorothy.Gellert@nokia.com skrev: > Hi Magnus, > = > When we developed the capwap requirements years ago, we wanted to provide= for the private corporate internel networks as well as implementations tha= t traverse open IP networks, resulting in some hardware inplementations tha= t target the closed network case. For this reason, we didn't require ful= l ECN support. = > = > In order to address your concerns in light of our WG operating procedures= , and to prevent causing current implementations to barf, would you agree t= o allow the spec to require the limited ECN functionality option with text = to note that full ECN functionality should be supported in environments tha= t run across the open internet? = > = > We can then pursue your option to develop full ECN functionality in the n= ext release. = > = > Would this approach meet your concerns? The problem is I don't see how this can be made interoperable. Otherwise it= would be fine. To have the option we need signalling that indicate what th= e tunnel egress supports. Otherwise a full functionality ingress can send t= o a limited egress and the congestion information are dropped. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 22 05:44:52 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EAF43A69EE for ; Wed, 22 Oct 2008 05:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wcz+yIEYWnsw for ; Wed, 22 Oct 2008 05:44:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 574323A6804 for ; Wed, 22 Oct 2008 05:44:51 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AEA2443038F for ; Wed, 22 Oct 2008 05:45:53 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 688F0440006 for ; Wed, 22 Oct 2008 05:45:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 4F10E19EE27 for ; Wed, 22 Oct 2008 05:45:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id B5C1319EA32 for ; Wed, 22 Oct 2008 05:45:46 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx3.tigertech.net (Postfix) with ESMTP for ; Wed, 22 Oct 2008 05:45:46 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Vmgj1a00C0b6N64A2olmDp; Wed, 22 Oct 2008 12:45:46 +0000 Received: from [10.0.0.145] ([64.241.37.140]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id Vol51a00M31Re0Y8PolDAU; Wed, 22 Oct 2008 12:45:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=FZOf11M51wQA:10 a=bWCOJchBm9MA:10 a=RflBIR96BQPpR1WN_4MA:9 a=D8vSBYoEjLNX1hjwEHIA:7 a=s_kPw_rH_IuHNnrT968KpQBDbR4A:4 a=3SmO1NJXDBsA:10 Message-Id: <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> From: Margaret Wasserman To: Magnus Westerlund In-Reply-To: <48FDA02C.8080506@ericsson.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 08:45:03 -0400 References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> X-Mailer: Apple Mail (2.929.2) Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi Magnus, On Oct 21, 2008, at 5:26 AM, Magnus Westerlund wrote: > The problem is I don't see how this can be made interoperable. > Otherwise > it would be fine. To have the option we need signalling that indicate > what the tunnel egress supports. Otherwise a full functionality > ingress > can send to a limited egress and the congestion information are > dropped. The CAPWAP control protocol is designed to be extensible. We anticipate that private enterprises will include private control messages in their implementations, and we also expect that later standards (new bindings or updated versions of the CAPWAP protocol) will contain additional control messages. As indicated in section 4.5.1.1 of the base CAPWAP specification: "When a WTP or AC receives a message with a Message Type Value field that is not recognized and is an odd number, the number in the Message Type Value Field is incremented by one, and a Response message with a Message Type Value field containing the incremented value and containing the Result Code message element with the value (Unrecognized Request) is returned to the sender of the received message. If the unknown message type is even, the message is ignored." This makes it very easy to add a feature (such as the ability to negotiate a different ECN mode) in a new version of CAPWAP. If a WTP or AC wishes to negotiate use of a new feature, it would send a message requesting the feature (use of the full functionality ECN mode) , and wait for a reply from the other end. If the reply contained a Result Code of "Unrecognized Request", the requestor would know that it was not supported on the remote end and would keep using the default behavior (in this case, limited functionality ECN). So, I do believe that it would be possible to add the ability to negotiate a different ECN mode to a later version of CAPWAP in an interoperable way. That specification would presumably include the details such as which end(s) can send the request and how an AC or WTP that implements this feature should respond. As I indicated in a private message to you before this issue came to the list, I have two issues with adding "full functionality" ECN mode to CAPWAP at this time: (1) RFC 3168 isn't a BCP, and it doesn't state any requirements for future IETF protocols. Typically, the requirements in a Standards Track RFC apply to implementations that claim compliance with that RFC. In this case, implementations that claim compliance with RFC 3168 MUST implement the limited functionality and SHOULD implement the full functionality. There are cases where we have written RFCs that do place requirements on future IETF specifications, but they are very explicit about the fact that they are doing that. There have been several tunneling specs published since RFC 3168 was approved. Are there any other cases where RFC 3168 has been interpreted to apply to tunneling specifications? Were those specifications required to include a MUST for the full functionality option? (2) Even if I did agree that RFC 3168 should apply to CAPWAP, RFC 3168 claims that there are two viable options for handling ECN in IP-in-IP tunnels and that tunnels SHOULD implement the full functionality implementation and MUST implement the limited functionality implementation. By telling us to include a MUST for implementation of the full functionality in the CAPWAP spec, you are telling us that CAPWAP needs to comply with more stringent requirements in this area than RFC 3168 places on other IP-in-IP tunnels. Why do you think that makes sense? In some sense, that is a technicality-based argument, though. This discussion should really be about what is the right technical choice for the protocol... In this case, there are two things that we need to trade off: - Enabling better ECN functionality - Allowing CAPWAP to run on existing switch hardware We are not expecting that companies will produce new hardware products just to run CAPWAP. We are in a situation where most of the enterprise switch vendors have something similar to CAPWAP (such as LWAPP from Cisco, etc.) that only works between their ACs and WTPs. We are trying to standardize a protocol that will allow one vendor's AP to work with other vendor's WTPs, eliminating the lock-in that is inherent in the current situation and allowing customers to build a viable multi-vendor network. It is essential to the success of the CAPWAP protocol that we do not include features in CAPWAP that would require a hardware upgrade to deployed ACs and WTPs. This goal has been the topic of much WG discussion, and we've made several significant compromises to ensure that CAPWAP will work in its default configuration on all of the existing hardware that we are aware of. Some of these compromises have been very significant, more significant IMO than the question of which ECN mode(s) we enable, and the WG has consistently chosen the path that will allow deployment on existing hardware. This is _not_ just a situation where people who have already implemented CAPWAP are reticent to change their software implementations (although we are). It is a case where requiring us to implement the full ECN functionality will have one of two effects: (1) Vendors will not move to CAPWAP from their current proprietary solutions, because they can not develop a compliant implementation on their existing deployed hardware and they don't want to leave their customers behind. OR (2) Vendors will simply ignore our "MUST implement" and it will be meaningless. We will cost our friends (the ones would actually strive to meet our requirements) money while not actually achieving anything beneficial. In fact, depending on how the requirement for full functionality ECN is specified, this might _create_ an interoperability problem rather than resolving one. I explained, in the first part of this message, how we could add a full functionality ECN to CAPWAP later in an interoperable manner. Does that resolve your discuss? Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 22 06:20:55 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BEC3A6886 for ; Wed, 22 Oct 2008 06:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoBzzAri2N05 for ; Wed, 22 Oct 2008 06:20:51 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 948BB3A690E for ; Wed, 22 Oct 2008 06:20:51 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 180434303AB for ; Wed, 22 Oct 2008 06:21:05 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 001A2440006 for ; Wed, 22 Oct 2008 05:40:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id E438B19EE23 for ; Wed, 22 Oct 2008 05:40:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id D447B19EE09 for ; Wed, 22 Oct 2008 05:40:48 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by mx3.tigertech.net (Postfix) with ESMTP for ; Wed, 22 Oct 2008 05:40:48 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 13:40:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 13:40:44 +0100 Message-ID: In-Reply-To: <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFB1F2@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] [Capwap] ECN support when tunneling user packets inCAPWAP Thread-Index: AckzX061xuV9fRIpQpuQ7Acqu3GWLQAvbsaQAAli0iA= References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFB1F2@daebe103.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 22 Oct 2008 12:40:46.0745 (UTC) FILETIME=[67E78890:01C93443] X-Mailman-Approved-At: Wed, 22 Oct 2008 06:20:52 -0700 Cc: capwap@frascone.com, tsvwg@ietf.org Subject: Re: [Capwap] [Tsvwg] ECN support when tunneling user packets inCAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com I think it would be worthwhile people looking at Bob Briscoe's TSVWG draft = concerning tunnelling of ECN (draft-ietf-tsvwg-ecn-tunnel-00). It seems to = me that what you are proposing doing with CAPWAP will just add yet another = level of compatibility problems between tunnel behaviours. Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 = > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Dorothy.Gellert@nokia.com > Sent: 22 October 2008 09:43 > To: magnus.westerlund@ericsson.com > Cc: capwap@frascone.com; tsvwg@ietf.org > Subject: Re: [Tsvwg] [Capwap] ECN support when tunneling user packets > inCAPWAP > = > Hi Magnus and Capwap WG, > = > As we've defined the capwap protocol, we have interoperability within > the enterprise case, which has limited ECN functionality, but is RFC > compliant. Since there exist implementations within the WG community > that will cause hardware failure, we won't have any degree of > interoperability if we were to postpone the binding specificaton until > the SHOULD portion of RFC 3168 is implemented. > = > Is there any support for the binding specifcation towards the > enterprise case so that we can support interoperability and resolve the > final discuss? > = > I encourge the WG to weigh in on this final discussion point. We are > getting few comments on the list and Magnus has taken the time to > document and present congestion concern and the use of ECN. > = > Best Regards, > Dorothy > = > = > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, October 21, 2008 2:26 AM > To: Gellert Dorothy (Nokia-CIC/MtView) > Cc: capwap@frascone.com; tsvwg@ietf.org > Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP > = > Dorothy.Gellert@nokia.com skrev: > > Hi Magnus, > > > > When we developed the capwap requirements years ago, we wanted to > provide for the private corporate internel networks as well as > implementations that traverse open IP networks, resulting in some > hardware inplementations that target the closed network case. For > this reason, we didn't require full ECN support. > > > > In order to address your concerns in light of our WG operating > procedures, and to prevent causing current implementations to barf, > would you agree to allow the spec to require the limited ECN > functionality option with text to note that full ECN functionality > should be supported in environments that run across the open internet? > > > > We can then pursue your option to develop full ECN functionality in > the next release. > > > > Would this approach meet your concerns? > = > The problem is I don't see how this can be made interoperable. > Otherwise it would be fine. To have the option we need signalling that > indicate what the tunnel egress supports. Otherwise a full > functionality ingress can send to a limited egress and the congestion > information are dropped. > = > Cheers > = > Magnus Westerlund > = > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 22 08:07:04 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDEA28C12E for ; Wed, 22 Oct 2008 08:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.792 X-Spam-Level: X-Spam-Status: No, score=-4.792 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aMLJbkUwNUK for ; Wed, 22 Oct 2008 08:07:00 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2AC303A68D8 for ; Wed, 22 Oct 2008 08:07:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5206B4303E2 for ; Wed, 22 Oct 2008 08:08:17 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 470B3440006 for ; Wed, 22 Oct 2008 08:08:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 3639819F68A for ; Wed, 22 Oct 2008 08:08:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 64EF319F668 for ; Wed, 22 Oct 2008 08:08:02 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.62 whitelisted by list.dnswl.org 5.2) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by mx3.tigertech.net (Postfix) with ESMTP for ; Wed, 22 Oct 2008 08:08:02 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A96EA20529; Wed, 22 Oct 2008 17:08:00 +0200 (CEST) X-AuditID: c1b4fb3e-af787bb00000537b-e4-48ff41d07727 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7EF2720447; Wed, 22 Oct 2008 17:08:00 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 17:08:00 +0200 Received: from [153.88.52.49] ([153.88.52.49]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Oct 2008 17:07:59 +0200 Message-ID: <48FF41CF.5060904@ericsson.com> Date: Wed, 22 Oct 2008 17:07:59 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Margaret Wasserman References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> In-Reply-To: <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 22 Oct 2008 15:07:59.0788 (UTC) FILETIME=[F8CEEEC0:01C93457] X-Brightmail-Tracker: AAAAAA== Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi Margaret, I don't agree with your reasoning that RFC 3168 doesn't apply. Because ECN is a IP fixed header feature, thus something you need to support when implementing IP. And as the WTP and AC is a tunnel ingress and egress points this leads to a requirement handle IP tunnel functionality. The question which I hoped for feedback was the question about how one interpret the SHOULD use full functionality. Considering the possibility for upgrade if some one cares this could be fixed. I am a bit worried that one hasn't enabled this already now, as the network where ECN is likely to make a difference would be the access network that exist between the WTP and the AC. Cheers Magnus Margaret Wasserman skrev: > = > Hi Magnus, > = > On Oct 21, 2008, at 5:26 AM, Magnus Westerlund wrote: >> The problem is I don't see how this can be made interoperable. Otherwise >> it would be fine. To have the option we need signalling that indicate >> what the tunnel egress supports. Otherwise a full functionality ingress >> can send to a limited egress and the congestion information are dropped. > = > The CAPWAP control protocol is designed to be extensible. We anticipate > that private > enterprises will include private control messages in their > implementations, and we > also expect that later standards (new bindings or updated versions of > the CAPWAP > protocol) will contain additional control messages. > = > As indicated in section 4.5.1.1 of the base CAPWAP specification: > = > "When a WTP or AC receives a message with a Message Type Value field > that is not recognized and is an odd number, the number in the Message > Type Value Field is incremented by one, and a Response message with a > Message Type Value field containing the incremented value and containing > the Result Code message element with the value (Unrecognized Request) is > returned to the sender of the received message. If the unknown message > type is even, the message is ignored." > = > This makes it very easy to add a feature (such as the ability to > negotiate a different > ECN mode) in a new version of CAPWAP. If a WTP or AC wishes to > negotiate use > of a new feature, it would send a message requesting the feature (use > of the full > functionality ECN mode) , and wait for a reply from the other end. If > the reply contained > a Result Code of "Unrecognized Request", the requestor would know that > it was not > supported on the remote end and would keep using the default behavior > (in this case, > limited functionality ECN). > = > So, I do believe that it would be possible to add the ability to > negotiate a different > ECN mode to a later version of CAPWAP in an interoperable way. That > specification > would presumably include the details such as which end(s) can send the > request and > how an AC or WTP that implements this feature should respond. > = > As I indicated in a private message to you before this issue came to the > list, I have > two issues with adding "full functionality" ECN mode to CAPWAP at this > time: > = > (1) RFC 3168 isn't a BCP, and it doesn't state any requirements for > future IETF protocols. Typically, the requirements in a Standards > Track RFC apply to implementations that claim compliance with that RFC. = > In this case, implementations that claim compliance with RFC 3168 MUST > implement the limited functionality and SHOULD implement the full > functionality. There are cases where we have written RFCs that do place > requirements on future IETF specifications, but they are very explicit > about the fact that they are doing that. There have been several > tunneling specs published since RFC 3168 was approved. Are there any > other cases where RFC 3168 has been interpreted to apply to tunneling > specifications? Were those specifications required to include a MUST > for the full functionality option? > = > (2) Even if I did agree that RFC 3168 should apply to CAPWAP, RFC 3168 > claims that there are two viable options for handling ECN in IP-in-IP > tunnels and that tunnels SHOULD implement the full functionality > implementation and MUST implement the limited functionality > implementation. By telling us to include a MUST for implementation of > the full functionality in the CAPWAP spec, you are telling us that > CAPWAP needs to comply with more stringent requirements in this area > than RFC 3168 places on other IP-in-IP tunnels. Why do you think that > makes sense? > = > In some sense, that is a technicality-based argument, though. This > discussion should really be about what is the right technical choice for > the protocol... > = > In this case, there are two things that we need to trade off: > = > - Enabling better ECN functionality > - Allowing CAPWAP to run on existing switch hardware > = > We are not expecting that companies will produce new hardware products > just to run CAPWAP. We are in a situation where most of the enterprise > switch vendors have something similar to CAPWAP (such as LWAPP from > Cisco, etc.) that only works between their ACs and WTPs. We are trying > to standardize a protocol that will allow one vendor's AP to work with > other vendor's WTPs, eliminating the lock-in that is inherent in the > current situation and allowing customers to build a viable multi-vendor > network. > = > It is essential to the success of the CAPWAP protocol that we do not > include features in CAPWAP that would require a hardware upgrade to > deployed ACs and WTPs. This goal has been the topic of much WG > discussion, and we've made several significant compromises to ensure > that CAPWAP will work in its default configuration on all of the > existing hardware that we are aware of. Some of these compromises have > been very significant, more significant IMO than the question of which > ECN mode(s) we enable, and the WG has consistently chosen the path that > will allow deployment on existing hardware. > = > This is _not_ just a situation where people who have already implemented > CAPWAP are reticent to change their software implementations (although > we are). It is a case where requiring us to implement the full ECN > functionality will have one of two effects: > = > (1) Vendors will not move to CAPWAP from their current proprietary > solutions, because they can not develop a compliant implementation on > their existing deployed hardware and they don't want to leave their > customers behind. > = > OR > = > (2) Vendors will simply ignore our "MUST implement" and it will be > meaningless. We will cost our friends (the ones would actually strive > to meet our requirements) money while not actually achieving anything > beneficial. In fact, depending on how the requirement for full > functionality ECN is specified, this might _create_ an interoperability > problem rather than resolving one. > = > I explained, in the first part of this message, how we could add a full > functionality ECN to CAPWAP later in an interoperable manner. Does that > resolve your discuss? > = > Margaret > = > = > = -- = Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 22 08:26:26 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7893A697A for ; Wed, 22 Oct 2008 08:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnYd9E07TO5b for ; Wed, 22 Oct 2008 08:26:25 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 49DCE3A6823 for ; Wed, 22 Oct 2008 08:26:24 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 70451430415 for ; Wed, 22 Oct 2008 08:27:18 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 65E8DD04067 for ; Wed, 22 Oct 2008 08:27:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 4BABE19F7C9 for ; Wed, 22 Oct 2008 08:27:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 9370619F7C5 for ; Wed, 22 Oct 2008 08:27:11 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx3.tigertech.net (Postfix) with ESMTP for ; Wed, 22 Oct 2008 08:27:11 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Vnep1a00517dt5G55rTAzl; Wed, 22 Oct 2008 15:27:10 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA13.westchester.pa.mail.comcast.net with comcast id VrSp1a0051cMU3H3ZrSrZe; Wed, 22 Oct 2008 15:27:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=FZOf11M51wQA:10 a=bWCOJchBm9MA:10 a=6YMWKgzb7OR4zHnTjIAA:9 a=iz8y0Wm-Km9HBSkWU--zhoKEfoIA:4 a=WuK_CZDBSqoA:10 Message-Id: From: Margaret Wasserman To: Magnus Westerlund In-Reply-To: <48FF41CF.5060904@ericsson.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 11:26:48 -0400 References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> <48FF41CF.5060904@ericsson.com> X-Mailer: Apple Mail (2.929.2) Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com On Oct 22, 2008, at 11:07 AM, Magnus Westerlund wrote: > Considering the possibility for upgrade if some one cares this could > be > fixed. I am a bit worried that one hasn't enabled this already now, as > the network where ECN is likely to make a difference would be the > access > network that exist between the WTP and the AC. In the vast majority of cases where CAPWAP-like functionality is deployed today, the AC is an access controller for an enterprise wireless network, so there is very little network complexity between the WTP and the AC. In fact, the vast majority of deployments probably have _no_ IP routers between the WTP and the AC. It is not clear that there is much functional difference between the two ECN deployment modes in those cases. I agree that congestion may become and issues, though, if CAPWAP is deployed with the WTP and AC separated by a complex network topology. So, it would be good if we could support full functionality ECN. However, we really can't require all CAPWAP nodes to implement the full functionality ECN mode, because there is already a bunch of deployed hardware that won't do it, and we need CAPWAP to work on that hardware. Because the full functionality ECN requires a change in how we process every packet, it would require changes in the "data plane" -- the low-level hardware that encapsulates and decapsulates the CAPWAP data packets. Is that the need for compatibility with existing hardware that doesn't support full functionality ECN a good enough reason to allow us not to follow the SHOULD in RFC 3168 and only implement the limited functionality ECN mode (which is a MUST)? If not, what do you suggest we do instead, given the fact that we need to run this protocol on hardware that already exists and doesn't support the full functionality ECN? Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 22 12:04:27 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0523A6A7A for ; Wed, 22 Oct 2008 12:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gG-+uKcWsut for ; Wed, 22 Oct 2008 12:04:26 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3A84D3A6999 for ; Wed, 22 Oct 2008 12:04:26 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D733E43053A for ; Wed, 22 Oct 2008 12:05:23 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 8E150440006 for ; Wed, 22 Oct 2008 12:05:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 6F6CD1A01AD for ; Wed, 22 Oct 2008 12:05:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id A725E1A019A for ; Wed, 22 Oct 2008 12:05:17 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx3.tigertech.net (Postfix) with ESMTP for ; Wed, 22 Oct 2008 12:05:17 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA04.westchester.pa.mail.comcast.net with comcast id Vuf51a0090EZKEL54v5GFv; Wed, 22 Oct 2008 19:05:16 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA01.westchester.pa.mail.comcast.net with comcast id Vv4y1a00p1cMU3H3Mv51WC; Wed, 22 Oct 2008 19:05:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=FZOf11M51wQA:10 a=bWCOJchBm9MA:10 a=55jr06K9TwvMPPjYXHAA:9 a=28fu4LhtP0PycDdHnzoWZ1vJlvIA:4 a=AcZQ66N1Z8sA:10 Message-Id: From: Margaret Wasserman To: Margaret Wasserman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 15:04:58 -0400 References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> <48FF41CF.5060904@ericsson.com> X-Mailer: Apple Mail (2.929.2) Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Correcting my own typos... On Oct 22, 2008, at 11:26 AM, Margaret Wasserman wrote: > Is that the need for compatibility with existing hardware that doesn't > support full functionality ECN a good enough reason to allow us not to > follow the SHOULD in RFC 3168 and only implement the limited > functionality ECN mode (which is a MUST)? What I _meant_ to ask is: Is the need for compatibility with existing hardware (that doesn't support ECN in the "full functionality" mode) a good enough reason not to follow the SHOULD in RFC 3168? CAPWAP already meets the MUST in RFC 3168 of supporting "limited functionality" ECN. My final question remains: > If not, what do you suggest we do instead, given the fact that we need > to run this protocol on hardware that already exists and doesn't > support the full functionality ECN? Sorry, Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 23 01:43:55 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14B43A6C1E for ; Thu, 23 Oct 2008 01:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.831 X-Spam-Level: X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaUg8+8oAUIs for ; Thu, 23 Oct 2008 01:43:54 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 154203A6C1B for ; Thu, 23 Oct 2008 01:43:53 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8887B43027A for ; Thu, 23 Oct 2008 01:44:20 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id B9C5B440006 for ; Thu, 23 Oct 2008 01:44:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 981AF19DFCE for ; Thu, 23 Oct 2008 01:44:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 8CAC319DF69 for ; Thu, 23 Oct 2008 01:44:12 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.62 whitelisted by list.dnswl.org 5.2) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by mx3.tigertech.net (Postfix) with ESMTP for ; Thu, 23 Oct 2008 01:44:12 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 871EE22238; Thu, 23 Oct 2008 10:40:18 +0200 (CEST) X-AuditID: c1b4fb3e-abf80bb00000537b-5c-49003872b5e1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7767A22237; Thu, 23 Oct 2008 10:40:18 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 10:40:17 +0200 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 10:40:17 +0200 Message-ID: <49003871.5010301@ericsson.com> Date: Thu, 23 Oct 2008 10:40:17 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Margaret Wasserman References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> <48FF41CF.5060904@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 23 Oct 2008 08:40:17.0535 (UTC) FILETIME=[F9D690F0:01C934EA] X-Brightmail-Tracker: AAAAAA== Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Margaret, I think you have misinterpreted what I was suggesting as the way forward. I was suggesting to require a mechanism to indicate which functionality was in place. Recommend full ECN functionality but let the legacy nodes use the limited functionality. I wasn't clear on that I assumed that the legacy nodes would use limited functionality. I don't know what to really take away from Matt Mathis comment about that the failure mode may not be particular severe. The question is if not severe enough to require the signalling mechanism. Margaret Wasserman skrev: > = > Correcting my own typos... > = > On Oct 22, 2008, at 11:26 AM, Margaret Wasserman wrote: >> Is that the need for compatibility with existing hardware that doesn't >> support full functionality ECN a good enough reason to allow us not to >> follow the SHOULD in RFC 3168 and only implement the limited >> functionality ECN mode (which is a MUST)? > = > What I _meant_ to ask is: > = > Is the need for compatibility with existing hardware (that doesn't > support ECN in the > "full functionality" mode) a good enough reason not to follow the SHOULD > in RFC > 3168? CAPWAP already meets the MUST in RFC 3168 of supporting "limited > functionality" ECN. I think that require a signalling mechanism to indicate what is implemented together with a recommendation for full ECN functionality is reasonable based on a should. I just wished this hadn't come up in this stage in the process. > = > My final question remains: > = >> If not, what do you suggest we do instead, given the fact that we need >> to run this protocol on hardware that already exists and doesn't >> support the full functionality ECN? > = As indicated above. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 23 07:35:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8543A6A5C for ; Thu, 23 Oct 2008 07:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmLxl-lnCigg for ; Thu, 23 Oct 2008 07:35:34 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A76FF3A6919 for ; Thu, 23 Oct 2008 07:35:34 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 49D3343075E for ; Thu, 23 Oct 2008 07:36:43 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 022A8440006 for ; Thu, 23 Oct 2008 07:36:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id E936F19F03E for ; Thu, 23 Oct 2008 07:36:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 2C89E19F02A for ; Thu, 23 Oct 2008 07:36:28 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx3.tigertech.net (Postfix) with ESMTP for ; Thu, 23 Oct 2008 07:36:25 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA02.westchester.pa.mail.comcast.net with comcast id WBNJ1a0041GhbT852EcQyr; Thu, 23 Oct 2008 14:36:25 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA07.westchester.pa.mail.comcast.net with comcast id WEcB1a00X1cMU3H3TEcE0M; Thu, 23 Oct 2008 14:36:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=FZOf11M51wQA:10 a=bWCOJchBm9MA:10 a=bf5IWGkupQNB2c3efVUA:9 a=T5QkfHrEtecZ0iEbE7rA6aLdkx0A:4 a=BjCMj3f9L9QA:10 Message-Id: From: Margaret Wasserman To: Magnus Westerlund In-Reply-To: <49003871.5010301@ericsson.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 23 Oct 2008 10:36:09 -0400 References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> <48FF41CF.5060904@ericsson.com> <49003871.5010301@ericsson.com> X-Mailer: Apple Mail (2.929.2) Cc: capwap , tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > I don't know what to really take away from Matt Mathis comment about > that the failure mode may not be particular severe. The question is if > not severe enough to require the signalling mechanism. I don't think I've seen Matt Mathis' comment. Where was it sent? Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 23 07:58:49 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701903A6928 for ; Thu, 23 Oct 2008 07:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.825 X-Spam-Level: X-Spam-Status: No, score=-4.825 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpmqctV7Iz59 for ; Thu, 23 Oct 2008 07:58:40 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7BE203A68D1 for ; Thu, 23 Oct 2008 07:58:40 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 44A084307EE for ; Thu, 23 Oct 2008 08:00:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 53535440006 for ; Thu, 23 Oct 2008 07:59:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 3E26834AFAED for ; Thu, 23 Oct 2008 07:59:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id AAB0A34AFAC8 for ; Thu, 23 Oct 2008 07:59:52 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.60 whitelisted by list.dnswl.org 5.2) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 23 Oct 2008 07:59:52 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F41EE20B0E; Thu, 23 Oct 2008 16:59:50 +0200 (CEST) X-AuditID: c1b4fb3c-ab0c8bb0000015b5-48-490091660fbf Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D3E5020C85; Thu, 23 Oct 2008 16:59:50 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 16:59:50 +0200 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 16:59:50 +0200 Message-ID: <49009166.6060609@ericsson.com> Date: Thu, 23 Oct 2008 16:59:50 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Margaret Wasserman References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> <48FF41CF.5060904@ericsson.com> <49003871.5010301@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 23 Oct 2008 14:59:50.0376 (UTC) FILETIME=[FF825680:01C9351F] X-Brightmail-Tracker: AAAAAA== Cc: capwap , tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Margaret Wasserman skrev: >> >> I don't know what to really take away from Matt Mathis comment about >> that the failure mode may not be particular severe. The question is if >> not severe enough to require the signalling mechanism. > = > I don't think I've seen Matt Mathis' comment. Where was it sent? > = TSVWG list only: http://www.ietf.org/mail-archive/web/tsvwg/current/msg08685.html Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 23 08:09:26 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F303A68D7 for ; Thu, 23 Oct 2008 08:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOthNyJSQhfP for ; Thu, 23 Oct 2008 08:09:25 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 60DE43A67EE for ; Thu, 23 Oct 2008 08:09:25 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 35D0F430736 for ; Thu, 23 Oct 2008 08:10:45 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id BBEC9440006 for ; Thu, 23 Oct 2008 08:10:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A3AD234AFAED for ; Thu, 23 Oct 2008 08:10:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B9CFF34AFBA7 for ; Thu, 23 Oct 2008 08:10:37 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 23 Oct 2008 08:10:36 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA10.westchester.pa.mail.comcast.net with comcast id WF1R1a00416LCl05AFAcJh; Thu, 23 Oct 2008 15:10:36 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA06.westchester.pa.mail.comcast.net with comcast id WFAM1a00F1cMU3H3SFAP6g; Thu, 23 Oct 2008 15:10:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=FZOf11M51wQA:10 a=bWCOJchBm9MA:10 a=b6qV9G_O2ksncwWpi1EA:9 a=Bx5PVguWGMVXyN4aapIA:7 a=BGa5WJGInpRvrloKZzdGTsagp-4A:4 a=f7GxY0FH8QIA:10 a=3SmO1NJXDBsA:10 Message-Id: <45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> From: Margaret Wasserman To: Magnus Westerlund In-Reply-To: <49003871.5010301@ericsson.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 23 Oct 2008 11:10:19 -0400 References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> <48FF41CF.5060904@ericsson.com> <49003871.5010301@ericsson.com> X-Mailer: Apple Mail (2.929.2) Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Hi Magnus, Just to make sure I understand... You are asking us to add a new optional message to CAPWAP that will = enable "full functionality" ECN support (as described in 3168) on the = CAPWAP data channel. The default behavior will remain the same as = described in the current spec ("limited functionality" ECN), and it = will be up to vendors who implement CAPWAP whether they implement the = optional message in their products? If one end of the connection = supports "full functionality" ECN and the other does not, the = connection would continue to use the "limited functionality" mode. Is = that correct? If that would allow us to get the document approved, it seems likely = that we (more specifically Pat) could add this option to the spec, we = could get it reviewed by the WG, and we could probably have a new = document ready for publication within a few weeks, as long as no one = in the WG raises a significant objection. Pat, does that seem doable? I don't personally believe that the benefit of adding this option will = be worth the delay. I don't think that many vendors are likely to = implement the full functionality option, and I also don't believe that = full functionality vs. limited functionality ECN will make much = difference in the situations where CAPWAP is likely to be deployed. = But, if this is the only way forward, let's not waste any more time = arguing, let's just do it. Is there anyone in the WG who has a blocking objection to adding a = full functionality ECN option (as described in the first paragraph of = this message) to CAPWAP? Margaret > Margaret, > > I think you have misinterpreted what I was suggesting as the way > forward. I was suggesting to require a mechanism to indicate which > functionality was in place. Recommend full ECN functionality but let = > the > legacy nodes use the limited functionality. I wasn't clear on that I > assumed that the legacy nodes would use limited functionality. > > I don't know what to really take away from Matt Mathis comment about > that the failure mode may not be particular severe. The question is if > not severe enough to require the signalling mechanism. > > Margaret Wasserman skrev: >> >> Correcting my own typos... >> >> On Oct 22, 2008, at 11:26 AM, Margaret Wasserman wrote: >>> Is that the need for compatibility with existing hardware that = >>> doesn't >>> support full functionality ECN a good enough reason to allow us = >>> not to >>> follow the SHOULD in RFC 3168 and only implement the limited >>> functionality ECN mode (which is a MUST)? >> >> What I _meant_ to ask is: >> >> Is the need for compatibility with existing hardware (that doesn't >> support ECN in the >> "full functionality" mode) a good enough reason not to follow the = >> SHOULD >> in RFC >> 3168? CAPWAP already meets the MUST in RFC 3168 of supporting = >> "limited >> functionality" ECN. > > I think that require a signalling mechanism to indicate what is > implemented together with a recommendation for full ECN = > functionality is > reasonable based on a should. I just wished this hadn't come up in = > this > stage in the process. > >> >> My final question remains: >> >>> If not, what do you suggest we do instead, given the fact that we = >>> need >>> to run this protocol on hardware that already exists and doesn't >>> support the full functionality ECN? >> > > As indicated above. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 23 15:01:49 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF5528C18A for ; Thu, 23 Oct 2008 15:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.44 X-Spam-Level: X-Spam-Status: No, score=-4.44 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-u-Ypid8kY3 for ; Thu, 23 Oct 2008 15:01:48 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 0240A28C175 for ; Thu, 23 Oct 2008 15:00:13 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 07A9343093A for ; Thu, 23 Oct 2008 15:01:32 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 26DD2440006 for ; Thu, 23 Oct 2008 15:01:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 15FF3361007D for ; Thu, 23 Oct 2008 15:01:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A2100361007C for ; Thu, 23 Oct 2008 15:01:21 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.72 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by mx1.tigertech.net (Postfix) with ESMTP for ; Thu, 23 Oct 2008 15:01:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,472,1220227200"; d="scan'208";a="110716262" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2008 22:01:13 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9NM1DtT002073; Thu, 23 Oct 2008 15:01:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9NM1DG4014481; Thu, 23 Oct 2008 22:01:13 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 15:01:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 15:00:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206B38E4F@xmb-sjc-235.amer.cisco.com> In-Reply-To: <45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] ECN support when tunneling user packets in CAPWAP Thread-Index: Ack1IYQ6UR8VoYApTUCkOtBz+g2vdgAB/JCQ References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com> <45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" , "Magnus Westerlund" X-OriginalArrivalTime: 23 Oct 2008 22:01:13.0254 (UTC) FILETIME=[DD475C60:01C9355A] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com It is unclear to me that this is what Magnus is proposing - but if it is th= at simple, yes, I can make the requested change. Magnus, could you please c= onfirm that Margaret's recommendation below would address your discuss? PatC = -----Original Message----- From: Margaret Wasserman [mailto:mrw@lilacglade.org] = Sent: Thursday, October 23, 2008 8:10 AM To: Magnus Westerlund Cc: capwap@frascone.com; Dorothy.Gellert@nokia.com; tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP Hi Magnus, Just to make sure I understand... You are asking us to add a new optional message to CAPWAP that will enable = "full functionality" ECN support (as described in 3168) on the CAPWAP data = channel. The default behavior will remain the same as described in the cur= rent spec ("limited functionality" ECN), and it will be up to vendors who i= mplement CAPWAP whether they implement the optional message in their produc= ts? If one end of the connection supports "full functionality" ECN and the= other does not, the connection would continue to use the "limited function= ality" mode. Is that correct? If that would allow us to get the document approved, it seems likely that w= e (more specifically Pat) could add this option to the spec, we could get i= t reviewed by the WG, and we could probably have a new document ready for p= ublication within a few weeks, as long as no one in the WG raises a signifi= cant objection. Pat, does that seem doable? I don't personally believe that the benefit of adding this option will be w= orth the delay. I don't think that many vendors are likely to implement th= e full functionality option, and I also don't believe that full functionali= ty vs. limited functionality ECN will make much = difference in the situations where CAPWAP is likely to be deployed. = But, if this is the only way forward, let's not waste any more time arguing= , let's just do it. Is there anyone in the WG who has a blocking objection to adding a full fun= ctionality ECN option (as described in the first paragraph of this message)= to CAPWAP? Margaret > Margaret, > > I think you have misinterpreted what I was suggesting as the way = > forward. I was suggesting to require a mechanism to indicate which = > functionality was in place. Recommend full ECN functionality but let = > the legacy nodes use the limited functionality. I wasn't clear on that = > I assumed that the legacy nodes would use limited functionality. > > I don't know what to really take away from Matt Mathis comment about = > that the failure mode may not be particular severe. The question is if = > not severe enough to require the signalling mechanism. > > Margaret Wasserman skrev: >> >> Correcting my own typos... >> >> On Oct 22, 2008, at 11:26 AM, Margaret Wasserman wrote: >>> Is that the need for compatibility with existing hardware that = >>> doesn't support full functionality ECN a good enough reason to allow = >>> us not to follow the SHOULD in RFC 3168 and only implement the = >>> limited functionality ECN mode (which is a MUST)? >> >> What I _meant_ to ask is: >> >> Is the need for compatibility with existing hardware (that doesn't = >> support ECN in the "full functionality" mode) a good enough reason = >> not to follow the SHOULD in RFC 3168? CAPWAP already meets the MUST = >> in RFC 3168 of supporting "limited functionality" ECN. > > I think that require a signalling mechanism to indicate what is = > implemented together with a recommendation for full ECN functionality = > is reasonable based on a should. I just wished this hadn't come up in = > this stage in the process. > >> >> My final question remains: >> >>> If not, what do you suggest we do instead, given the fact that we = >>> need to run this protocol on hardware that already exists and = >>> doesn't support the full functionality ECN? >> > > As indicated above. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 27 07:50:08 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8963A6B82 for ; Mon, 27 Oct 2008 07:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTxeGg36t1uk for ; Mon, 27 Oct 2008 07:50:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id EDEC03A6B77 for ; Mon, 27 Oct 2008 07:50:06 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BA21D1C40F47 for ; Mon, 27 Oct 2008 07:50:06 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id EF054440006 for ; Mon, 27 Oct 2008 07:49:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id D7DCE19EEC1 for ; Mon, 27 Oct 2008 07:49:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 3A20919EEC3 for ; Mon, 27 Oct 2008 07:49:57 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.62 whitelisted by list.dnswl.org 5.2) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by mx3.tigertech.net (Postfix) with ESMTP for ; Mon, 27 Oct 2008 07:49:57 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 69A4C2130A; Mon, 27 Oct 2008 15:49:55 +0100 (CET) X-AuditID: c1b4fb3e-adf84bb00000537b-1a-4905d51311e3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3F23920399; Mon, 27 Oct 2008 15:49:55 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 15:49:51 +0100 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 15:49:51 +0100 Message-ID: <4905D50F.6010508@ericsson.com> Date: Mon, 27 Oct 2008 15:49:51 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Margaret Wasserman References: <48F5B9A3.1040502@ericsson.com> <0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com> <48FDA02C.8080506@ericsson.com> <1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org> <48FF41CF.5060904@ericsson.com> <49003871.5010301@ericsson.com> <45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> In-Reply-To: <45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 27 Oct 2008 14:49:51.0141 (UTC) FILETIME=[43FD5550:01C93843] X-Brightmail-Tracker: AAAAAA== Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Margaret Wasserman skrev: > = > Hi Magnus, > = > Just to make sure I understand... > = > You are asking us to add a new optional message to CAPWAP that will > enable "full functionality" ECN support (as described in 3168) on the > CAPWAP data channel. The default behavior will remain the same as > described in the current spec ("limited functionality" ECN), and it will > be up to vendors who implement CAPWAP whether they implement the > optional message in their products? If one end of the connection > supports "full functionality" ECN and the other does not, the connection > would continue to use the "limited functionality" mode. Is that correct? > = Yes, but I would voice ECN support as recommend full functionality, but clearly allowed to do only limited. But otherwise correct. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 27 08:00:37 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8BA3A6B8C for ; Mon, 27 Oct 2008 08:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.815 X-Spam-Level: X-Spam-Status: No, score=-102.815 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llo2KxtX3-Va for ; Mon, 27 Oct 2008 08:00:29 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 745FC28C1DF for ; Mon, 27 Oct 2008 08:00:12 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4FB921C40F75 for ; Mon, 27 Oct 2008 08:00:12 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 72F2D440023 for ; Mon, 27 Oct 2008 08:00:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 6165419EF83 for ; Mon, 27 Oct 2008 08:00:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id F23C319EF86 for ; Mon, 27 Oct 2008 08:00:01 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx3.tigertech.net (Postfix) with ESMTP for ; Mon, 27 Oct 2008 08:00:01 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id D38ED3A6B89; Mon, 27 Oct 2008 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081027150001.D38ED3A6B89@core3.amsl.com> Date: Mon, 27 Oct 2008 08:00:01 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D Action:draft-ietf-capwap-base-mib-02.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Base MIB Author(s) : Y. Shi, et al. Filename : draft-ietf-capwap-base-mib-02.txt Pages : 59 Date : 2008-10-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-base-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-base-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27074644.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 27 08:00:39 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93CFC3A6A91 for ; Mon, 27 Oct 2008 08:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.817 X-Spam-Level: X-Spam-Status: No, score=-102.817 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV3ogtkICi6W for ; Mon, 27 Oct 2008 08:00:28 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DDC3928C1AE for ; Mon, 27 Oct 2008 08:00:11 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B80331C40F74 for ; Mon, 27 Oct 2008 08:00:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 704C9440006 for ; Mon, 27 Oct 2008 08:00:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 2E88A34AC5A4 for ; Mon, 27 Oct 2008 08:00:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id F30F834AC22E for ; Mon, 27 Oct 2008 08:00:01 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 27 Oct 2008 08:00:01 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 0) id DE50C28C100; Mon, 27 Oct 2008 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081027150001.DE50C28C100@core3.amsl.com> Date: Mon, 27 Oct 2008 08:00:01 -0700 (PDT) Cc: capwap@frascone.com Subject: [Capwap] I-D Action:draft-ietf-capwap-802dot11-mib-02.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Binding MIB for IEEE 802.11 Author(s) : Y. Shi, et al. Filename : draft-ietf-capwap-802dot11-mib-02.txt Pages : 24 Date : 2008-10-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol for IEEE 802.11 wireless binding. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-802dot11-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-capwap-802dot11-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27075010.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 27 08:06:16 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB323A6B2E for ; Mon, 27 Oct 2008 08:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK8iGpyJdlGl for ; Mon, 27 Oct 2008 08:06:07 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 449723A67A1 for ; Mon, 27 Oct 2008 08:06:07 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2056A1C40F49 for ; Mon, 27 Oct 2008 08:06:07 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id B8D2E440006 for ; Mon, 27 Oct 2008 08:06:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 1C1E419EFE1 for ; Mon, 27 Oct 2008 08:06:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 3815E19EFB0 for ; Mon, 27 Oct 2008 08:05:59 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Sender first seen 3 mons 2 days 03:05:49 ago / dynamic or unknown reverse DNS) Received: from huawei-3com.com (unknown [221.12.31.56]) by mx3.tigertech.net (Postfix) with ESMTP for ; Mon, 27 Oct 2008 08:05:56 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K9E00MSVKLVPV@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 27 Oct 2008 23:05:55 +0800 (CST) Received: from huawei-3com.com ([172.25.15.135]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K9E00E2FKLUTC@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 27 Oct 2008 23:05:54 +0800 (CST) Received: from [172.25.15.126] (Forwarded-For: [221.221.236.177]) by h3cmc02-in.huawei-3com.com (mshttpd); Mon, 27 Oct 2008 23:14:02 +0800 Date: Mon, 27 Oct 2008 23:14:02 +0800 From: shiyang 00338 To: capwap@frascone.com Message-id: <2028ce201b43.201b432028ce@huawei-3com.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Cc: Yong Zhang , chris elliot Subject: [Capwap] The version 02 of MIB drafts were posted to the IETF repository today X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1917206671==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --===============1917206671== Content-type: text/html; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline

Hi,

The draft-ietf-capwap-802dot11-mib-02 and  draft-ietf-capwap-base-mib-02 were
posted to the IETF repository today.

For binding MIB, the main change is to update its format. Now, it is very stable.
For base MIB, we updated the access right of some MIB objects. As format in the
MIB definition section is inconsisent, we also updated document format.
For CAPWAP timer and variable MIB object, it requires some effort to update.
From now on, we will focus in the base MIB.

Regards

Richard

--===============1917206671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1917206671==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 27 08:21:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D69128C110 for ; Mon, 27 Oct 2008 08:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1EJ+lqY5VbF for ; Mon, 27 Oct 2008 08:21:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 591023A67A1 for ; Mon, 27 Oct 2008 08:21:01 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 27EF71C40F42 for ; Mon, 27 Oct 2008 08:21:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 2352D440006 for ; Mon, 27 Oct 2008 08:20:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0FD7D34AC5E3 for ; Mon, 27 Oct 2008 08:20:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id A5B1A34AC5E1 for ; Mon, 27 Oct 2008 08:20:54 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 27 Oct 2008 08:20:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,492,1220227200"; d="scan'208";a="183345434" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2008 15:20:53 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9RFKrOE032040; Mon, 27 Oct 2008 08:20:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9RFKrfX026476; Mon, 27 Oct 2008 15:20:53 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 08:20:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 08:20:53 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4905D50F.6010508@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Capwap] ECN support when tunneling user packets in CAPWAP thread-index: Ack4Q0qodl1TDjiYSpKPbJQJ3qqgnwABB4Jg References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> From: "Pat Calhoun (pacalhou)" To: "Magnus Westerlund" , "Margaret Wasserman" X-OriginalArrivalTime: 27 Oct 2008 15:20:52.0863 (UTC) FILETIME=[99A990F0:01C93847] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > Margaret Wasserman skrev: > > > > Hi Magnus, > > > > Just to make sure I understand... > > > > You are asking us to add a new optional message to CAPWAP that will > > enable "full functionality" ECN support (as described in 3168) on the > > CAPWAP data channel. The default behavior will remain the same as > > described in the current spec ("limited functionality" ECN), and it > > will be up to vendors who implement CAPWAP whether they implement the > > optional message in their products? If one end of the connection > > supports "full functionality" ECN and the other does not, the > > connection would continue to use the "limited functionality" mode. Is that correct? > > > Yes, but I would voice ECN support as recommend full functionality, but clearly allowed to do only limited. But otherwise correct. I continue to be confused with your position. A MUST is not a recommendation - it is a mandate. A SHOULD is a recommendation. Are you asking for a MUST or a SHOULD? PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 27 08:28:57 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DB928C180 for ; Mon, 27 Oct 2008 08:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.313 X-Spam-Level: X-Spam-Status: No, score=-4.313 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCoTPDiLw57L for ; Mon, 27 Oct 2008 08:28:56 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6870C28C14A for ; Mon, 27 Oct 2008 08:28:56 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 42C221C40F49 for ; Mon, 27 Oct 2008 08:28:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id C57C8440006 for ; Mon, 27 Oct 2008 08:28:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id B06B434AC5E1 for ; Mon, 27 Oct 2008 08:28:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EDAB034AC22E for ; Mon, 27 Oct 2008 08:28:49 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.62 whitelisted by list.dnswl.org 5.2) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 27 Oct 2008 08:28:49 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33C3421237; Mon, 27 Oct 2008 16:28:49 +0100 (CET) X-AuditID: c1b4fb3e-ac781bb00000537b-45-4905de31aaca Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 15DE220013; Mon, 27 Oct 2008 16:28:49 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 16:28:48 +0100 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 16:28:48 +0100 Message-ID: <4905DE30.6020609@ericsson.com> Date: Mon, 27 Oct 2008 16:28:48 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 27 Oct 2008 15:28:48.0394 (UTC) FILETIME=[B519D6A0:01C93848] X-Brightmail-Tracker: AAAAAA== Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun (pacalhou) skrev: >> Margaret Wasserman skrev: >>> Hi Magnus, >>> >>> Just to make sure I understand... >>> >>> You are asking us to add a new optional message to CAPWAP that will = >>> enable "full functionality" ECN support (as described in 3168) on > the = >>> CAPWAP data channel. The default behavior will remain the same as = >>> described in the current spec ("limited functionality" ECN), and it = >>> will be up to vendors who implement CAPWAP whether they implement > the = >>> optional message in their products? If one end of the connection = >>> supports "full functionality" ECN and the other does not, the = >>> connection would continue to use the "limited functionality" mode. > Is that correct? >> Yes, but I would voice ECN support as recommend full functionality, > but clearly allowed to do only limited. But otherwise correct. > = > I continue to be confused with your position. A MUST is not a > recommendation - it is a mandate. A SHOULD is a recommendation. Are you > asking for a MUST or a SHOULD? > = What I am suggesting is the following: CAPWAP AC and WTP SHALL implement limited functionality for ECN and is RECOMMENDED to implement full ECN functionality. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 27 09:08:38 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBC03A6AF6 for ; Mon, 27 Oct 2008 09:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgDxVYct-NmX for ; Mon, 27 Oct 2008 09:08:37 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2A2233A6A0E for ; Mon, 27 Oct 2008 09:08:37 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0019E1C40F3C for ; Mon, 27 Oct 2008 09:08:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id E015C440006 for ; Mon, 27 Oct 2008 09:07:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id C7BBE36100A3 for ; Mon, 27 Oct 2008 09:07:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 713753610097 for ; Mon, 27 Oct 2008 09:07:51 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.117 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.tigertech.net (Postfix) with ESMTP for ; Mon, 27 Oct 2008 09:07:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,492,1220227200"; d="scan'208";a="183375914" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2008 16:07:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9RG7pEq011197; Mon, 27 Oct 2008 09:07:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9RG7peg024852; Mon, 27 Oct 2008 16:07:51 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 09:07:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 09:07:50 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206B3956A@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4905DE30.6020609@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Capwap] ECN support when tunneling user packets in CAPWAP thread-index: Ack4SLd2A+aUjCrQTaSxqRgrOf+eJQABVnYg References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> <4905DE30.6020609@ericsson.com> From: "Pat Calhoun (pacalhou)" To: "Magnus Westerlund" X-OriginalArrivalTime: 27 Oct 2008 16:07:51.0085 (UTC) FILETIME=[29741DD0:01C9384E] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > Pat Calhoun (pacalhou) skrev: > >> Margaret Wasserman skrev: > >>> Hi Magnus, > >>> > >>> Just to make sure I understand... > >>> > >>> You are asking us to add a new optional message to CAPWAP that will > >>> enable "full functionality" ECN support (as described in 3168) on > > the > >>> CAPWAP data channel. The default behavior will remain the same as > >>> described in the current spec ("limited functionality" ECN), and it > >>> will be up to vendors who implement CAPWAP whether they implement > > the > >>> optional message in their products? If one end of the connection > >>> supports "full functionality" ECN and the other does not, the > >>> connection would continue to use the "limited functionality" mode. > > Is that correct? > >> Yes, but I would voice ECN support as recommend full functionality, > > but clearly allowed to do only limited. But otherwise correct. > > > > I continue to be confused with your position. A MUST is not a > > recommendation - it is a mandate. A SHOULD is a recommendation. Are > > you asking for a MUST or a SHOULD? > > > > What I am suggesting is the following: > > CAPWAP AC and WTP SHALL implement limited functionality for ECN and is RECOMMENDED to implement full ECN functionality. OK, how about: 4.5.2. Quality of Service [...] The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. CAPWAP AC and WTP SHALL implement limited functionality for ECN and is RECOMMENDED to implement full ECN functionality. In the "limited functionality option" is supported, when packets are encapsulated, the the ECN bits in the outer header are set to zero (0). Similarly, upon decapsulation, the receiver does not modify the ECN bits in the original station's packet header. In "full functionality option", during the encapsulation process, the original ECN bits are copied to the outer header. Similarly, the ECN bits of the outer header are copied to the inner header during the decapsulation process. PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 28 03:07:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815F53A69A6 for ; Tue, 28 Oct 2008 03:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.352 X-Spam-Level: X-Spam-Status: No, score=-4.352 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpfArLIGuLJ8 for ; Tue, 28 Oct 2008 03:07:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 128F83A67AF for ; Tue, 28 Oct 2008 03:07:52 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9E96C43027C for ; Tue, 28 Oct 2008 03:07:51 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 39982440006 for ; Tue, 28 Oct 2008 03:07:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 19D9519E37D for ; Tue, 28 Oct 2008 03:07:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 1158719E3A5 for ; Tue, 28 Oct 2008 03:07:42 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.60 whitelisted by list.dnswl.org 5.2) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 28 Oct 2008 03:07:42 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 32E5E20B64; Tue, 28 Oct 2008 11:07:40 +0100 (CET) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-f3-4906e46c86b9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0A021205CF; Tue, 28 Oct 2008 11:07:40 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 11:06:50 +0100 Received: from [147.214.183.48] ([147.214.183.48]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 11:06:43 +0100 Message-ID: <4906E433.9040700@ericsson.com> Date: Tue, 28 Oct 2008 11:06:43 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> <4905DE30.6020609@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B3956A@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206B3956A@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 28 Oct 2008 10:06:43.0218 (UTC) FILETIME=[E0CFBF20:01C938E4] X-Brightmail-Tracker: AAAAAA== Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] [Tsvwg] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun (pacalhou) skrev: >> Pat Calhoun (pacalhou) skrev: >>>> Margaret Wasserman skrev: >>>>> Hi Magnus, >>>>> >>>>> Just to make sure I understand... >>>>> >>>>> You are asking us to add a new optional message to CAPWAP that > will = >>>>> enable "full functionality" ECN support (as described in 3168) on >>> the >>>>> CAPWAP data channel. The default behavior will remain the same as > = >>>>> described in the current spec ("limited functionality" ECN), and > it = >>>>> will be up to vendors who implement CAPWAP whether they implement >>> the >>>>> optional message in their products? If one end of the connection = >>>>> supports "full functionality" ECN and the other does not, the = >>>>> connection would continue to use the "limited functionality" mode. >>> Is that correct? >>>> Yes, but I would voice ECN support as recommend full functionality, >>> but clearly allowed to do only limited. But otherwise correct. >>> >>> I continue to be confused with your position. A MUST is not a = >>> recommendation - it is a mandate. A SHOULD is a recommendation. Are = >>> you asking for a MUST or a SHOULD? >>> >> What I am suggesting is the following: >> >> CAPWAP AC and WTP SHALL implement limited functionality for ECN and is > RECOMMENDED to implement full ECN functionality. > = > OK, how about: > = > > 4.5.2. Quality of Service > [...] > The IP header also includes the Explicit Congestion Notification > (ECN) bits [RFC3168]. CAPWAP AC and WTP SHALL implement limited > functionality for ECN and is RECOMMENDED to implement full ECN > functionality. In the "limited functionality option" is supported, > when packets are encapsulated, the the ECN bits in the outer header > are set to zero (0). Similarly, upon decapsulation, the receiver > does not modify the ECN bits in the original station's packet header. > = > In "full functionality option", during the encapsulation process, the > original ECN bits are copied to the outer header. Similarly, the > ECN bits of the outer header are copied to the inner header during > the > decapsulation process. > > = Pat, I think the requirements text is fine. The summary what to do text is not correct for the full-functionality. I would simply leave a reference to section 9.1.1 in RFC 3168. The other part of the solution is how an ingress can learn what the egress is capable of. We do need something in Configuration status request and response message (seems most appropriate as this is what negotiate the transport also) that indicate the capabilities of the respective end-point in there function as egress. To me it seems a single bit is enough. ECN limited functionality only (0), Full and Limited functionality (1). You know your protocols best, please figure out where to best stick this information. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 28 09:02:02 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6F128C255 for ; Tue, 28 Oct 2008 09:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQwjlBBU5cJO for ; Tue, 28 Oct 2008 09:02:01 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5647728C1A7 for ; Tue, 28 Oct 2008 09:02:00 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D5AFC430E82 for ; Tue, 28 Oct 2008 09:01:59 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id A4528440006 for ; Tue, 28 Oct 2008 09:01:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 7165934AC458 for ; Tue, 28 Oct 2008 09:01:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 777BA34AC4C1 for ; Tue, 28 Oct 2008 09:01:51 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.68.10.87 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.tigertech.net (Postfix) with ESMTP for ; Tue, 28 Oct 2008 09:01:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,500,1220227200"; d="scan'208";a="50713965" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2008 16:01:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m9SG1oGJ023984; Tue, 28 Oct 2008 09:01:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9SG1oqC028090; Tue, 28 Oct 2008 16:01:50 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 09:01:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 09:01:49 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206B39A3C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4906E433.9040700@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Tsvwg] [Capwap] ECN support when tunneling user packets in CAPWAP thread-index: Ack45QdHHD3Sq5usTj2vOnUIlzwcnAAMFNVw References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> <4905DE30.6020609@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B3956A@xmb-sjc-235.amer.cisco.com> <4906E433.9040700@ericsson.com> From: "Pat Calhoun (pacalhou)" To: "Magnus Westerlund" X-OriginalArrivalTime: 28 Oct 2008 16:01:50.0773 (UTC) FILETIME=[7D1A9E50:01C93916] Authentication-Results: sj-dkim-3; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] [Tsvwg] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com > > OK, how about: > > > > > > 4.5.2. Quality of Service > > [...] > > The IP header also includes the Explicit Congestion Notification > > (ECN) bits [RFC3168]. CAPWAP AC and WTP SHALL implement limited > > functionality for ECN and is RECOMMENDED to implement full ECN > > functionality. In the "limited functionality option" is supported, > > when packets are encapsulated, the the ECN bits in the outer header > > are set to zero (0). Similarly, upon decapsulation, the receiver > > does not modify the ECN bits in the original station's packet header. > > > > In "full functionality option", during the encapsulation process, the > > original ECN bits are copied to the outer header. Similarly, the > > ECN bits of the outer header are copied to the inner header during > > the > > decapsulation process. > > > > > > Pat, I think the requirements text is fine. The summary what to do text is not correct for the full-functionality. I would simply leave a reference to section 9.1.1 in RFC 3168. > > The other part of the solution is how an ingress can learn what the egress is capable of. We do need something in Configuration status request and response message (seems most appropriate as this is what negotiate the transport also) that indicate the capabilities of the respective end-point in there function as egress. To me it seems a single bit is enough. ECN limited functionality only (0), Full and Limited functionality (1). > > You know your protocols best, please figure out where to best stick this information. OK, right - I omitted the control plane signalling part - my bad. How about: 4.5.2. Quality of Service [...] The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. CAPWAP AC and WTP SHALL implement limited functionality for ECN and is RECOMMENDED to implement full ECN functionality. Section 9.1.1 of [RFC3168] provides guidance on limited and full functionality for tunneling protocols. 4.6. CAPWAP Protocol Message Elements [...] ECN Support 53 4.6.25. ECN Support The ECN Support message element is sent by both the WTP and the AC to indicate their support for the Explicit Congestion Notification (ECN) bits, as defined in [RFC3168]. 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | ECN Support | +-+-+-+-+-+-+-+-+ Type: 53 for ECN Support Length: 1 ECN Support: An 8-bit value representing the sender's support for ECN, as defined in [RFC3168]. 0 - Limited ECN Support 1 - Full ECN Support 6.1. Join Request [...] The following message elements MUST be included in the Join Request message. [...] o ECN Support, see Section 4.6.25 6.2. Join Response [...] The following message elements MUST be included in the Join Response message. [...] o ECN Support, see Section 4.6.25 14. Transport Considerations [...] The CAPWAP protocol mandates support of the Explicit Congestion Notification (ECN) through a mode of operation named "limited functionality option", detailed in section 9.1.1 of [RFC3168]. Future versions of the CAPWAP protocol should consider mandating support for the "full functionality option". 15. IANA Considerations [...] 15.7. CAPWAP Message Element Type The Type field in the CAPWAP Message Element header (see Section 4.6) is used to identify the data being transported. The namespace is 16 bits (0-65535), where the value of zero (0) is reserved and must not be assigned. The values one (1) through 53 are allocated in this specification, and can be found in Section 4.5.1.1. [...] 15.16. ECN Support The ECN Support field in the ECN Support message element (see Section 4.6.25) is used by the WTP to represent its ECN Support. The namespace is 8 bits (0-255). The values zero (0) and one (1) are allocated in this specification, and can be found in Section 4.6.25. This namespace is managed by IANA and assignments require a Expert Review. IANA will create the ECN Support registry, whose format is: ECN Support Type Value Reference PatC _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 28 10:46:46 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428C328C33C for ; Tue, 28 Oct 2008 10:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOS-72ha2scW for ; Tue, 28 Oct 2008 10:46:41 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 7218E28C2BA for ; Tue, 28 Oct 2008 10:46:36 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EEAA1430246 for ; Tue, 28 Oct 2008 10:46:32 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 5566D440006 for ; Tue, 28 Oct 2008 10:46:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 3492B1CD485 for ; Tue, 28 Oct 2008 10:46:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 0A7FF1CD484 for ; Tue, 28 Oct 2008 10:46:26 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (64.170.98.32 whitelisted by list.dnswl.org 9.2) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 28 Oct 2008 10:46:25 -0700 (PDT) Received: by core3.amsl.com (Postfix, from userid 30) id 931B228C335; Tue, 28 Oct 2008 10:45:30 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20081028174530.931B228C335@core3.amsl.com> Date: Tue, 28 Oct 2008 10:45:30 -0700 (PDT) Cc: capwap chair , Internet Architecture Board , capwap mailing list , RFC Editor Subject: [Capwap] Protocol Action: 'CAPWAP Access Controller DHCP Option' to Proposed Standard X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com The IESG has approved the following document: - 'CAPWAP Access Controller DHCP Option ' as a Proposed Standard This document is the product of the Control And Provisioning of Wireless Access Points Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-dhc-ac-option-02.txt Technical Summary The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers it is to connect to. This document describes the DHCP options to be used by the CAPWAP protocol. Working Group Summary This document is a work item of the CAPWAP WG and respresents the consensus of the group. Document Quality This document was reviewed within the CAPWAP WG and no issues were raised in WG Last Call. Francis Dupont reviewed it for the GenART and Dan Romascanu performed the OPS Area Director review. Personnel Margaret Wasserman is the document shepherd and Dan Romascanu is the responsible AD. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 28 13:33:07 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1871228C275 for ; Tue, 28 Oct 2008 13:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.924 X-Spam-Level: X-Spam-Status: No, score=-4.924 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0XBEHQN+kxY for ; Tue, 28 Oct 2008 13:33:06 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 3642A3A6C00 for ; Tue, 28 Oct 2008 13:33:03 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CB824430214 for ; Tue, 28 Oct 2008 13:33:02 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 72EB9440006 for ; Tue, 28 Oct 2008 13:32:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 582951CD48A for ; Tue, 28 Oct 2008 13:32:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 953AC1CD489 for ; Tue, 28 Oct 2008 13:32:53 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (193.180.251.62 whitelisted by list.dnswl.org 5.2) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 28 Oct 2008 13:32:53 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31CA220994; Tue, 28 Oct 2008 21:30:28 +0100 (CET) X-AuditID: c1b4fb3e-aef86bb00000537b-30-490776648354 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 09813200F5; Tue, 28 Oct 2008 21:30:28 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:30:20 +0100 Received: from [153.88.53.51] ([153.88.53.51]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Oct 2008 21:30:20 +0100 Message-ID: <4907765B.6050406@ericsson.com> Date: Tue, 28 Oct 2008 21:30:19 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> <4905DE30.6020609@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B3956A@xmb-sjc-235.amer.cisco.com> <4906E433.9040700@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39A3C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206B39A3C@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 28 Oct 2008 20:30:20.0111 (UTC) FILETIME=[FF0485F0:01C9393B] X-Brightmail-Tracker: AAAAAA== Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] [Tsvwg] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Pat Calhoun (pacalhou) skrev: > = > OK, right - I omitted the control plane signalling part - my bad. How > about: Looks mostly okay, see inline below. Thanks for the quick work. I would appreciate if some people from the capwap WG also did indicate that it looks okay from a capwap perspective. > = > > 4.5.2. Quality of Service > [...] > = > The IP header also includes the Explicit Congestion Notification > (ECN) bits [RFC3168]. CAPWAP AC and WTP SHALL implement limited > functionality for ECN and is RECOMMENDED to implement full ECN > functionality. Section 9.1.1 of [RFC3168] provides guidance on > limited and full functionality for tunneling protocols. > = > 4.6. CAPWAP Protocol Message Elements > [...] > ECN Support 53 > = > 4.6.25. ECN Support > = > The ECN Support message element is sent by both the WTP and the AC to > indicate their support for the Explicit Congestion Notification (ECN) > bits, as defined in [RFC3168]. > = > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | ECN Support | > +-+-+-+-+-+-+-+-+ > = > Type: 53 for ECN Support > = > Length: 1 > = > ECN Support: An 8-bit value representing the sender's support for > ECN, as defined in [RFC3168]. > = > 0 - Limited ECN Support > = > 1 - Full ECN Support I think 1 should be "Full and Limited ECN support". > = > 6.1. Join Request > [...] > The following message elements MUST be included in the Join Request > message. > [...] > o ECN Support, see Section 4.6.25 > = > 6.2. Join Response > [...] > The following message elements MUST be included in the Join Response > message. > [...] > o ECN Support, see Section 4.6.25 > = > 14. Transport Considerations > [...] > The CAPWAP protocol mandates support of the Explicit Congestion > Notification (ECN) through a mode of operation named "limited > functionality option", detailed in section 9.1.1 of [RFC3168]. > Future versions of the CAPWAP protocol should consider mandating > support for the "full functionality option". > = > 15. IANA Considerations > [...] > 15.7. CAPWAP Message Element Type > = > The Type field in the CAPWAP Message Element header (see Section 4.6) > is used to identify the data being transported. The namespace is 16 > bits (0-65535), where the value of zero (0) is reserved and must not > be assigned. The values one (1) through 53 are allocated in this > specification, and can be found in Section 4.5.1.1. > = > [...] > 15.16. ECN Support > = > The ECN Support field in the ECN Support message element (see > Section 4.6.25) is used by the WTP to represent its ECN Support. The > namespace is 8 bits (0-255). The values zero (0) and one (1) are > allocated in this specification, and can be found in Section 4.6.25. > This namespace is managed by IANA and assignments require a Expert > Review. IANA will create the ECN Support registry, whose format is: > = > ECN Support Type Value Reference > > = > PatC > = Thanks Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 28 13:34:23 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9863A6C00 for ; Tue, 28 Oct 2008 13:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWmcdCAZ7WJ4 for ; Tue, 28 Oct 2008 13:34:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 06DBD3A6C7F for ; Tue, 28 Oct 2008 13:34:23 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A209243028A for ; Tue, 28 Oct 2008 13:34:22 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 16C23440006 for ; Tue, 28 Oct 2008 13:34:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 08EE11CD485 for ; Tue, 28 Oct 2008 13:34:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 2AFDA1CD489 for ; Tue, 28 Oct 2008 13:34:14 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by mx3.tigertech.net (Postfix) with ESMTP for ; Tue, 28 Oct 2008 13:34:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,501,1220241600"; d="scan'208";a="140171889" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 28 Oct 2008 16:34:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Oct 2008 16:34:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Oct 2008 21:34:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Protocol Action: 'CAPWAP Access Controller DHCP Option' to Proposed Standard Thread-Index: Ack5JSFb5iYGrfsVS9imXTS9ZbwEJwAFzsiw From: "Romascanu, Dan (Dan)" To: Subject: [Capwap] FW: Protocol Action: 'CAPWAP Access Controller DHCP Option' to Proposed Standard X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Congratulations to the editor, contributors, chairs and to the whole Working Group for the approval of this document. Regards, Dan -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Tuesday, October 28, 2008 7:46 PM To: IETF-Announce Cc: capwap chair; Internet Architecture Board; capwap mailing list; RFC Editor Subject: [Capwap] Protocol Action: 'CAPWAP Access Controller DHCP Option' to Proposed Standard The IESG has approved the following document: - 'CAPWAP Access Controller DHCP Option ' as a Proposed Standard This document is the product of the Control And Provisioning of Wireless Access Points Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-dhc-ac-option-02.t xt Technical Summary The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers it is to connect to. This document describes the DHCP options to be used by the CAPWAP protocol. Working Group Summary This document is a work item of the CAPWAP WG and respresents the consensus of the group. Document Quality This document was reviewed within the CAPWAP WG and no issues were raised in WG Last Call. Francis Dupont reviewed it for the GenART and Dan Romascanu performed the OPS Area Director review. Personnel Margaret Wasserman is the document shepherd and Dan Romascanu is the responsible AD. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 29 10:59:56 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E683A6B09 for ; Wed, 29 Oct 2008 10:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22hkRLNdi3Ew for ; Wed, 29 Oct 2008 10:59:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6B3A63A680C for ; Wed, 29 Oct 2008 10:59:55 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 93E7743044C for ; Wed, 29 Oct 2008 10:59:39 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id 3006C440006 for ; Wed, 29 Oct 2008 10:59:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 0619F19FBDD for ; Wed, 29 Oct 2008 10:59:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 3D8CE19F9F3 for ; Wed, 29 Oct 2008 10:59:30 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx3.tigertech.net (Postfix) with ESMTP for ; Wed, 29 Oct 2008 10:59:29 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Ybla1a0070xGWP855hzU8Q; Wed, 29 Oct 2008 17:59:28 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA12.westchester.pa.mail.comcast.net with comcast id YhzB1a0061cMU3H3YhzDn0; Wed, 29 Oct 2008 17:59:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=Xc_tSRSJdFQA:10 a=T7Mncx4BXDMA:10 a=ZdzAMXKZgeN9Iy8-coMA:9 a=maAvcWpK45Mtx9a-T8gA:7 a=ifASq-NTl_xTJSZLYJ6_-E9_ZEQA:4 a=f7GxY0FH8QIA:10 a=WuK_CZDBSqoA:10 Message-Id: <7E12349B-C5DB-48C6-9AD3-A41A4B99347A@lilacglade.org> From: Margaret Wasserman To: Magnus Westerlund In-Reply-To: <4907765B.6050406@ericsson.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 29 Oct 2008 13:59:09 -0400 References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> <4905DE30.6020609@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B3956A@xmb-sjc-235.amer.cisco.com> <4906E433.9040700@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39A3C@xmb-sjc-235.amer.cisco.com> <4907765B.6050406@ericsson.com> X-Mailer: Apple Mail (2.929.2) Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] [Tsvwg] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com On Oct 28, 2008, at 4:30 PM, Magnus Westerlund wrote: > Pat Calhoun (pacalhou) skrev: >> >> OK, right - I omitted the control plane signalling part - my bad. How >> about: > > Looks mostly okay, see inline below. Thanks for the quick work. I = > would > appreciate if some people from the capwap WG also did indicate that it > looks okay from a capwap perspective. Hi Magnus. We will do a 1 week call for comments on these changes = with the WG once they are finalized and a new draft is available, and = before it is published. Personally, I think this looks fine from a CAPWAP perspective, and I = hope others will comment as well. > >> >> >> 4.5.2. Quality of Service >> [...] >> >> The IP header also includes the Explicit Congestion Notification >> (ECN) bits [RFC3168]. CAPWAP AC and WTP SHALL implement limited >> functionality for ECN and is RECOMMENDED to implement full ECN >> functionality. Section 9.1.1 of [RFC3168] provides guidance on >> limited and full functionality for tunneling protocols. >> >> 4.6. CAPWAP Protocol Message Elements >> [...] >> ECN Support 53 >> >> 4.6.25. ECN Support >> >> The ECN Support message element is sent by both the WTP and the = >> AC to >> indicate their support for the Explicit Congestion Notification = >> (ECN) >> bits, as defined in [RFC3168]. >> >> 0 >> 0 1 2 3 4 5 6 7 >> +-+-+-+-+-+-+-+-+ >> | ECN Support | >> +-+-+-+-+-+-+-+-+ >> >> Type: 53 for ECN Support >> >> Length: 1 >> >> ECN Support: An 8-bit value representing the sender's support for >> ECN, as defined in [RFC3168]. >> >> 0 - Limited ECN Support >> >> 1 - Full ECN Support > > I think 1 should be "Full and Limited ECN support". > > > >> >> 6.1. Join Request >> [...] >> The following message elements MUST be included in the Join Request >> message. >> [...] >> o ECN Support, see Section 4.6.25 >> >> 6.2. Join Response >> [...] >> The following message elements MUST be included in the Join = >> Response >> message. >> [...] >> o ECN Support, see Section 4.6.25 >> >> 14. Transport Considerations >> [...] >> The CAPWAP protocol mandates support of the Explicit Congestion >> Notification (ECN) through a mode of operation named "limited >> functionality option", detailed in section 9.1.1 of [RFC3168]. >> Future versions of the CAPWAP protocol should consider mandating >> support for the "full functionality option". >> >> 15. IANA Considerations >> [...] >> 15.7. CAPWAP Message Element Type >> >> The Type field in the CAPWAP Message Element header (see Section = >> 4.6) >> is used to identify the data being transported. The namespace is = >> 16 >> bits (0-65535), where the value of zero (0) is reserved and must = >> not >> be assigned. The values one (1) through 53 are allocated in this >> specification, and can be found in Section 4.5.1.1. >> >> [...] >> 15.16. ECN Support >> >> The ECN Support field in the ECN Support message element (see >> Section 4.6.25) is used by the WTP to represent its ECN Support. = >> The >> namespace is 8 bits (0-255). The values zero (0) and one (1) are >> allocated in this specification, and can be found in Section = >> 4.6.25. >> This namespace is managed by IANA and assignments require a Expert >> Review. IANA will create the ECN Support registry, whose format = >> is: >> >> ECN Support Type Value Reference >> >> >> PatC >> > > Thanks > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 29 11:05:43 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0003A6CB7 for ; Wed, 29 Oct 2008 11:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iX0SCBhMafL for ; Wed, 29 Oct 2008 11:05:42 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 232893A6D4D for ; Wed, 29 Oct 2008 11:05:38 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 70BE1430420 for ; Wed, 29 Oct 2008 11:05:22 -0700 (PDT) Received: from mx3.tigertech.net (mx3.tigertech.net [64.62.209.33]) by mx2.tigertech.net (Postfix) with ESMTP id E44CA440006 for ; Wed, 29 Oct 2008 11:05:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id CA37E19FC29 for ; Wed, 29 Oct 2008 11:05:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 7C4FB19FC27 for ; Wed, 29 Oct 2008 11:05:15 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 1 (Low) (P0); Accepted (Neutral) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx3.tigertech.net (Postfix) with ESMTP for ; Wed, 29 Oct 2008 11:05:15 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id YcxE1a00F0lTkoCA4i5FsQ; Wed, 29 Oct 2008 18:05:15 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id Yi4w1a00P1cMU3H8Qi4z8B; Wed, 29 Oct 2008 18:05:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=Xc_tSRSJdFQA:10 a=T7Mncx4BXDMA:10 a=jRYtBqz34jt-1QnN4z4A:9 a=7Z0-Ru4-xGTPr0yc8K5mTqnvjyMA:4 a=I2EqgwFF2xUA:10 Message-Id: From: Margaret Wasserman To: Pat Calhoun (pacalhou) In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A206B39A3C@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 29 Oct 2008 14:04:54 -0400 References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> <4905DE30.6020609@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B3956A@xmb-sjc-235.amer.cisco.com> <4906E433.9040700@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39A3C@xmb-sjc-235.amer.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] [Tsvwg] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com I'm okay with this change in general, as I indicated in my last message. I do think some minor editing is needed for grammar, though, details in-line: On Oct 28, 2008, at 12:01 PM, Pat Calhoun (pacalhou) wrote: > > 4.5.2. Quality of Service > [...] > > The IP header also includes the Explicit Congestion Notification > (ECN) bits [RFC3168]. CAPWAP AC and WTP SHALL implement limited > functionality for ECN and is RECOMMENDED to implement full ECN > functionality. Section 9.1.1 of [RFC3168] provides guidance on > limited and full functionality for tunneling protocols. The second sentence is not quite right grammatically... How about changing these this paragraph to: The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. Section 9.1.1 of RFC3168 describes two levels of ECN functionality, full functionality and limited functionality. CAPWAP ACs and WTPs SHALL implement the limited functionality and are RECOMMENDED to implement the full functionality described in RFC3168. > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 29 11:30:04 2008 Return-Path: X-Original-To: ietfarch-capwap-archive@core3.amsl.com Delivered-To: ietfarch-capwap-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0128528C3D1 for ; Wed, 29 Oct 2008 11:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.456 X-Spam-Level: X-Spam-Status: No, score=-4.456 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIIfBIt1gdiX for ; Wed, 29 Oct 2008 11:30:03 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 350B528C3CA for ; Wed, 29 Oct 2008 11:30:03 -0700 (PDT) Received: from hermes.tigertech.net (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AA81C430486 for ; Wed, 29 Oct 2008 11:29:58 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by mx2.tigertech.net (Postfix) with ESMTP id 82D0B440006 for ; Wed, 29 Oct 2008 11:29:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 69B2834ACEC8 for ; Wed, 29 Oct 2008 11:29:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 18AAB34ACEC7 for ; Wed, 29 Oct 2008 11:29:53 -0700 (PDT) X-TigerTech-Content-Filter: Clean X-TigerTech-Spam-Status: Level 0 (Low) (P0); Whitelisted TTSSA (171.71.176.70 whitelisted by list.dnswl.org 9.2) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by mx1.tigertech.net (Postfix) with ESMTP for ; Wed, 29 Oct 2008 11:29:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,507,1220227200"; d="scan'208";a="97651001" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2008 18:29:52 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9TITqAF003711; Wed, 29 Oct 2008 11:29:52 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m9TITp9E011182; Wed, 29 Oct 2008 18:29:52 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 11:29:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Oct 2008 11:28:15 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A206BB03FC@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Tsvwg] [Capwap] ECN support when tunneling user packets in CAPWAP thread-index: Ack58OVtsdIaFSQmQ6CW4kAvdcwSfAAAynIw References: <48F5B9A3.1040502@ericsson.com><0AC25B27A4FD2E4B839C9FAF2C704DBA03CFAC52@daebe103.NOE.Nokia.com><48FDA02C.8080506@ericsson.com><1266DDA7-B353-457E-86D0-CD032BCECADA@lilacglade.org><48FF41CF.5060904@ericsson.com><49003871.5010301@ericsson.com><45DB0AD0-0BC0-4C9B-8A4B-3FDC496D5BC1@lilacglade.org> <4905D50F.6010508@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39525@xmb-sjc-235.amer.cisco.com> <4905DE30.6020609@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B3956A@xmb-sjc-235.amer.cisco.com> <4906E433.9040700@ericsson.com> <4FF84B0BC277FF45AA27FE969DD956A206B39A3C@xmb-sjc-235.amer.cisco.com> From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 29 Oct 2008 18:29:50.0885 (UTC) FILETIME=[5479ED50:01C939F4] Authentication-Results: sj-dkim-1; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: capwap@frascone.com, Dorothy.Gellert@nokia.com, tsvwg@ietf.org Subject: Re: [Capwap] [Tsvwg] ECN support when tunneling user packets in CAPWAP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Done, I will resubmit the drafts today and we can start the 1 week WG Last Call. OK? PatC -----Original Message----- From: Margaret Wasserman [mailto:mrw@lilacglade.org] Sent: Wednesday, October 29, 2008 11:05 AM To: Pat Calhoun (pacalhou) Cc: Magnus Westerlund; capwap@frascone.com; Dorothy.Gellert@nokia.com; tsvwg@ietf.org Subject: Re: [Tsvwg] [Capwap] ECN support when tunneling user packets in CAPWAP I'm okay with this change in general, as I indicated in my last message. I do think some minor editing is needed for grammar, though, details in-line: On Oct 28, 2008, at 12:01 PM, Pat Calhoun (pacalhou) wrote: > > 4.5.2. Quality of Service > [...] > > The IP header also includes the Explicit Congestion Notification > (ECN) bits [RFC3168]. CAPWAP AC and WTP SHALL implement limited > functionality for ECN and is RECOMMENDED to implement full ECN > functionality. Section 9.1.1 of [RFC3168] provides guidance on > limited and full functionality for tunneling protocols. The second sentence is not quite right grammatically... How about changing these this paragraph to: The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. Section 9.1.1 of RFC3168 describes two levels of ECN functionality, full functionality and limited functionality. CAPWAP ACs and WTPs SHALL implement the limited functionality and are RECOMMENDED to implement the full functionality described in RFC3168. > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap