From melinda.shore@gmail.com Mon Jul 1 12:45:44 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F398B11E8240 for ; Mon, 1 Jul 2013 12:45:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaJaTrSnA5Wb for ; Mon, 1 Jul 2013 12:45:43 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF7521F9A15 for ; Mon, 1 Jul 2013 12:45:43 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so2914898pdi.41 for ; Mon, 01 Jul 2013 12:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=IgXvJCTfQkT2MP0FNSlTtI61U+aeErNV++AJJ5eY+Jk=; b=C7ckZclj/Q0aDEkzBKXvnoAPLGmCcc9guBov0j8OqIARfa7RasDJsVnGQKwiIpzxGV uhm9KSIx+96aWYSttKfYIIT5JO/3Q1rC4PoqE3yyFCehdViPoaAUcC5NVTzn9c6NRjPF KKqRHz5XCxFkCu5WLa2AASZyjdWVnqGZxIp/AYLT+NKdvQmKpECmKyqbb1M1PrCB1hDW aSaJBulIWilgCGy++Lt0Q/8tBEYjRoHSkfw4zL3Ar9HYHzRhtGnsUIOspylBOVZYC+pY mT1k9zwMnEob3yJgQ+LwE0JNglY1B1KauY0+j7/2dT5zvQe1DuVgqmTRT8YtD/9h4HNP 5Kxg== X-Received: by 10.66.155.102 with SMTP id vv6mr25748195pab.60.1372707943242; Mon, 01 Jul 2013 12:45:43 -0700 (PDT) Received: from spandex.local (216-67-47-248-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.47.248]) by mx.google.com with ESMTPSA id eq5sm23692825pbc.15.2013.07.01.12.45.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 12:45:42 -0700 (PDT) Message-ID: <51D1DC64.5050509@gmail.com> Date: Mon, 01 Jul 2013 11:45:40 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <20130701193936.10181.90437.idtracker@ietfa.amsl.com> In-Reply-To: <20130701193936.10181.90437.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130701193936.10181.90437.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: IETF Mentor Program X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:45:44 -0000 The IETF is experimenting with a new mentoring program. If you're a long-time IETF participant and are nomcom-eligible, please give some thought to volunteering to be a mentor. If you're a new IETF participant (you've attended fewer than three meetings), please consider asking to be paired with a mentor. If this works out it could be an excellent mechanism for helping newer participants be more successful in the IETF. Melinda -------- Original Message -------- Subject: IETF Mentor Program Date: Mon, 01 Jul 2013 12:39:36 -0700 From: IETF Chair Reply-To: ietf@ietf.org To: IETF Announcement List Hi all, Based on discussions during IETF 86, we are trialing an IETF mentoring program. During this trial period, we would like to pair newcomers (people who have attended 3 or fewer meetings or have registered as students) with existing IETF participants. The goal is to provide a resource for the newcomer who can assist them with integrating into the IETF community. Mentors and newcomers will be paired prior to IETF 87. What we need is for people to volunteer to be mentors. As a mentor, we would ask that you be willing to assist your mentoring participant before, during, and (hopefully) after IETF 87. The actual level of interaction will be driven by an agreement between the mentor and the mentoring participant. Additionally, we would need a brief description of your areas of expertise, technical interests, and conversational languages. A description of the Mentor Program (including a FAQ describing how to volunteer to be a mentor) is available: http://www.ietf.org/resources/mentoring-program.html. Anyone interested in being a mentor should follow the sign-up instructions contained in the above URL. The more volunteers we have, the stronger the program will be! Regards, IETF Chair From panda@hongo.wide.ad.jp Tue Jul 2 21:33:18 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF6C11E8168 for ; Tue, 2 Jul 2013 21:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i4za77EEvzh for ; Tue, 2 Jul 2013 21:33:14 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id F371B11E8166 for ; Tue, 2 Jul 2013 21:33:13 -0700 (PDT) Received: from [157.82.4.171] (unknown [157.82.4.171]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 230FF108DE5F; Wed, 3 Jul 2013 13:32:19 +0900 (JST) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hirochika Asai Date: Wed, 3 Jul 2013 13:33:10 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130702151434.833.9587.idtracker@ietfa.amsl.com> To: "opsawg@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: [OPSAWG] Fwd: New Version Notification for draft-asai-vmm-mib-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 04:33:18 -0000 Dear all, Thanks to Randy Presuhn and David Black for providing helpful comments on this mailing list, we have submitted the new version of our MIB proposal for virtual machines controlled by a hypervisor: http://tools.ietf.org/html/draft-asai-vmm-mib-04 The main difference from the previous version is the notification part that has been discussed in this mailing list. We would like you to review this version of I-D. Thank you. Hirochika Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-asai-vmm-mib-04.txt > Date: July 3, 2013 12:14:34 AM GMT+09:00 > To: Yuji Sekiya , Cathy Zhou = , Tina Tsou , = Keiichi Shima , Juergen Schoenwaelder = , Michael MacFaden = , Hirochika Asai , Hiroshi Esaki = >=20 >=20 > A new version of I-D, draft-asai-vmm-mib-04.txt > has been successfully submitted by Hirochika Asai and posted to the > IETF repository. >=20 > Filename: draft-asai-vmm-mib > Revision: 04 > Title: Management Information Base for Virtual = Machines Controlled by a Hypervisor > Creation date: 2013-07-03 > Group: Individual Submission > Number of pages: 49 > URL: = http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-04.txt > Status: http://datatracker.ietf.org/doc/draft-asai-vmm-mib > Htmlized: http://tools.ietf.org/html/draft-asai-vmm-mib-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-asai-vmm-mib-04 >=20 > Abstract: > This document defines a portion of the Management Information Base > (MIB) for use with network management protocols in the Internet > community. In particular, this specifies objects for managing > virtual machines controlled by a hypervisor (a.k.a. virtual machine > manager). >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 --=20 Hirochika Asai , The University of Tokyo From Jean-Francois.TremblayING@videotron.com Thu Jul 4 11:52:47 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5AD11E80F2 for ; Thu, 4 Jul 2013 11:52:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aPhYOMWqD9A for ; Thu, 4 Jul 2013 11:52:42 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1EA11E8186 for ; Thu, 4 Jul 2013 11:52:39 -0700 (PDT) In-Reply-To: <51CC91E0.3020002@gmail.com> References: <20130627192119.11177.56159.idtracker@ietfa.amsl.com> <51CC91E0.3020002@gmail.com> To: "opsawg@ietf.org" MIME-Version: 1.0 X-KeepSent: D4522C96:9613985B-85257B9E:00662C10; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP1 March 08, 2012 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Thu, 4 Jul 2013 14:52:36 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP3|November 15, 2012) at 07/04/2013 14:52:39, Serialize complete at 07/04/2013 14:52:39 Content-Type: text/plain; charset="US-ASCII" Received-SPF: none Subject: Re: [OPSAWG] Fwd: I-D Action: draft-ietf-opsawg-lsn-deployment-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 18:52:47 -0000 > As we discussed at the last meeting, we'd like to move this > version towards working group last call. Please give this > a read with that in mind, and provide feedback to the mailing > list. > > Melinda Beside two small differences (in 4. and 4.2, concerning RDs and IPv6 trafic flow), this draft accurately describes a CGN deployment model that has been tested in production at Videotron (a Canadian cable ISP). This could be considered a second running deployment for this model. As an operator, I find it useful to see such a framework documented properly. It facilitates information sharing internally, between operators and with implementors of CGN technologies. +1 in favor of WGLC. /JF From fanpeng@chinamobile.com Fri Jul 5 07:51:15 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B78F11E82FC for ; Fri, 5 Jul 2013 07:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uZzdM4WilkX for ; Fri, 5 Jul 2013 07:51:10 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 8123411E82E8 for ; Fri, 5 Jul 2013 07:51:09 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee251d6dd27419-fc419; Fri, 05 Jul 2013 22:50:15 +0800 (CST) X-RM-TRANSID: 2ee251d6dd27419-fc419 Received: from X6X8D79D8F49E2 (unknown[125.97.241.144]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee351d6dd2293e-2eaaa; Fri, 05 Jul 2013 22:50:15 +0800 (CST) X-RM-TRANSID: 2ee351d6dd2293e-2eaaa From: "Fan Peng" To: Date: Fri, 5 Jul 2013 22:55:58 +0800 Message-ID: <009901ce798f$c39243b0$4ab6cb10$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac55iWvw4ki8XM1uTqaaMMRB/yWpzA== Content-Language: zh-cn Subject: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 14:51:15 -0000 Dear all, We have updated a complete revision to the I-D regarding packet loss = measurement , and would like to get feedback from you: IP Packet Loss Rate Measurement Testing and Problem Statement http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01 The document aims to review methods for packet loss rate measurement and = problems with them, and provide some guidelines when performing the = measurement. The document is based on operational experience and needs = especially when doing performance monitoring on the interconnecting link = between two providers' networks. We also hope we can find after the = discussion a measurement scheme that is convenient enough and provides = consistent results. Any comment would be appreciated. Thank you! Regards, Peng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B47=E6=9C=885=E6=97=A5 = 21:44 =E6=94=B6=E4=BB=B6=E4=BA=BA: Peng Fan; Mach Chen; Lu Huang; Mach (Guoyi) = Chen; Nagendra Kumar =E4=B8=BB=E9=A2=98: New Version Notification for = draft-fan-opsawg-packet-loss-01.txt A new version of I-D, draft-fan-opsawg-packet-loss-01.txt has been successfully submitted by Peng Fan and posted to the IETF = repository. Filename: draft-fan-opsawg-packet-loss Revision: 01 Title: IP Packet Loss Rate Measurement Testing and Problem Statement Creation date: 2013-07-05 Group: Individual Submission Number of pages: 15 URL: = http://www.ietf.org/internet-drafts/draft-fan-opsawg-packet-loss-01.txt Status: = http://datatracker.ietf.org/doc/draft-fan-opsawg-packet-loss Htmlized: = http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-fan-opsawg-packet-loss-01 Abstract: This document describes common methods for measuring packet loss rate and their effectiveness. Issues encountered when using the methods and necessary considerations are also discussed and recommended. = =20 The IETF Secretariat From toms.sanders@gmail.com Mon Jul 8 08:33:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D3421F9CFF for ; Mon, 8 Jul 2013 08:33:26 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnFCZ4hVgf1w for ; Mon, 8 Jul 2013 08:33:26 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 49A0421F9130 for ; Mon, 8 Jul 2013 08:33:26 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w11so4157690pde.23 for ; Mon, 08 Jul 2013 08:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CuC1jVsPa6mbDWh8qhG+gv/D1W95JM0oNgvKYZZYUCI=; b=UZOGJ6M14Dk+dTWxS+azmb7ajN0gMAs4DdBYSfT+aZBarKuAhadp/D+Xx2pw/XmFjo u9cfh5u/6uunA0qpKFthslLatXkAFW50R8oR0IQyWDQ3IOtSIplmyYCvxVfCby5i5Ek5 luAPmc6J90l8emS4QB/1p3DNfZIlesyWSt2775nzyZNGEj8Le/PUgEpAV1iWLDbvtpzG UYyK+3dzSJ4wb/+kKeQ02vnUAx9rhNoBLM+iLtZftE0kv0q/jnW4/pzmuFgkiyZJCnBU QYLWsABPnJ4MjicFl5vtZb6PgM2ueiGE81qFj/SdWtYfS6hthbYIWHvF0F8pF2nq38AG ZAZw== MIME-Version: 1.0 X-Received: by 10.68.221.69 with SMTP id qc5mr21891814pbc.60.1373297605801; Mon, 08 Jul 2013 08:33:25 -0700 (PDT) Received: by 10.68.226.38 with HTTP; Mon, 8 Jul 2013 08:33:25 -0700 (PDT) Date: Mon, 8 Jul 2013 21:03:25 +0530 Message-ID: From: Tom Sanders To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=047d7b2ee61df6fb7304e101c362 Subject: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:33:27 -0000 --047d7b2ee61df6fb7304e101c362 Content-Type: text/plain; charset=UTF-8 Hi, I know that we dont have a setbulk operation in SNMP. Am just wondering as to why it isnt there. Is there a reason why we only have a getbulk PDU and not a setbulk PDU? Will not having a SETBULK PDU speed up configs as we dont have to set multiple SET PDUs. -- Toms. --047d7b2ee61df6fb7304e101c362 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I know that we dont have a setbulk = operation in SNMP. Am just wondering as to why it isnt there. Is there a re= ason why we only have a getbulk PDU and not a setbulk PDU? Will not having = a SETBULK PDU speed up configs as we dont have to set multiple SET PDUs.

--
Toms.
--047d7b2ee61df6fb7304e101c362-- From mrm@vmware.com Mon Jul 8 08:55:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2458421F9D2A for ; Mon, 8 Jul 2013 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0wD+vrdxMNr for ; Mon, 8 Jul 2013 08:55:28 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2398521F8F24 for ; Mon, 8 Jul 2013 08:55:28 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 831D128588; Mon, 8 Jul 2013 08:55:27 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 782BC403E0; Mon, 8 Jul 2013 08:55:27 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id 66D3BE004C; Mon, 8 Jul 2013 08:55:27 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Mon, 8 Jul 2013 08:55:27 -0700 (PDT) Date: Mon, 8 Jul 2013 08:55:27 -0700 (PDT) From: Michael MacFaden To: Tom Sanders Message-ID: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17596467_1144560069.1373298927136" X-Originating-IP: [10.113.163.68] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: SNMP SetBulk Operat Thread-Index: LgcF2xgv3PG/kDQj9Y4CjHq4kuBVZQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:55:33 -0000 ------=_Part_17596467_1144560069.1373298927136 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > I know that we dont have a setbulk operation in SNMP. Am just wondering as to > why it isnt there. Is there a reason why we only have a getbulk PDU and not > a setbulk PDU? Will not having a SETBULK PDU speed up configs as we dont > have to set multiple SET PDUs. Yet message size would still limited udp transport. Reminds me of the apple airport mgmt interface for config, recall it used snmp set with one very large octet string. Anyway standardization efforts have long since focused what operators thought would be a more acceptable approach, ...doing config with NETCONF. Mike ------=_Part_17596467_1144560069.1373298927136 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I k= now that we dont have a setbulk operation in SNMP. Am just wondering as to = why it isnt there. Is there a reason why we only have a getbulk PDU and not= a setbulk PDU? Will not having a SETBULK PDU speed up configs as we dont h= ave to set multiple SET PDUs.
Yet message size would still limited udp transport.
Reminds me of the apple a= irport mgmt interface for config,
recall it used snmp set with one very large octet string.

Anyway&= nbsp;standardization efforts have l= ong since focused
what op= erators thought would be a more acceptable approach,
...doing config with NETCONF.


Mike

------=_Part_17596467_1144560069.1373298927136-- From ietfdbh@comcast.net Mon Jul 8 09:00:12 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D84F21F9104 for ; Mon, 8 Jul 2013 09:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.377 X-Spam-Level: X-Spam-Status: No, score=-100.377 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i88kpYa6iLc6 for ; Mon, 8 Jul 2013 09:00:06 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 00C4121F9005 for ; Mon, 8 Jul 2013 09:00:05 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id xnkU1l00317dt5G56s05kS; Mon, 08 Jul 2013 16:00:05 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta13.westchester.pa.mail.comcast.net with comcast id xs041l01H2yZEBF3Zs04zb; Mon, 08 Jul 2013 16:00:05 +0000 From: "ietfdbh" To: "'Michael MacFaden'" , "'Tom Sanders'" References: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> In-Reply-To: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> Date: Mon, 8 Jul 2013 11:59:34 -0400 Message-ID: <005a01ce7bf4$246f6580$6d4e3080$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01CE7BD2.9D5F4C20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGzQbtFG3eL5U59AX8JP2r42qHgnQJMQVDemX8CwBA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373299205; bh=cfbuUGYEhYVgEDjJ6Xr/V5HL9+YREnSQAfZqsys9ZDM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=gYTJLWf/GZcgyr7CBaGc7pMDHC3BvONU9tCoc1vu95FOEg6uLAiQlpAq6XzI8cH/w J+RU+ztcMB+DBz1OVIXZA1/gEjDvdUkBZWc4wdPI7FP5kBGn9pYIFJs1eQdmNHT6WR RQ+AJUuWJXpOaWxw1uwOjdDquebtANh7+3vxiwATw6ChUiAts13buc4Sls1e2QV/7K uZ4n26zGQ+t1VVSI31PjvMeWAUdefmXeOG6GlmiXx5xyk60azKLu3kI3aLlvLpzsmN VbNu/uZP4Vh/N/fQiaIyuQP2Ur+KyhyoEpiFeFYmgd1R/hU40WIxLKHTIcnhROuZU6 clFpuh+/PXnaw== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:00:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005B_01CE7BD2.9D5F4C20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 =20 David Harrington ietfdbh@comcast.net +1-603-828-1401 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf = Of Michael MacFaden Sent: Monday, July 08, 2013 11:55 AM To: Tom Sanders Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat =20 I know that we dont have a setbulk operation in SNMP. Am just wondering = as to why it isnt there. Is there a reason why we only have a getbulk = PDU and not a setbulk PDU? Will not having a SETBULK PDU speed up = configs as we dont have to set multiple SET PDUs. Yet message size would still limited udp transport. Reminds me of the apple airport mgmt interface for config,=20 recall it used snmp set with one very large octet string. =20 Anyway standardization efforts have long since focused what operators thought would be a more acceptable approach, ...doing config with NETCONF. =20 =20 Mike =20 ------=_NextPart_000_005B_01CE7BD2.9D5F4C20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1

 

David Harrington

ie= tfdbh@comcast.net

+1-603-828-1401

From:= = opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of = Michael MacFaden
Sent: Monday, July 08, 2013 11:55 = AM
To: Tom Sanders
Cc: = opsawg@ietf.org
Subject: Re: [OPSAWG] SNMP SetBulk = Operat

 

I know that = we dont have a setbulk operation in SNMP. Am just wondering as to why it = isnt there. Is there a reason why we only have a getbulk PDU and not a = setbulk PDU? Will not having a SETBULK PDU speed up configs as we dont = have to set multiple SET = PDUs.

Yet message size would = still limited udp transport.

Reminds me of the apple = airport mgmt interface for config,

recall it used snmp set = with one very large octet = string.

 

Anyway standardization efforts have long = since focused

what operators thought would be a more acceptable = approach,

...doing config with = NETCONF.

 

 

Mike

 

------=_NextPart_000_005B_01CE7BD2.9D5F4C20-- From toms.sanders@gmail.com Mon Jul 8 09:15:39 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6A321F9C0B for ; Mon, 8 Jul 2013 09:15:39 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3YuLjjxNjGJ for ; Mon, 8 Jul 2013 09:15:39 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5A51F21F9C0A for ; Mon, 8 Jul 2013 09:15:39 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id t12so4228126pdi.21 for ; Mon, 08 Jul 2013 09:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MJHvMEd8u3nvIJt4/1GP67DMhA64QQOpPYTPsd7fzuM=; b=jtxP12IZTkSUvy670G6zhCdPcAEy/QRigU7hzljmS2RMGid0i5LbpCyV/Fcm1+v4cL juFW/csFbEl1CU30vVQa2gjbVVPYyUCYNEujGyZVyXfnUhNS7PaPTJQh1tALYqMV8kf3 zAk80wRXofw/oGTriLrFOeM6TtKwR/teSfwCsXXqLz8yumOjwvN7ZJui+SSiPFfunQLF I9A9JNx1nSKDOVHPIsJAvD1L7vyjr8g4zxD2k/RhnNXlBpp0Lb5fSzVFgE9pn/yEHcB7 4O04ax6BwEoSazpO3e+UpgfN6O9uRsBIntb1GRZqWixlFEqPwqH5Fk0PAvGSSAJ5ZcnE 4+VQ== MIME-Version: 1.0 X-Received: by 10.67.3.99 with SMTP id bv3mr23630817pad.140.1373300138712; Mon, 08 Jul 2013 09:15:38 -0700 (PDT) Received: by 10.68.226.38 with HTTP; Mon, 8 Jul 2013 09:15:38 -0700 (PDT) In-Reply-To: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> References: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> Date: Mon, 8 Jul 2013 21:45:38 +0530 Message-ID: From: Tom Sanders To: Michael MacFaden Content-Type: multipart/alternative; boundary=047d7b15fbc9f0294e04e1025add Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:15:40 -0000 --047d7b15fbc9f0294e04e1025add Content-Type: text/plain; charset=UTF-8 Mike, I hear you when you say that operators might want to use NETCONF. However, there are still many out there that use provisioning tools that use SNMP as the underlying protocol who might benefit from such a PDU. Regardless of this, i would like to understand the rational (if anybody knows) of only having a GETBULK PDU and not a SETBULK PDU? Toms On 8 July 2013 21:25, Michael MacFaden wrote: > I know that we dont have a setbulk operation in SNMP. Am just wondering as > to why it isnt there. Is there a reason why we only have a getbulk PDU and > not a setbulk PDU? Will not having a SETBULK PDU speed up configs as we > dont have to set multiple SET PDUs. > > Yet message size would still limited udp transport. > Reminds me of the apple airport mgmt interface for config, > recall it used snmp set with one very large octet string. > > Anyway standardization efforts have long since focused > what operators thought would be a more acceptable approach, > ...doing config with NETCONF. > > > Mike > > -- Toms. --047d7b15fbc9f0294e04e1025add Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike,

I hear you when you say tha= t operators might want to use NETCONF. However, there are still many out th= ere that use provisioning tools that use SNMP as the underlying protocol wh= o might benefit from such a PDU.

Regardless of this, i would like to underst= and the rational (if anybody knows) of only having a GETBULK PDU and not a = SETBULK PDU?

Toms


On 8 July 2013 21:25, Michael MacFaden <= span dir=3D"ltr"><mr= m@vmware.com> wrote:
I know that we dont have a = setbulk operation in SNMP. Am just wondering as to why it isnt there. Is th= ere a reason why we only have a getbulk PDU and not a setbulk PDU? Will not= having a SETBULK PDU speed up configs as we dont have to set multiple SET = PDUs.
Yet message size wou= ld still limited udp transport.
Reminds me of the apple airport mgmt interface for config,
recall it used snmp set with one=C2=A0<= /span>very large octet string.
<= div>
Anyway=C2=A0standardizat= ion efforts have long since focused
what operators thought would be a more = acceptable approach,
...doi= ng config with NETCONF.


Mike




--
Toms.
--047d7b15fbc9f0294e04e1025add-- From randy_presuhn@mindspring.com Mon Jul 8 09:27:08 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33E521F9D0D for ; Mon, 8 Jul 2013 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 471kEOt6QaM9 for ; Mon, 8 Jul 2013 09:26:57 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id E7C5B21F9349 for ; Mon, 8 Jul 2013 09:26:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TiZHXTnK26twtB3FovCpRmDuYqoj5VFKeyEpxKL8Lscm6hIq7Mj+weQaCkbeBfzy; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UwEGy-0003mD-2W for opsawg@ietf.org; Mon, 08 Jul 2013 12:26:44 -0400 Received: from 99.187.238.71 by webmail.earthlink.net with HTTP; Mon, 8 Jul 2013 12:26:44 -0400 Message-ID: <9695388.1373300804049.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Mon, 8 Jul 2013 09:26:44 -0700 (GMT-07:00) From: Randy Presuhn To: opsawg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f08d646fa0d1e1cc4bafc1706a9754e34e2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:27:09 -0000 Hi - >From: Tom Sanders >Sent: Jul 8, 2013 9:15 AM >To: Michael MacFaden >Cc: opsawg@ietf.org >Subject: Re: [OPSAWG] SNMP SetBulk Operat ... >Regardless of this, i would like to understand the rational (if anybody >knows) of only having a GETBULK PDU and not a SETBULK PDU? ... I'm not sure what you have in mind. How would the "SETBULK PDU" (and presumably the corresponding response PDU) you're thinking of be different (syntactically and semantically) from the existing SetRequest-PDU? Randy From mrm@vmware.com Mon Jul 8 09:34:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CC121F8EEA for ; Mon, 8 Jul 2013 09:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pguF0IhREPQ for ; Mon, 8 Jul 2013 09:34:12 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9C60521F9D36 for ; Mon, 8 Jul 2013 09:34:12 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 8AE362865A; Mon, 8 Jul 2013 09:34:12 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 52E5B4009D; Mon, 8 Jul 2013 09:34:12 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 3E1EDE00FB; Mon, 8 Jul 2013 09:34:12 -0700 (PDT) Received: from [10.26.164.139] (unknown [10.113.160.14]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTPSA; Mon, 8 Jul 2013 09:34:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B3E68A8-B202-49A1-8D24-371021FF9002" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mike MacFaden In-Reply-To: Date: Mon, 8 Jul 2013 09:34:07 -0700 Message-Id: <3CAF33B8-CBFC-47B7-A22C-7405133CA670@zimbra.vmware.com> References: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> To: Tom Sanders X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:34:16 -0000 --Apple-Mail=_6B3E68A8-B202-49A1-8D24-371021FF9002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 8, 2013, at 9:15 AM, Tom Sanders wrote: > I hear you when you say that operators might want to use NETCONF. Operators did more than say they might, they wore t-shirts that read: "It's the CLI stupid" =20 IIRC that was during NANOG 19 conference plus or minus. > Regardless of this, i would like to understand the rational (if = anybody knows) of only having a GETBULK PDU and not a SETBULK PDU? First of all sets require a layer of security and that took a bit longer = to accomplish, not until 2002/SNMPv3. Secondly what would a set bulk do differently than a SET command? Thirdly =85. http://tools.ietf.org/html/rfc3512 Mike --Apple-Mail=_6B3E68A8-B202-49A1-8D24-371021FF9002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 toms.sanders@gmail.com> = wrote:

I hear you when you say that = operators might want to use = NETCONF.


Operators = did more than say they might, they wore t-shirts that = read:

"It's the CLI stupid" =  

IIRC that was during NANOG 19 conference = plus or minus.


Regardless of this, i would like to understand the = rational (if anybody knows) of only having a GETBULK PDU and not a = SETBULK PDU?

First of all sets = require a layer of security and that took a bit longer to accomplish, = not until 2002/SNMPv3.
Secondly  what would a set bulk do = differently than a SET command?


Mike


= = --Apple-Mail=_6B3E68A8-B202-49A1-8D24-371021FF9002-- From toms.sanders@gmail.com Mon Jul 8 09:44:02 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BD821F9DA1 for ; Mon, 8 Jul 2013 09:44:02 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0zDaqtlXS7i for ; Mon, 8 Jul 2013 09:44:01 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7E51A21F9D8E for ; Mon, 8 Jul 2013 09:44:01 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so4486201pbc.21 for ; Mon, 08 Jul 2013 09:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eTV1wXHHtOd5ZTlA5n+TMCy4jBoWKDXNFhOO7NiIgBI=; b=az86Wd5BJ6766/29Ik0Vr6DOaVCFbUxjvHw3VVt1D+WKvP3Ggo0Q34yXravwiaG1Ub bCAuq9CQ8HrTQliRLjSE/lK+8l1MsbYluV9ldwsfowHj9JOnV43YLT4mtb+k+JIECyp7 Bxz0UKDgEMu6XIwUXU4RRvhvNOHxZJk046+z076o+66GZZ5FqiKUS3l/9A9CVi/IV21y N6YrAwmbhxDxut2lsTH08hKWDA7Ffvzw145sFjDhUltbCLWK/sGOXz/cenieI/nf7Okg kqnJ+7YpxT7chPkLMT5ejXBzZY0Td0nhV/KmdzfTdlJxcpSw6F4TRpUIz070KJebM6Hi tX7g== MIME-Version: 1.0 X-Received: by 10.68.170.227 with SMTP id ap3mr21973378pbc.194.1373301841151; Mon, 08 Jul 2013 09:44:01 -0700 (PDT) Received: by 10.68.226.38 with HTTP; Mon, 8 Jul 2013 09:44:01 -0700 (PDT) In-Reply-To: <3CAF33B8-CBFC-47B7-A22C-7405133CA670@zimbra.vmware.com> References: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> <3CAF33B8-CBFC-47B7-A22C-7405133CA670@zimbra.vmware.com> Date: Mon, 8 Jul 2013 22:14:01 +0530 Message-ID: From: Tom Sanders To: Mike MacFaden Content-Type: multipart/alternative; boundary=047d7b6d8f1a694f6a04e102c0fe Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:44:02 -0000 --047d7b6d8f1a694f6a04e102c0fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Assume that a user wants to create 100 vlans. Instead of using 100 set operations, cant we use one SETBULK operation since in this case its only the index that is different - all other parameters are the same. Toms On 8 July 2013 22:04, Mike MacFaden wrote: > > On Jul 8, 2013, at 9:15 AM, Tom Sanders wrote: > > I hear you when you say that operators might want to use NETCONF. > > > > Operators did more than say they might, they wore t-shirts that read: > > "It's the CLI stupid" > > IIRC that was during NANOG 19 conference plus or minus. > > > Regardless of this, i would like to understand the rational (if anybody > knows) of only having a GETBULK PDU and not a SETBULK PDU? > > > First of all sets require a layer of security and that took a bit longer > to accomplish, not until 2002/SNMPv3. > Secondly what would a set bulk do differently than a SET command? > > Thirdly =E2=80=A6. http://tools.ietf.org/html/rfc3512 > > Mike > > > --=20 Toms. --047d7b6d8f1a694f6a04e102c0fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Assume that a user wants to create 100 vlans. Instead of u= sing 100 set operations, cant we use one SETBULK operation since in this ca= se its only the index that is different - all other parameters are the same= .

Toms


On 8 July 2013 22:04, Mike MacFaden <mrm@zimbra.vmware.com> wrote:


I hear you when you say= that operators might want to use NETCONF.

Operators did more than say they might, they wo= re t-shirts that read:

"It's the CLI stupid" =C2=A0
IIRC that was during NANOG 19 conference plus or minus.
<= div class=3D"im">


Regardless of this, i would like to understand the rational (if anybod= y knows) of only having a GETBULK PDU and not a SETBULK PDU?

First of all sets require a layer of securit= y and that took a bit longer to accomplish, not until 2002/SNMPv3.
Secondly =C2=A0what would a set bulk do differently than a SET command= ?

Thirdly =E2=80=A6. =C2=A0http://tools.ietf.org/html/rfc351= 2

Mike


=



--
Toms.
--047d7b6d8f1a694f6a04e102c0fe-- From randy_presuhn@mindspring.com Mon Jul 8 09:51:24 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A1321F9D56 for ; Mon, 8 Jul 2013 09:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzmSA9Zd12oH for ; Mon, 8 Jul 2013 09:51:17 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id AD60121F8B8B for ; Mon, 8 Jul 2013 09:51:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hAkeKPTDzd1JmqIprI0FshD2SA/irPFL4S4eGftnx4G0go4dBKqdyejDfke+bnXZ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UwEei-0006Hw-At for opsawg@ietf.org; Mon, 08 Jul 2013 12:51:16 -0400 Received: from 99.187.238.71 by webmail.earthlink.net with HTTP; Mon, 8 Jul 2013 12:51:16 -0400 Message-ID: <31731846.1373302276328.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Mon, 8 Jul 2013 09:51:16 -0700 (GMT-07:00) From: Randy Presuhn To: opsawg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f0804f171264bed10781a94e6b3f58ff2d1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:51:24 -0000 Hi - >From: Tom Sanders >Sent: Jul 8, 2013 9:44 AM >To: Mike MacFaden >Cc: opsawg@ietf.org >Subject: Re: [OPSAWG] SNMP SetBulk Operat > >Assume that a user wants to create 100 vlans. Instead of using 100 set >operations, cant we use one SETBULK operation since in this case its only >the index that is different - all other parameters are the same. What would the *syntax* of such a request look like? What would the syntax of the response be? How would this work with tables with multiple indexes? How would this work with tables with non-integer indexes? How would this work with a table that is already populated? How would this work with a partially-populated table? Randy From randy_presuhn@mindspring.com Mon Jul 8 09:55:40 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B393821F9A8C for ; Mon, 8 Jul 2013 09:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHDkT-MzUVHz for ; Mon, 8 Jul 2013 09:55:26 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id B155721F8EB3 for ; Mon, 8 Jul 2013 09:55:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DN/2IinYXTH2MdtRLZ7qoKA9jwe8plmm2s43nVmA37DNTyysrBaSGT2Kt3LVVdLD; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UwEij-0003aO-6C; Mon, 08 Jul 2013 12:55:25 -0400 Received: from 99.187.238.71 by webmail.earthlink.net with HTTP; Mon, 8 Jul 2013 12:55:24 -0400 Message-ID: <19673138.1373302525067.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Mon, 8 Jul 2013 09:55:24 -0700 (GMT-07:00) From: Randy Presuhn To: Mike MacFaden , Tom Sanders Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f0894846b69ee82d76680b3ffd6d5e585a8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:55:40 -0000 Hi - >From: Mike MacFaden >Sent: Jul 8, 2013 9:34 AM >To: Tom Sanders >Cc: opsawg@ietf.org >Subject: Re: [OPSAWG] SNMP SetBulk Operat ... >Thirdly =E2=80=A6. http://tools.ietf.org/html/rfc3512 In fairness, netconf bears scant resemblance to what the operators at the IAB workshop seemed to me to be asking for. Randy From mrm@vmware.com Mon Jul 8 10:24:12 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5172321F9D8B for ; Mon, 8 Jul 2013 10:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZxTU8xpknac for ; Mon, 8 Jul 2013 10:24:05 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7BE21F9CF1 for ; Mon, 8 Jul 2013 10:24:01 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 26626280FD; Mon, 8 Jul 2013 10:24:01 -0700 (PDT) Received: from zcs-prod-mta-3.vmware.com (zcs-prod-mta-3.vmware.com [10.113.163.65]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 24DC1B053E; Mon, 8 Jul 2013 10:24:01 -0700 (PDT) Received: from zcs-prod-mta-3.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-3.vmware.com (Postfix) with ESMTP id EC1A3E015E; Mon, 8 Jul 2013 10:24:00 -0700 (PDT) Received: from [10.26.164.139] (unknown [10.113.160.14]) by zcs-prod-mta-3.vmware.com (Postfix) with ESMTPSA; Mon, 8 Jul 2013 10:24:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mike MacFaden In-Reply-To: Date: Mon, 8 Jul 2013 10:23:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <34870613-9425-407A-B43D-0D34F8C25B75@zimbra.vmware.com> References: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> <3CAF33B8-CBFC-47B7-A22C-7405133CA670@zimbra.vmware.com> To: Tom Sanders X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:24:13 -0000 On Jul 8, 2013, at 9:44 AM, Tom Sanders wrote: > Assume that a user wants to create 100 vlans. Instead of using 100 set = operations, cant we use one SETBULK operation > since in this case its only the index that is different - all other = parameters are the same. SNMP defines a transaction as a single SET command and is constrained by = UDP transport message size.=20 SETBULK would still be constrained by the general problems found with = doing SETs and snmp -- including "too" many variables issue that can cause problems for devices with = large configurations. RFC 3512 contained design patterns for MIB module writers to consider = solving this problem with existing SET. We had to consider the important case of backward = compatibility i.e. v3 client talking to v1 server via PROXY or visa versa. In any case by the time the RFC was published most IETF WGs were not interested in SET with snmp only monitoring/GET. Mike From j.schoenwaelder@jacobs-university.de Mon Jul 8 10:37:08 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4B521F9C7D for ; Mon, 8 Jul 2013 10:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.071 X-Spam-Level: X-Spam-Status: No, score=-103.071 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7lvrRLjT+lg for ; Mon, 8 Jul 2013 10:37:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BD28B21F9C41 for ; Mon, 8 Jul 2013 10:36:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5BE4209D7; Mon, 8 Jul 2013 19:36:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aR6NPcLF4d0f; Mon, 8 Jul 2013 19:36:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41A6220979; Mon, 8 Jul 2013 19:36:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 900E1272D0F3; Mon, 8 Jul 2013 19:36:49 +0200 (CEST) Date: Mon, 8 Jul 2013 19:36:49 +0200 From: Juergen Schoenwaelder To: Tom Sanders Message-ID: <20130708173649.GD56895@elstar.local> Mail-Followup-To: Tom Sanders , opsawg@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:37:08 -0000 On Mon, Jul 08, 2013 at 09:03:25PM +0530, Tom Sanders wrote: > I know that we dont have a setbulk operation in SNMP. Am just wondering as > to why it isnt there. Is there a reason why we only have a getbulk PDU and > not a setbulk PDU? Will not having a SETBULK PDU speed up configs as we > dont have to set multiple SET PDUs. Getbulk makes sense because it allows to retrieve data out of a namespace that is not know by a management application (the next N iterations over a portion of a varbind list in lexicographic order). For writing, a management application can be assumed to know the namespace and hence the management application can stuff as much data into the varbind list as there is space. You can create 100 vlans in a single SNMP set today - if your message size handles this. /js PS: Sure, there are corner cases where the management application may not be fully aware of the namespace usage but corner cases do not justify new PDUs. PS: There once was a WG called EOS and it might be useful to look at stuff discussed back in those days. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rstory@tislabs.com Mon Jul 8 11:38:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240AE21F9C06 for ; Mon, 8 Jul 2013 11:38:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrL8Nzi4LYZq for ; Mon, 8 Jul 2013 11:38:01 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE921F9C03 for ; Mon, 8 Jul 2013 11:37:55 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 2566A28B003A; Mon, 8 Jul 2013 14:37:55 -0400 (EDT) Received: from ispx.vb.futz.org (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id E34881F8032; Mon, 8 Jul 2013 14:37:54 -0400 (EDT) Date: Mon, 8 Jul 2013 14:37:47 -0400 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20130708143747.37a1c7f6@ispx.vb.futz.org> In-Reply-To: <20130708173649.GD56895@elstar.local> References: <20130708173649.GD56895@elstar.local> Organization: Parsons X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/=JFOEbn8WblPC_b4k8gmzJI"; protocol="application/pgp-signature" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:38:06 -0000 --Sig_/=JFOEbn8WblPC_b4k8gmzJI Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 8 Jul 2013 19:36:49 +0200 Juergen wrote: JS> PS: There once was a WG called EOS and it might be useful to look at JS> stuff discussed back in those days. Yep, OID compression would allow more varbinds in all PDUs, not just sets. Robert -- Senior Software Engineer Parsons Government Services , National Security & Defense Division --Sig_/=JFOEbn8WblPC_b4k8gmzJI Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHbBwIACgkQ7/fVLLY1mngJ5wCgmg5UozWx7TOco+FuucmN61NL MAYAni8fJpuoNhbxrPTbmXOMStvF8rHN =GXys -----END PGP SIGNATURE----- --Sig_/=JFOEbn8WblPC_b4k8gmzJI-- From internet-drafts@ietf.org Mon Jul 8 14:38:47 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D5321F9E41; Mon, 8 Jul 2013 14:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JFlEG3RqVn0; Mon, 8 Jul 2013 14:38:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8149721F9E3F; Mon, 8 Jul 2013 14:38:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708213845.4253.1579.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 14:38:45 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-oam-overview-09.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:38:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : An Overview of Operations, Administration, and Maintenan= ce (OAM) Mechanisms Author(s) : Tal Mizrahi Nurit Sprecher Elisa Bellagamba Yaacov Weingarten Filename : draft-ietf-opsawg-oam-overview-09.txt Pages : 44 Date : 2013-07-08 Abstract: Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of transport protocols. This document presents an overview of the data plane OAM tools that have been defined by the IETF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-oam-overview-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From talmi@marvell.com Mon Jul 8 14:45:17 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E7B21F8E37 for ; Mon, 8 Jul 2013 14:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxaxteXmfLuq for ; Mon, 8 Jul 2013 14:45:13 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id E5D3321F95DD for ; Mon, 8 Jul 2013 14:45:06 -0700 (PDT) Received: from sc-owa02.marvell.com ([199.233.58.137]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKUdsypmv5fDkWwmtyGkHNEdeAGlNnhCF8@postini.com; Mon, 08 Jul 2013 14:45:12 PDT Received: from YK-HUB02.marvell.com (10.4.102.52) by sc-owa02.marvell.com (10.93.76.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Jul 2013 14:44:02 -0700 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Tue, 9 Jul 2013 00:43:59 +0300 From: Tal Mizrahi To: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" , "Carlos Pignataro (cpignata)" , Alexander Vainshtein , Elwyn Davies , Thomas Nadeau , "MORTON JR., ALFRED C (AL)" , Thomas Narten , Sam Aldrin , "Romascanu, Dan (Dan)" , joel jaeggli , Benoit Claise Date: Tue, 9 Jul 2013 00:43:57 +0300 Thread-Topic: Updated draft-ietf-opsawg-oam-overview Thread-Index: Ac58JBv8xtXXc/t2R4uAQ7hLVUUpyw== Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F9F93307@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F9F93307ILMB01marve_" MIME-Version: 1.0 Subject: [OPSAWG] Updated draft-ietf-opsawg-oam-overview X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:45:18 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F9F93307ILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have updated draft-ietf-opsawg-oam-overview following the comments we re= ceived in IETF last call. http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-09 This document went into IETF last call in January, and we received comments= from (in chronological order): Benoit Claise, Al Morton, Sam Aldrin, Tom N= adeau, Carlos Pignataro, Elwyn Davies, Sasha Vainshtein, Dan Romascanu, Tho= mas Narten, Joel Jaeggli. We carefully considered each and every comment, and significantly edited th= e document to address these comments. After we revised the document some of our reviewers kindly agreed to reiter= ate on the document in 1x1 sessions, allowing us to verify that we addresse= d the major comments. A brief summary of the changes in the document: - We practically rewrote the introduction; we added a subsection about the = target audience, and add general background about OAM including some histor= ical background. - The structure of the document went through a significant revision as well= ; for example, we moved the list of OAM documents to an appendix, and moved= the terminology section closer to the beginning. - We revised the terminology section: we added quite a few terms that were = used without definition, and we fixed some inaccurate existing definitions.= We also did some major editing throughout the document to verify that the = terminology is used consistently. - We added content that was missing in previous version of the draft, e.g.,= TRILL OAM. We encourage the reviewers to go over the updated document and let us know = if there are any further comments. Any further comments from the WG are welcome. Thanks, Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F9F93307ILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have up= dated draft-ietf-opsawg-oam-overview following the comments we received in = IETF last call.

http://tools.ietf.org/html= /draft-ietf-opsawg-oam-overview-09

<= o:p> 

This document went into IETF last = call in January, and we received comments from (in chronological order): Be= noit Claise, Al Morton, Sam Aldrin, Tom Nadeau, Carlos Pignataro, Elwyn Dav= ies, Sasha Vainshtein, Dan Romascanu, Thomas Narten, Joel Jaeggli.

We carefully considered each and every comment, = and significantly edited the document to address these comments.=

After we revised the document some of our reviewer= s kindly agreed to reiterate on the document in 1x1 sessions, allowing us t= o verify that we addressed the major comments.

A brief summary of the changes = in the document:

- We practically rewrot= e the introduction; we added a subsection about the target audience, and ad= d general background about OAM including some historical background.

- The structure of the document went through a= significant revision as well; for example, we moved the list of OAM docume= nts to an appendix, and moved the terminology section closer to the beginni= ng.

- We revised the terminology section= : we added quite a few terms that were used without definition, and we fixe= d some inaccurate existing definitions. We also did some major editing thro= ughout the document to verify that the terminology is used consistently.

- We added content that was missing in pre= vious version of the draft, e.g., TRILL OAM.

 

We encourage the reviewers t= o go over the updated document and let us know if there are any further com= ments.

Any further comments from the WG = are welcome.

 

Thanks,

Tal.

=

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F9F93307ILMB01marve_-- From andy.donati@comcast.net Mon Jul 8 19:56:49 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BDC11E8105 for ; Mon, 8 Jul 2013 19:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqAYnwXlhAOn for ; Mon, 8 Jul 2013 19:56:45 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id DECBE21F9A71 for ; Mon, 8 Jul 2013 19:56:44 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta04.westchester.pa.mail.comcast.net with comcast id y2wB1l0010QuhwU542wkYV; Tue, 09 Jul 2013 02:56:44 +0000 Received: from [IPv6:2600:1000:b024:a047:d9e:d780:8c31:b038] ([IPv6:2600:1000:b024:a047:d9e:d780:8c31:b038]) by omta02.westchester.pa.mail.comcast.net with comcast id y2wi1l01N1gfn3f3N2wjef; Tue, 09 Jul 2013 02:56:44 +0000 References: <1610053504.17596468.1373298927137.JavaMail.root@vmware.com> <3CAF33B8-CBFC-47B7-A22C-7405133CA670@zimbra.vmware.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-EB5EAF85-C72C-466E-BACE-0F2606757DFF Content-Transfer-Encoding: 7bit Message-Id: <434429ED-15D1-4BAF-9E89-2D2B55D7959E@comcast.net> X-Mailer: iPhone Mail (10B350) From: Andrew Donati Date: Mon, 8 Jul 2013 22:56:42 -0400 To: Tom Sanders DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373338604; bh=OvFWtbCHyeheaSeu2jHaCrRFn5xM0Q+h9QrDtoeWaeA=; h=Received:Received:Mime-Version:Content-Type:Message-Id:From: Subject:Date:To; b=bTIhBJCXQpmngXelTNiN4AnXo3RfWkF/s6QwjAcgesc/MbBvzEMZi1IZseIcbInCb wOWYVDWdQIuF1aKqQy9Ohd2W3wsyuc/ADraTHkGErupR+wknoOzqdtSRPruqhahujU PoSoEWzvvLmAGbNgTZG5iZB5UzNBW/3YgbGd+FcKVupXn8E34G+j3GpfLl26X7VqDW BkejUeKCHDc2Mrqc72whYvuBNgZ8QMOHeM3JYMIoevVY7lszcbN0aHG8Vny+ML9lVr x3yNx/pLwmwq5w+fkJtBfo/Hu7uK1WIHXErX6Pjox4bm0VMI9Qn5Z2gwFzjvwE5nFg Ehxo45dBgXE/g== Cc: "opsawg@ietf.org" , Mike MacFaden Subject: Re: [OPSAWG] SNMP SetBulk Operat X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 02:56:49 -0000 --Apple-Mail-EB5EAF85-C72C-466E-BACE-0F2606757DFF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Let's take as an example the setting of ifAdminStatus of all interfaces o= f a particular device to down. SETBULK can work in this example as all dat= a types and values will be the same for all instances for the ifAdminStatus c= olumn but special considerations need to be taken on the last PDU. The last= PDU will likely over extend the target column object making it fail as the n= ext column can be read only for example. As an alternative, SET operations using multiple variable bindings in one PD= U can be used but it is necessary to keep in mind the maximum UDP message si= ze. There is also additional flexibility using this method as each binding c= an be unrelated. -Andy On Jul 8, 2013, at 12:44 PM, Tom Sanders wrote: > Assume that a user wants to create 100 vlans. Instead of using 100 set ope= rations, cant we use one SETBULK operation since in this case its only the i= ndex that is different - all other parameters are the same. >=20 > Toms >=20 >=20 > On 8 July 2013 22:04, Mike MacFaden wrote: >>=20 >> On Jul 8, 2013, at 9:15 AM, Tom Sanders wrote: >>=20 >>> I hear you when you say that operators might want to use NETCONF. >>=20 >>=20 >> Operators did more than say they might, they wore t-shirts that read: >>=20 >> "It's the CLI stupid" =20 >>=20 >> IIRC that was during NANOG 19 conference plus or minus. >>=20 >>=20 >>> Regardless of this, i would like to understand the rational (if anybody k= nows) of only having a GETBULK PDU and not a SETBULK PDU? >>=20 >> First of all sets require a layer of security and that took a bit longer t= o accomplish, not until 2002/SNMPv3. >> Secondly what would a set bulk do differently than a SET command? >>=20 >> Thirdly =E2=80=A6. http://tools.ietf.org/html/rfc3512 >>=20 >> Mike >=20 >=20 >=20 > --=20 > Toms. > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail-EB5EAF85-C72C-466E-BACE-0F2606757DFF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
 Let's  take as an example &= nbsp;the setting of ifAdminStatus of all interfaces of a particular device t= o down.   SETBULK can work in this example as all data types and values= will be the same for all instances for the ifAdminStatus column but special= considerations need to be taken on the last PDU.  The last PDU will li= kely over extend the target column object making it fail as the next column c= an be read only for example.

As an alternative, SET= operations using multiple variable bindings in one PDU can be used but it i= s necessary to keep in mind the maximum UDP message size. There is also addi= tional  flexibility using this method as each binding can be unrelated.=

-Andy

On Jul 8, 2013, at 1= 2:44 PM, Tom Sanders <toms.sand= ers@gmail.com> wrote:

Assume that a user wants to create 100 vlans. Instead of using= 100 set operations, cant we use one SETBULK operation since in this case it= s only the index that is different - all other parameters are the same.
=
Toms


On 8 July 2013 22:04, Mike MacFaden <mrm@zimbra.vmware.com&g= t; wrote:

<= div class=3D"im">
On Jul 8, 2013, at 9:15 AM, Tom Sanders <toms.sanders@gmail.com= > wrote:

I hear you when you say t= hat operators might want to use NETCONF.


Operators did more than say they might, they wore t= -shirts that read:

"It's the CLI stupid"  

II= RC that was during NANOG 19 conference plus or minus.


Regardless of this, i would like to understand the rational (if anybody= knows) of only having a GETBULK PDU and not a SETBULK PDU?

First of all sets require a layer of security a= nd that took a bit longer to accomplish, not until 2002/SNMPv3.
Secondly  what would a set bulk do differently than a SET command?=


Mike


<= /blockquote>



--
Toms.
____________________= ___________________________
OPSAWG mailing list
OPSAWG@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/opsawg">https://www.ietf.org= /mailman/listinfo/opsawg
= --Apple-Mail-EB5EAF85-C72C-466E-BACE-0F2606757DFF-- From internet-drafts@ietf.org Tue Jul 9 19:44:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9C121F9AEE; Tue, 9 Jul 2013 19:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCEz22ljH8Ld; Tue, 9 Jul 2013 19:44:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3E521F9AE7; Tue, 9 Jul 2013 19:44:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710024434.16499.73341.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 19:44:34 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 02:44:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Mechanisms for Optimal LAG/ECMP Component Link Utilizati= on in Networks Author(s) : Ram Krishnan Sanjay Khanna Lucy Yong Anoop Ghanwani Ning So Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-03.txt Pages : 23 Date : 2013-07-09 Abstract: Demands on networking infrastructure are growing exponentially; the drivers are bandwidth hungry rich media applications, inter-data center communications, etc. In this context, it is important to optimally use the bandwidth in wired networks that extensively use LAG/ECMP techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-large-flow-load-balanc= ing-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jul 9 20:01:38 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7386911E8197; Tue, 9 Jul 2013 20:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uBh9h1KZx2N; Tue, 9 Jul 2013 20:01:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 167D711E8100; Tue, 9 Jul 2013 20:01:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710030137.3258.4705.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 20:01:37 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 03:01:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Mechanisms for Optimal LAG/ECMP Component Link Utilizati= on in Networks Author(s) : Ram Krishnan Sanjay Khanna Lucy Yong Anoop Ghanwani Ning So Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-04.txt Pages : 23 Date : 2013-07-09 Abstract: Demands on networking infrastructure are growing exponentially; the drivers are bandwidth hungry rich media applications, inter-data center communications, etc. In this context, it is important to optimally use the bandwidth in wired networks that extensively use LAG/ECMP techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-large-flow-load-balanc= ing-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ramk@Brocade.com Tue Jul 9 20:03:24 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05E921F9B0F for ; Tue, 9 Jul 2013 20:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD3K08eAtIFX for ; Tue, 9 Jul 2013 20:03:20 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 782E121F9B11 for ; Tue, 9 Jul 2013 20:03:12 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r6A336Vx020505; Tue, 9 Jul 2013 20:03:06 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1dgn0k8bch-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 09 Jul 2013 20:03:06 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 9 Jul 2013 20:03:06 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 9 Jul 2013 20:03:06 -0700 From: ramki Krishnan To: "opsawg@ietf.org" Date: Tue, 9 Jul 2013 20:03:01 -0700 Thread-Topic: New Version Notification for draft-ietf-opsawg-large-flow-load-balancing-04.txt Thread-Index: Ac59Gc06y13bBoGSTECW4EeCA/yx5QAAB5jg Message-ID: References: <20130710030138.3258.13516.idtracker@ietfa.amsl.com> In-Reply-To: <20130710030138.3258.13516.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-10_01:2013-07-09, 2013-07-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1307090248 Cc: Sanjay Khanna , Bhumip Khasnabish , Ning So Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-large-flow-load-balancing-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 03:03:24 -0000 RGVhciBBbGwsDQoNCldlIGhhdmUgZG9uZSBhIG1pbm9yIHVwZGF0ZSB0byB0aGUgaW5mb3JtYXRp b24gbW9kZWwgc2VjdGlvbiBmb3IgZnVydGhlciBjbGFyaXR5LiBZb3VyIGNvbW1lbnRzIG9uIHRo ZSBkcmFmdCBhcmUgd2VsY29tZS4NCg0KVGhhbmtzLA0KUmFta2kNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA5LCAyMDEzIDg6MDIg UE0NClRvOiBTYW5qYXkgS2hhbm5hOyBMdWN5IFlvbmc7IFNvIE5pbmc7IE5pbmcgU287IHJhbWtp IEtyaXNobmFuOyByYW1raSBLcmlzaG5hbjsgQW5vb3AgR2hhbndhbmk7IEJodW1pcCBLaGFzbmFi aXNoDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb3Bz YXdnLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNpbmctMDQudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWlldGYtb3BzYXdnLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNpbmctMDQudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhbSBLcmlzaG5hbiBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1vcHNh d2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZw0KUmV2aXNpb246CSAwNA0KVGl0bGU6CQkgTWVj aGFuaXNtcyBmb3IgT3B0aW1hbCBMQUcvRUNNUCBDb21wb25lbnQgTGluayBVdGlsaXphdGlvbiBp biBOZXR3b3Jrcw0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDctMDkNCkdyb3VwOgkJIG9wc2F3Zw0K TnVtYmVyIG9mIHBhZ2VzOiAyMw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wc2F3Zy1sYXJnZS1mbG93LWxvYWQtYmFsYW5j aW5nLTA0LnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb3BzYXdnLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNpbmcNCkh0bWxpemVk OiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctbGFy Z2UtZmxvdy1sb2FkLWJhbGFuY2luZy0wNA0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2F3Zy1sYXJnZS1mbG93LWxvYWQtYmFs YW5jaW5nLTA0DQoNCkFic3RyYWN0Og0KICAgRGVtYW5kcyBvbiBuZXR3b3JraW5nIGluZnJhc3Ry dWN0dXJlIGFyZSBncm93aW5nIGV4cG9uZW50aWFsbHk7IHRoZQ0KICAgZHJpdmVycyBhcmUgYmFu ZHdpZHRoIGh1bmdyeSByaWNoIG1lZGlhIGFwcGxpY2F0aW9ucywgaW50ZXItZGF0YQ0KICAgY2Vu dGVyIGNvbW11bmljYXRpb25zLCBldGMuIEluIHRoaXMgY29udGV4dCwgaXQgaXMgaW1wb3J0YW50 IHRvDQogICBvcHRpbWFsbHkgdXNlIHRoZSBiYW5kd2lkdGggaW4gd2lyZWQgbmV0d29ya3MgdGhh dCBleHRlbnNpdmVseSB1c2UNCiAgIExBRy9FQ01QIHRlY2huaXF1ZXMgZm9yIGJhbmR3aWR0aCBz Y2FsaW5nLiBUaGlzIGRyYWZ0IGV4cGxvcmVzIHNvbWUNCiAgIG9mIHRoZSBtZWNoYW5pc21zIHVz ZWZ1bCBmb3IgYWNoaWV2aW5nIHRoaXMuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From xueli@huawei.com Tue Jul 9 22:55:18 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEE321F9AEC for ; Tue, 9 Jul 2013 22:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80nfw29XhS-p for ; Tue, 9 Jul 2013 22:55:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E7EEE21F9AE3 for ; Tue, 9 Jul 2013 22:55:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH26017; Wed, 10 Jul 2013 05:55:12 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Jul 2013 06:54:50 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Jul 2013 06:55:07 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Wed, 10 Jul 2013 13:55:01 +0800 From: Xueli To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-xue-opsawg-capwap-separation-capability-00.txt Thread-Index: AQHOfSHDq0NI87QwW0iz8HgXAxVTN5ldaPvQ Date: Wed, 10 Jul 2013 05:55:00 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B4485256A8@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OPSAWG] FW: New Version Notification for draft-xue-opsawg-capwap-separation-capability-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 05:55:18 -0000 SGkgQWxsDQoNClRoZXJlIGlzIGEgbmV3IGRyYWZ0IGFib3V0IENBUFdBUCBleHRlbnNpb24gZm9y IENBUFdBUCBkYXRhIGNoYW5uZWwgYW5kIGNvbnRyb2wgY2hhbm5lbCBzZXBhcmF0aW9uLiANCllv dXIgY29tbWVudHMgYW5kIHJldmlldyBhcmUgYXBwcmVjaWF0ZWQuDQoNCkJlc3Qgd2lzaGVzDQoN CkxpIFh1ZQ0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+U2VudDog V2VkbmVzZGF5LCBKdWx5IDEwLCAyMDEzIDExOjU5IEFNDQo+VG86IEpvaG4gS2FpcHBhbGxpbWFs aWw7IER1em9uZ3Blbmc7IERhcGVuZyBMaXU7IFJvbmcgWmhhbmc7IFh1ZWxpDQo+U3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPmRyYWZ0LXh1ZS1vcHNhd2ctY2Fwd2FwLXNl cGFyYXRpb24tY2FwYWJpbGl0eS0wMC50eHQNCj4NCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQteHVlLW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1jYXBhYmlsaXR5LTAwLnR4dA0KPmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGkgWHVlIGFuZCBwb3N0ZWQgdG8gdGhl DQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPkZpbGVuYW1lOgkgZHJhZnQteHVlLW9wc2F3Zy1jYXB3 YXAtc2VwYXJhdGlvbi1jYXBhYmlsaXR5DQo+UmV2aXNpb246CSAwMA0KPlRpdGxlOgkJIENhcGFi aWxpdHkgQW5ub3VuY2VtZW50IGFuZCBBUiBEaXNjb3ZlcnkgaW4gQ0FQV0FQDQo+Q29udHJvbCBh bmQgRGF0YSBDaGFubmVsIFNlcGFyYXRpb24NCj5DcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0xMA0K Pkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPk51bWJlciBvZiBwYWdlczogOQ0KPlVS TDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dWUtb3BzYXdn LWNhcHdhcC1zZXBhcmF0aW9uLWNhcA0KPmFiaWxpdHktMDAudHh0DQo+U3RhdHVzOg0KPmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteHVlLW9wc2F3Zy1jYXB3YXAtc2VwYXJh dGlvbi1jYXBhYmlsaXQNCj55DQo+SHRtbGl6ZWQ6DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQteHVlLW9wc2F3Zy1jYXB3YXAtc2VwYXJhdGlvbi1jYXBhYmlsaXR5LTAwDQo+DQo+ DQo+QWJzdHJhY3Q6DQo+ICAgSW4gYSBjZW50cmFsaXplZCBJRUVFIDgwMi4xMSBXaXJlbGVzcyBM b2NhbCBBcmVhIE5ldHdvcmsgKFdMQU4pDQo+ICAgYXJjaGl0ZWN0dXJlLCB0aGUgQWNjZXNzIENv bnRyb2xsZXIgKEFDKSBkb2VzIG5vdCBoYXZlIHRoZQ0KPiAgIGludGVsbGlnZW5jZSB0byBhZ2dy ZWdhdGUgYWxsIHRoZSB3aXJlbGVzcyBmcmFtZXMuIEluIGFkZGl0aW9uLA0KPiAgIGluY3JlYXNp bmcgYW1vdW50cyBvZiB0cmFmZmljIGhhbmRsZWQgYnkgZWFjaCBhY2Nlc3MgcG9pbnQgd291bGQN Cj4gICByZXF1aXJlIGV2ZW4gbW9yZSBwcm9jZXNzaW5nIGF0IGFuIEFDLiAgVGh1cyBpdCBpcyBu b3JtYWwgaW4gYW4NCj4gICBleGlzdGluZyBvcGVyYXRvcidzIG5ldHdvcmsgZm9yIHRoZSBXVFBz IHRvIGZvcndhcmQgdGhlIHdpcmVsZXNzDQo+ICAgZnJhbWVzIGRpcmVjdGx5IHRvIEFSIHRvIGF2 b2lkIG92ZXJsb2FkaW5nIHRoZSBBQy4gIEluIHRoaXMgc2NlbmFyaW8sDQo+ICAgQ0FQV0FQIENv bnRyb2wgQ2hhbm5lbCBhbmQgQ0FQV0FQIERhdGEgQ2hhbm5lbCBhcmUgc2VwYXJhdGVkIGZyb20N Cj4gICBlYWNoIG90aGVyLiAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBleHRlbnNpb25zIHRvIENB UFdBUCBmb3IgdGhlDQo+ICAgc3BsaXQgc2NlbmFyaW8gd2hlcmUgQ0FQV0FQIENvbnRyb2wgYW5k IERhdGEgQ2hhbm5lbCBhcmUgc2VwYXJhdGVkLg0KPg0KPg0KPg0KPg0KPg0KPlRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg== From zehn.cao@gmail.com Mon Jul 15 08:02:45 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0811A11E8150 for ; Mon, 15 Jul 2013 08:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHHoB2rJwLjd for ; Mon, 15 Jul 2013 08:02:44 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA6611E8156 for ; Mon, 15 Jul 2013 08:02:42 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so10144871wes.38 for ; Mon, 15 Jul 2013 08:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mkr9aA4CMQViWz0XcFey1mdVVcCoQ/JBxvOQgwhI+MM=; b=q0QswRZla2xqx8d8HiiqWbBMksLZ+0Rbn4ol+bxCkulb1VEiuETeluK32ipze5pXy5 UKCesOqN2XrM0FWCt7HzFDu0e30qK6jwKMYpsIPwPHczeqqebPfSBIoCuOY/2F4DEdBA T8yKhigJUlp8WLW5QITg7TaytLRMlfU2oWSzrv4YzssbhTJyWQ2GHx1knoNJbFYeKko8 QRLEzYKSnJ5v6yzdieoyOhqrynae74000wOS1ARTstM2e+D8ttmmIkJunG1lHLh3oQcx 7LMLECEzBNLqtOiLOlQuGNTrdZk+jQfeo9jTXYOQrYd0ep73QYVaK5rPJc9b36jNLh2i I1pg== MIME-Version: 1.0 X-Received: by 10.194.58.11 with SMTP id m11mr32366005wjq.45.1373900562197; Mon, 15 Jul 2013 08:02:42 -0700 (PDT) Received: by 10.216.77.131 with HTTP; Mon, 15 Jul 2013 08:02:42 -0700 (PDT) In-Reply-To: <20130714125019.25439.81817.idtracker@ietfa.amsl.com> References: <20130714125019.25439.81817.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 23:02:42 +0800 Message-ID: From: "Cao,Zhen" To: opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OPSAWG] Fwd: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:02:45 -0000 FYI. ---------- Forwarded message ---------- From: Date: Sun, Jul 14, 2013 at 8:50 PM Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Separation of CAPWAP Control and Data Plane: Scenarios, Requirements and Solutions Author(s) : Rong Zhang Zhen Cao Hui Deng Rajesh S. Pazhyannur Sri Gundavelli Filename : draft-zhang-opsawg-capwap-cds-00.txt Pages : 8 Date : 2013-07-14 Abstract: This document describes the scenarios and requirements of separating CAPWAP Data and Control plane. This specification provides a CAPWAP extension to allow two distinct AC component: AC-DP (AC-Data Plane) and AC-CP (AC-Control Plane). AC-DP handles all user payload with the exception of layer 2 management frames between the AC and user such as IEEE 802.11 association, authentication, probe, Action Frame. AC-CP handles all control messages between the WTP and AC. In addition, the AC-CP wil handle user payload related to layer-2 management frames such as those mentioned above. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds There's also a htmlized version available at: http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From melinda.shore@gmail.com Tue Jul 16 12:46:18 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0021821E8054 for ; Tue, 16 Jul 2013 12:46:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lweMjMutBYYE for ; Tue, 16 Jul 2013 12:46:17 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9258521F9D22 for ; Tue, 16 Jul 2013 12:46:17 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so1127241pac.26 for ; Tue, 16 Jul 2013 12:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=4UYYDomhSi1VD9xjFcAx3j77M+r7cVWfwhYsueQxnYU=; b=fSqfbwBQ1eF7AC1hvaGtXr1/4F0D68dcSlU9XoCmtKMSWO3U3LC6pMoGS8ahoOE5rh 1M5TH8PQqRewSqvArO+X6fwBcaFzdD/7yMy2/nJA8iK+3BLl7CV5cGdcoPm2U0+e664J GlZuEJwsmfUxx8rVQbbnkWu0URvEG++eFaV0EmwbswlYc2bKJk96xDH1gAcBVy3ZzCV+ Co60oUVVQ46Ppp+sHS5NGV9oyQ1ru/vZ2lEqJveAjuYauBP4Ej/hnZGic8TLL6rE1O3M o79+SpgT75fWbem70HLCX5IhcG2RlHKi5F0UySKb0sdSmlYgs6BU4tRhZUx+7Uc+2VZf RNPA== X-Received: by 10.66.194.13 with SMTP id hs13mr4204635pac.152.1374003977344; Tue, 16 Jul 2013 12:46:17 -0700 (PDT) Received: from spandex.local (216-67-40-63-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.40.63]) by mx.google.com with ESMTPSA id nv6sm3545846pbc.6.2013.07.16.12.46.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 12:46:16 -0700 (PDT) Message-ID: <51E5A306.5080907@gmail.com> Date: Tue, 16 Jul 2013 11:46:14 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] On the use of meeting time X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:46:18 -0000 We've been getting a lot of requests for time on the agenda for the upcoming meeting to "present" drafts which haven't been discussed on the mailing list. This is a reminder that the purpose of meetings is face-to-face discussion of issues that haven't been able to make progress on the mailing list, and to progress deliverables. The IETF is somewhat different from other standards bodies in that meeting time is generally not used for presentation of new material, and that the work of the organization is primarily done via working group mailing lists. The most reliable way to get time on a meeting agenda is to have a lively discussion on the mailing list prior to the meeting. Thanks, Melinda From andy@yumaworks.com Tue Jul 16 15:37:48 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37B121F896D for ; Tue, 16 Jul 2013 15:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwm3ebkGSicZ for ; Tue, 16 Jul 2013 15:37:43 -0700 (PDT) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id B9E1C21F8AA1 for ; Tue, 16 Jul 2013 15:37:43 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so1194259pbc.10 for ; Tue, 16 Jul 2013 15:37:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=TH+kMeuglyjmNNaQ6VJaCZqfKWOhKvJZ9Hs1UhlQnlQ=; b=pOIjE8KfYmStyXMOfu4+v4pYoMxOQb5UbWsOjypZMu+9k/CUtmiC/0eMql5ErqmSqw d/LhAffj58tQGHFxWdNPsFh5vP4pjlmI4VTFTKpah4VMVp2+ud/mOqigNdePWGIIMqGd lS5dk0XMSAgJUcbCOFycFaVIHYo0x7n13o7/Zk52eAuFBz78M+nZwDiTzwC0vJJvhVtj VrOhoYkY6pkbGolXrKMGOnqOFYJ6E+sJgFI4oK6fcyteClkWq2ogGrj4lGmky2KlAp4I r40L9+ciZ+yH/8VuD5gYTR8mNKApO9sayD90bX9KnMKV8/1Ttydmbod2w4sn2wNSAtnw NMnw== MIME-Version: 1.0 X-Received: by 10.68.164.69 with SMTP id yo5mr3681052pbb.96.1374014262191; Tue, 16 Jul 2013 15:37:42 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 16 Jul 2013 15:37:42 -0700 (PDT) In-Reply-To: <51E5A306.5080907@gmail.com> References: <51E5A306.5080907@gmail.com> Date: Tue, 16 Jul 2013 15:37:42 -0700 Message-ID: From: Andy Bierman To: Melinda Shore Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnzEUUaGkJ5f9c46RV4TAG/GxqCFIWgbl6QcL7dK1PmUxHZ044BbHfNfDfcyCTEghSVWNAr Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] On the use of meeting time X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 22:37:48 -0000 On Tue, Jul 16, 2013 at 12:46 PM, Melinda Shore wrote: > We've been getting a lot of requests for time on the agenda for > the upcoming meeting to "present" drafts which haven't been > discussed on the mailing list. This is a reminder that the purpose > of meetings is face-to-face discussion of issues that haven't > been able to make progress on the mailing list, and to progress > deliverables. The IETF is somewhat different from other standards > bodies in that meeting time is generally not used for presentation > of new material, and that the work of the organization is primarily > done via working group mailing lists. The most reliable way to > get time on a meeting agenda is to have a lively discussion on > the mailing list prior to the meeting. > I applaud your attempt to turn back the clock to when people actually read all the drafts before a meeting (no wifi or slideware meant there were no other options). A bold policy would be to ask the room how many people have read a draft, and then actually pull the plug on the agenda item if the WG chairs decide not enough people have read it. > Thanks, > > Melinda Andy From zehn.cao@gmail.com Thu Jul 18 20:36:46 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1C011E8278 for ; Thu, 18 Jul 2013 20:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzRQULf8fi2F for ; Thu, 18 Jul 2013 20:36:46 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 22FCD11E8277 for ; Thu, 18 Jul 2013 20:36:42 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so3605336wes.9 for ; Thu, 18 Jul 2013 20:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sQdvc+r7otD3aND1uk1YfTz454PwKV3wCigSsmRDqIc=; b=SA9F7wgC8oUlNyKoSxpBIFWZls0J+cdXDMnyS0ck+rkfEeFyz+sRRLHC78cOClU984 zuGpVuegmlElUuAbEqubMlLKEgDe0f8kDyZoMR4z7oSREgeb22CtRBHEpiuixP/pRx6k TL4bwoY/gf6CUMzXrxcqncYz8Nr1Xe9yBFDKJPEQlHmVBTErxkmQYfGz18f1Om1fe4Sw j4ZVwnp7wwyNcyaEweqgaQ/olJeLhP2OHFn1iX8MDwHbq05txAJXOgXfk1+vsnfDNlmB e3t77NQTqHigXsfKyw9jWDiDLI6OSOUwDrhO8ePxoEhhi550pCEYRQwBKlS+qV3+/gTP QYRQ== MIME-Version: 1.0 X-Received: by 10.194.58.11 with SMTP id m11mr10719149wjq.45.1374205002280; Thu, 18 Jul 2013 20:36:42 -0700 (PDT) Received: by 10.216.77.131 with HTTP; Thu, 18 Jul 2013 20:36:42 -0700 (PDT) Date: Fri, 19 Jul 2013 11:36:42 +0800 Message-ID: From: "Cao,Zhen" To: opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 03:36:46 -0000 Hello Everyone, The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) with a new title and a new methodology, based on review of multiple experts recommended by OPS ADs. Here is a highlight of the update in this version: The current draft proposes to split data and control plane by having two elements AC-CP and AC-DP. AC-DP handles all user payload with the exception of layer 2 management frames between the AC and use such as IEEE 802.11 association, authentication, probe, Action Frame. AC-CP handles all control messages between the WTP and AC. In addition, the AC-CP will handle user payload related to layer-2 management frames such as those mentioned above. The WTP will have one set of Control and Data Tunnel to AC-CP and another data-tunnel to AC-DP. The key difference from the previous version is that the previous draft suggested 1) AC-CP has a control and data channel (instead of only a control channel in current draft) 2) EAP messages were sent on Control Channel (instead of Data channel in current draft) We also do an analyze of CAPWAP local bridge model to support such scenarios, as recommended by Dorothy. Thank ALL that reviewed the draft and looking forward to your new comments. Best regards, -cz On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen wrote: > FYI. > > > ---------- Forwarded message ---------- > From: > Date: Sun, Jul 14, 2013 at 8:50 PM > Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Separation of CAPWAP Control and Data Plane: > Scenarios, Requirements and Solutions > Author(s) : Rong Zhang > Zhen Cao > Hui Deng > Rajesh S. Pazhyannur > Sri Gundavelli > Filename : draft-zhang-opsawg-capwap-cds-00.txt > Pages : 8 > Date : 2013-07-14 > > Abstract: > This document describes the scenarios and requirements of separating > CAPWAP Data and Control plane. This specification provides a CAPWAP > extension to allow two distinct AC component: AC-DP (AC-Data Plane) > and AC-CP (AC-Control Plane). AC-DP handles all user payload with > the exception of layer 2 management frames between the AC and user > such as IEEE 802.11 association, authentication, probe, Action Frame. > AC-CP handles all control messages between the WTP and AC. In > addition, the AC-CP wil handle user payload related to layer-2 > management frames such as those mentioned above. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From maxpassion@gmail.com Fri Jul 19 01:56:26 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3511E8205 for ; Fri, 19 Jul 2013 01:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJS5HfLQXfsp for ; Fri, 19 Jul 2013 01:56:25 -0700 (PDT) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFE611E81F3 for ; Fri, 19 Jul 2013 01:56:25 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e15so3050844vbg.17 for ; Fri, 19 Jul 2013 01:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IDew/E/GTurSC/ggfLd0HwYiloupCX/0TIRicsJcBZk=; b=Wl4Bb3z+hwhNLOT5AUtVCtXiitCsBLzPNUFWLib1edsXWeKP4O3fYJeePVQupDJM+u 1FXRR2aoB1fZCWYvrsFWWCXhfP6unD6l+CS4bClg4ffwtAHbN42eADawp2zQm3AQ9oEK aehQMb5XLfEx4h5c5Mj8HF2/zxBEYMS6XOQ3v3Tf6dumzNsGppffPkOijX09nc25mF59 I0X5o12pFITqMSytel1Cpns242ht2v1Izwh4Y1QbpmUnSXB67/D0Oy5L9WHJ/VDKp+To FaDYiVT9lhlhlkG0j2jLI4c2neFAiUv6j+aZxHGLI7G6SaDunoSLjZjTOkKVB+0OnZC0 kBug== MIME-Version: 1.0 X-Received: by 10.220.123.195 with SMTP id q3mr5348156vcr.64.1374224183367; Fri, 19 Jul 2013 01:56:23 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Fri, 19 Jul 2013 01:56:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jul 2013 16:56:23 +0800 Message-ID: From: Liu Dapeng To: "Cao,Zhen" Content-Type: multipart/alternative; boundary=089e013cb7284a9d6404e1d98057 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:56:26 -0000 --089e013cb7284a9d6404e1d98057 Content-Type: text/plain; charset=ISO-8859-1 Hi Zhen, The update of the draft actually proposes a way of encapsulating any new controlling messages to an independent CAPWAP Data tunnel. This way is straightforward, but do you think there is a need of signaling and selection of multiple Data tunnels on the WTP? Regards, Dapeng Liu 2013/7/19 Cao,Zhen > Hello Everyone, > > The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of > draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) with > a new title and a new methodology, based on review of multiple experts > recommended by OPS ADs. > > Here is a highlight of the update in this version: > > The current draft proposes to split data and control plane by having > two elements AC-CP and AC-DP. AC-DP handles all user payload with the > exception of layer 2 management frames between the AC and use such as > IEEE 802.11 association, authentication, probe, Action Frame. AC-CP > handles all control messages between the WTP and AC. In addition, the > AC-CP will handle user payload related to layer-2 management frames > such as those mentioned above. The WTP will have one set of Control > and Data Tunnel to AC-CP and another data-tunnel to AC-DP. > > The key difference from the previous version is that the previous > draft suggested > 1) AC-CP has a control and data channel (instead of only a control > channel in current draft) > 2) EAP messages were sent on Control Channel (instead of Data channel > in current draft) > > We also do an analyze of CAPWAP local bridge model to support such > scenarios, as recommended by Dorothy. > > Thank ALL that reviewed the draft and looking forward to your new comments. > > Best regards, > -cz > > On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen wrote: > > FYI. > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Sun, Jul 14, 2013 at 8:50 PM > > Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Separation of CAPWAP Control and Data Plane: > > Scenarios, Requirements and Solutions > > Author(s) : Rong Zhang > > Zhen Cao > > Hui Deng > > Rajesh S. Pazhyannur > > Sri Gundavelli > > Filename : draft-zhang-opsawg-capwap-cds-00.txt > > Pages : 8 > > Date : 2013-07-14 > > > > Abstract: > > This document describes the scenarios and requirements of separating > > CAPWAP Data and Control plane. This specification provides a CAPWAP > > extension to allow two distinct AC component: AC-DP (AC-Data Plane) > > and AC-CP (AC-Control Plane). AC-DP handles all user payload with > > the exception of layer 2 management frames between the AC and user > > such as IEEE 802.11 association, authentication, probe, Action Frame. > > AC-CP handles all control messages between the WTP and AC. In > > addition, the AC-CP wil handle user payload related to layer-2 > > management frames such as those mentioned above. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- ------ Best Regards, Dapeng Liu --089e013cb7284a9d6404e1d98057 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Zhen,

The update of the draft actually proposes a way of encapsulating any new controlling messages to an independ= ent CAPWAP Data tunnel. This way is straightforward, but do you think there is = a need of signaling and selection of multiple Data tunnels on the WTP?=A0


Regards,

Dapeng Liu



2013/7/19 Cao= ,Zhen <zehn.cao@gmail.com>
zehn.cao@gmail.com> wrote:
> FYI.
>
>
> ---------- Forwarded message ----------
> From: =A0<internet-draf= ts@ietf.org>
> Date: Sun, Jul 14, 2013 at 8:50 PM
> Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt
> To: i-d-announce@ietf.org=
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Separation of CAPWAP Contr= ol and Data Plane:
> Scenarios, Requirements and Solutions
> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Rong Zhang
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Zhen Cao
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hui Deng
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rajesh S. Pazhyann= ur
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sri Gundavelli
> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-zhang-opsawg-capwap-cd= s-00.txt
> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-14
>
> Abstract:
> =A0 =A0This document describes the scenarios and requirements of separ= ating
> =A0 =A0CAPWAP Data and Control plane. =A0This specification provides a= CAPWAP
> =A0 =A0extension to allow two distinct AC component: AC-DP (AC-Data Pl= ane)
> =A0 =A0and AC-CP (AC-Control Plane). =A0AC-DP handles all user payload= with
> =A0 =A0the exception of layer 2 management frames between the AC and u= ser
> =A0 =A0such as IEEE 802.11 association, authentication, probe, Action = Frame.
> =A0 =A0AC-CP handles all control messages between the WTP and AC. =A0I= n
> =A0 =A0addition, the AC-CP wil handle user payload related to layer-2<= br> > =A0 =A0management frames such as those mentioned above.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-zhang-opsawg-= capwap-cds
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cd= s-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg



--

------Best Regards,
Dapeng Liu
--089e013cb7284a9d6404e1d98057-- From pinkmgo@sina.com Sat Jul 20 01:12:55 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64CD21E808E for ; Sat, 20 Jul 2013 01:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.691 X-Spam-Level: *** X-Spam-Status: No, score=3.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN4A6eULKZVn for ; Sat, 20 Jul 2013 01:12:48 -0700 (PDT) Received: from mail228-170.sinamail.sina.com.cn (mail228-170.sinamail.sina.com.cn [60.28.228.170]) by ietfa.amsl.com (Postfix) with ESMTP id A7F7821E804B for ; Sat, 20 Jul 2013 01:12:44 -0700 (PDT) Received: from unknown (HELO webmail.sinamail.sina.com.cn) ([172.16.201.97]) by irtj11-84.sinamail.sina.com.cn with ESMTP; 20 Jul 2013 16:12:35 +0800 Received: by webmail.sinamail.sina.com.cn (Postfix, from userid 80) id 7CA88301E9; Sat, 20 Jul 2013 16:12:35 +0800 (CST) Date: Sat, 20 Jul 2013 16:12:35 +0800 Received: from pinkmgo@sina.com([10.79.101.3]) by m0.mail.sina.com.cn via HTTP; Sat, 20 Jul 2013 16:12:35 +0800 (CST) From: "Chris Sun" To: "fanpeng" , "opsawg" MIME-Version: 1.0 X-Priority: 3 X-MessageID: 1374307955.4905.4062 X-Originating-IP: [172.16.201.97] X-Mailer: Sina WebMail 4.0 Content-Type: multipart/alternative; boundary="=-sinamail_alt_8e85e90572c15717b75b79844789ecdb" Message-Id: <20130720081235.7CA88301E9@webmail.sinamail.sina.com.cn> Subject: [OPSAWG] =?gbk?b?16q3oqO6Rlc6INeqt6I6IE5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?gbk?q?tion_for_draft-fan-opsawg-packet-loss-01=2Etxt?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pinkmgo@sina.com List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 08:12:55 -0000 --=-sinamail_alt_8e85e90572c15717b75b79844789ecdb Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgUGVuZyANCgoNClRoaXMncyBDaHJpcywgYXMgYSB0ZWNobmljYWwgZW5naW5lZXIgLA0KVGhh bmtzIGZvciB5b3Ugc2hhcmluZyB0aGlzIG5ldHdvcmsgdHJhZmZpYyByZWxpYWJpbGl0eSBtZWFz dXJlbWVudCBtZWFucyBiZXN0IHByYWN0aWNlIGZvciB1cyAsDQpBcyBJIGtub3csIHdlIGFsd2F5 cyB1c2UgdGhlIHBhY2tldCBsb3NzIHJhdGUgdG8gcHJlc2VudCB0aGUgcXVhbGl0eSBhYm91dCBs aXZlIG5ldHdvcms7IA0KdGhhdCdzIGEgdXN1YWwgdG9vbHMgYXMgInBpbmcgdmlhIGNsaSIgYW5k ICJzbm1wIiBmcm9tIE5NUyBtb25pdG9yICwgDQp0aGUgZHJhZnQgbWVudGlvbiB0aGF0IHRoZSBt dWx0LWJlaGF2aW9yIGFib3V0IHBpbmcgb24gcm91dGUgcGxhdGZvcm0gaXMgc28gdXNlZnVsIDsN Cml0IGNvdWxkIGxldCBtZSB1bmRlcnN0YW5kaW5nIHRoZSBkZXRhaWwgcHJvY2VzcyBhbmQgYSBj bGVhciByZXN1bHRpbmcgLCBpdCBjb3VsZCB0cmlnZ2VyIEkgdXNlIGEgY29sbGVjdCBtZXRob2Qg dG8gZXZhbHVhdGUgbXkgbmV0d29yayByZWxpYWJpbGl0eSBhbmQgcXVhbGl0eSAuDQoKDQoKDQpC UnMNCkNocmlzIFN1biAKDQoKPgo+t6K8/sjLOiBGYW4gUGVuZyBbbWFpbHRvOmZhbnBlbmdAY2hp bmFtb2JpbGUuY29tXQo+t6LLzcqxvOQ6IDIwMTPE6jfUwjXI1SAyMjo1Ngo+ytW8/sjLOiBvcHNh d2dAaWV0Zi5vcmcKPtb3zOI6IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxLnR4dAo+Cj5EZWFyIGFsbCwKPgo+V2UgaGF2ZSB1 cGRhdGVkIGEgY29tcGxldGUgcmV2aXNpb24gdG8gdGhlIEktRCByZWdhcmRpbmcgcGFja2V0IGxv c3MKPm1lYXN1cmVtZW50ICwgYW5kIHdvdWxkIGxpa2UgdG8gZ2V0IGZlZWRiYWNrIGZyb20geW91 Ogo+Cj5JUCBQYWNrZXQgTG9zcyBSYXRlIE1lYXN1cmVtZW50IFRlc3RpbmcgYW5kIFByb2JsZW0g U3RhdGVtZW50Cj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYW4tb3BzYXdnLXBh Y2tldC1sb3NzLTAxCj4KPlRoZSBkb2N1bWVudCBhaW1zIHRvIHJldmlldyBtZXRob2RzIGZvciBw YWNrZXQgbG9zcyByYXRlIG1lYXN1cmVtZW50IGFuZAo+cHJvYmxlbXMgd2l0aCB0aGVtLCBhbmQg cHJvdmlkZSBzb21lIGd1aWRlbGluZXMgd2hlbiBwZXJmb3JtaW5nIHRoZQo+bWVhc3VyZW1lbnQu IFRoZSBkb2N1bWVudCBpcyBiYXNlZCBvbiBvcGVyYXRpb25hbCBleHBlcmllbmNlIGFuZCBuZWVk cwo+ZXNwZWNpYWxseSB3aGVuIGRvaW5nIHBlcmZvcm1hbmNlIG1vbml0b3Jpbmcgb24gdGhlIGlu dGVyY29ubmVjdGluZyBsaW5rCj5iZXR3ZWVuIHR3byBwcm92aWRlcnMnIG5ldHdvcmtzLiBXZSBh bHNvIGhvcGUgd2UgY2FuIGZpbmQgYWZ0ZXIgdGhlCj5kaXNjdXNzaW9uIGEgbWVhc3VyZW1lbnQg c2NoZW1lIHRoYXQgaXMgY29udmVuaWVudCBlbm91Z2ggYW5kIHByb3ZpZGVzCj5jb25zaXN0ZW50 IHJlc3VsdHMuCj4KPkFueSBjb21tZW50IHdvdWxkIGJlIGFwcHJlY2lhdGVkLiBUaGFuayB5b3Uh Cj4KPlJlZ2FyZHMsCj5QZW5nCj4KPgo+LS0tLS3Tyrz+1K28/i0tLS0tCj63orz+yMs6IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10KPrei y83KsbzkOiAyMDEzxOo31MI1yNUgMjE6NDQKPsrVvP7IyzogUGVuZyBGYW47IE1hY2ggQ2hlbjsg THUgSHVhbmc7IE1hY2ggKEd1b3lpKSBDaGVuOyBOYWdlbmRyYSBLdW1hcgo+1vfM4jogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxLnR4 dAo+Cj4KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3Nz LTAxLnR4dAo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQZW5nIEZhbiBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGCj5yZXBvc2l0b3J5Lgo+Cj5GaWxlbmFtZToJIGRyYWZ0LWZhbi1v cHNhd2ctcGFja2V0LWxvc3MKPlJldmlzaW9uOgkgMDEKPlRpdGxlOgkJIElQIFBhY2tldCBMb3Nz IFJhdGUgTWVhc3VyZW1lbnQgVGVzdGluZyBhbmQgUHJvYmxlbSBTdGF0ZW1lbnQKPkNyZWF0aW9u IGRhdGU6CSAyMDEzLTA3LTA1Cj5Hcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24KPk51bWJl ciBvZiBwYWdlczogMTUKPlVSTDogICAgICAgICAgICAgCj5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxLnR4dAo+U3RhdHVz OiAgICAgICAgICAKPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmFuLW9w c2F3Zy1wYWNrZXQtbG9zcwo+SHRtbGl6ZWQ6ICAgICAgICAKPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDEKPkRpZmY6ICAgICAgICAgICAg Cj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mYW4tb3BzYXdnLXBhY2tl dC1sb3NzLTAxCj4KPkFic3RyYWN0Ogo+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgY29tbW9u IG1ldGhvZHMgZm9yIG1lYXN1cmluZyBwYWNrZXQgbG9zcyByYXRlCj4gICBhbmQgdGhlaXIgZWZm ZWN0aXZlbmVzcy4gIElzc3VlcyBlbmNvdW50ZXJlZCB3aGVuIHVzaW5nIHRoZSBtZXRob2RzCj4g ICBhbmQgbmVjZXNzYXJ5IGNvbnNpZGVyYXRpb25zIGFyZSBhbHNvIGRpc2N1c3NlZCBhbmQgcmVj b21tZW5kZWQuCj4KPiAgICAgICAgICAgICAgICAgIAo+ICAgICAgICAKPgo+Cj5UaGUgSUVURiBT ZWNyZXRhcmlhdAo+Cj4KPgo+Cg== --=-sinamail_alt_8e85e90572c15717b75b79844789ecdb Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSBQZW5nJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj4NCjxkaXY+VGhpcydzIENo cmlzLCBhcyBhIHRlY2huaWNhbCBlbmdpbmVlciAsPC9kaXY+DQo8ZGl2PlRoYW5rcyBmb3IgeW91 IHNoYXJpbmcgdGhpcyBuZXR3b3JrIHRyYWZmaWMmbmJzcDtyZWxpYWJpbGl0eSBtZWFzdXJlbWVu dCBtZWFucyBiZXN0IHByYWN0aWNlIGZvciB1cyAsPC9kaXY+DQo8ZGl2PkFzIEkga25vdywgd2Ug YWx3YXlzIHVzZSB0aGUgcGFja2V0IGxvc3MgcmF0ZSB0byBwcmVzZW50IHRoZSBxdWFsaXR5IGFi b3V0IGxpdmUgbmV0d29yazsmbmJzcDs8L2Rpdj4NCjxkaXY+dGhhdCdzIGEgdXN1YWwgdG9vbHMg YXMgInBpbmcgdmlhIGNsaSIgYW5kICJzbm1wIiBmcm9tIE5NUyBtb25pdG9yICwmbmJzcDs8L2Rp dj4NCjxkaXY+dGhlIGRyYWZ0IG1lbnRpb24gdGhhdCB0aGUgbXVsdC1iZWhhdmlvciBhYm91dCBw aW5nIG9uIHJvdXRlIHBsYXRmb3JtIGlzIHNvIHVzZWZ1bCA7PC9kaXY+DQo8ZGl2Pml0IGNvdWxk IGxldCBtZSB1bmRlcnN0YW5kaW5nIHRoZSBkZXRhaWwgcHJvY2VzcyBhbmQgYSBjbGVhciByZXN1 bHRpbmcgLCBpdCBjb3VsZCB0cmlnZ2VyIEkgdXNlIGEgY29sbGVjdCZuYnNwO21ldGhvZCB0byZu YnNwO2V2YWx1YXRlIG15IG5ldHdvcmsmbmJzcDtyZWxpYWJpbGl0eSBhbmQgcXVhbGl0eSAuPC9k aXY+DQo8ZGl2Pjxicj48L2Rpdj4NCjxkaXY+PGJyPjwvZGl2Pg0KPGRpdj5CUnM8L2Rpdj4NCjxk aXY+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxNTAlOyI+Q2hyaXMgU3VuPC9zcGFuPiZuYnNw Ozxicj48L2Rpdj4NCjxkaXYgaWQ9Im9yaWdib2R5Ij48YnI+Jmd0Ozxicj4mZ3Q7t6K8/sjLOiBG YW4gUGVuZyBbbWFpbHRvOmZhbnBlbmdAY2hpbmFtb2JpbGUuY29tXTxicj4mZ3Q7t6LLzcqxvOQ6 IDIwMTPE6jfUwjXI1SAyMjo1Njxicj4mZ3Q7ytW8/sjLOiBvcHNhd2dAaWV0Zi5vcmc8YnI+Jmd0 O9b3zOI6IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mYW4tb3BzYXdn LXBhY2tldC1sb3NzLTAxLnR4dDxicj4mZ3Q7PGJyPiZndDtEZWFyIGFsbCw8YnI+Jmd0Ozxicj4m Z3Q7V2UgaGF2ZSB1cGRhdGVkIGEgY29tcGxldGUgcmV2aXNpb24gdG8gdGhlIEktRCByZWdhcmRp bmcgcGFja2V0IGxvc3M8YnI+Jmd0O21lYXN1cmVtZW50ICwgYW5kIHdvdWxkIGxpa2UgdG8gZ2V0 IGZlZWRiYWNrIGZyb20geW91Ojxicj4mZ3Q7PGJyPiZndDtJUCBQYWNrZXQgTG9zcyBSYXRlIE1l YXN1cmVtZW50IFRlc3RpbmcgYW5kIFByb2JsZW0gU3RhdGVtZW50PGJyPiZndDtodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxPGJyPiZndDs8 YnI+Jmd0O1RoZSBkb2N1bWVudCBhaW1zIHRvIHJldmlldyBtZXRob2RzIGZvciBwYWNrZXQgbG9z cyByYXRlIG1lYXN1cmVtZW50IGFuZDxicj4mZ3Q7cHJvYmxlbXMgd2l0aCB0aGVtLCBhbmQgcHJv dmlkZSBzb21lIGd1aWRlbGluZXMgd2hlbiBwZXJmb3JtaW5nIHRoZTxicj4mZ3Q7bWVhc3VyZW1l bnQuIFRoZSBkb2N1bWVudCBpcyBiYXNlZCBvbiBvcGVyYXRpb25hbCBleHBlcmllbmNlIGFuZCBu ZWVkczxicj4mZ3Q7ZXNwZWNpYWxseSB3aGVuIGRvaW5nIHBlcmZvcm1hbmNlIG1vbml0b3Jpbmcg b24gdGhlIGludGVyY29ubmVjdGluZyBsaW5rPGJyPiZndDtiZXR3ZWVuIHR3byBwcm92aWRlcnMn IG5ldHdvcmtzLiBXZSBhbHNvIGhvcGUgd2UgY2FuIGZpbmQgYWZ0ZXIgdGhlPGJyPiZndDtkaXNj dXNzaW9uIGEgbWVhc3VyZW1lbnQgc2NoZW1lIHRoYXQgaXMgY29udmVuaWVudCBlbm91Z2ggYW5k IHByb3ZpZGVzPGJyPiZndDtjb25zaXN0ZW50IHJlc3VsdHMuPGJyPiZndDs8YnI+Jmd0O0FueSBj b21tZW50IHdvdWxkIGJlIGFwcHJlY2lhdGVkLiBUaGFuayB5b3UhPGJyPiZndDs8YnI+Jmd0O1Jl Z2FyZHMsPGJyPiZndDtQZW5nPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7LS0tLS3Tyrz+1K28/i0t LS0tPGJyPiZndDu3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ108YnI+Jmd0O7eiy83KsbzkOiAyMDEzxOo31MI1yNUgMjE6NDQ8 YnI+Jmd0O8rVvP7IyzogUGVuZyBGYW47IE1hY2ggQ2hlbjsgTHUgSHVhbmc7IE1hY2ggKEd1b3lp KSBDaGVuOyBOYWdlbmRyYSBLdW1hcjxicj4mZ3Q71vfM4jogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxLnR4dDxicj4mZ3Q7PGJyPiZn dDs8YnI+Jmd0O0EgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1s b3NzLTAxLnR4dDxicj4mZ3Q7aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQZW5n IEZhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGPGJyPiZndDtyZXBvc2l0b3J5Ljxicj4mZ3Q7PGJy PiZndDtGaWxlbmFtZToJIGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3M8YnI+Jmd0O1Jldmlz aW9uOgkgMDE8YnI+Jmd0O1RpdGxlOgkJIElQIFBhY2tldCBMb3NzIFJhdGUgTWVhc3VyZW1lbnQg VGVzdGluZyBhbmQgUHJvYmxlbSBTdGF0ZW1lbnQ8YnI+Jmd0O0NyZWF0aW9uIGRhdGU6CSAyMDEz LTA3LTA1PGJyPiZndDtHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+Jmd0O051bWJl ciBvZiBwYWdlczogMTU8YnI+Jmd0O1VSTDogICAgICAgICAgICAgPGJyPiZndDtodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAx LnR4dDxicj4mZ3Q7U3RhdHVzOiAgICAgICAgICA8YnI+Jmd0O2h0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zczxicj4mZ3Q7SHRtbGl6ZWQ6 ICAgICAgICA8YnI+Jmd0O2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZhbi1vcHNh d2ctcGFja2V0LWxvc3MtMDE8YnI+Jmd0O0RpZmY6ICAgICAgICAgICAgPGJyPiZndDtodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAx PGJyPiZndDs8YnI+Jmd0O0Fic3RyYWN0Ojxicj4mZ3Q7ICAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgY29tbW9uIG1ldGhvZHMgZm9yIG1lYXN1cmluZyBwYWNrZXQgbG9zcyByYXRlPGJyPiZndDsg ICBhbmQgdGhlaXIgZWZmZWN0aXZlbmVzcy4gIElzc3VlcyBlbmNvdW50ZXJlZCB3aGVuIHVzaW5n IHRoZSBtZXRob2RzPGJyPiZndDsgICBhbmQgbmVjZXNzYXJ5IGNvbnNpZGVyYXRpb25zIGFyZSBh bHNvIGRpc2N1c3NlZCBhbmQgcmVjb21tZW5kZWQuPGJyPiZndDs8YnI+Jmd0OyAgICAgICAgICAg ICAgICAgIDxicj4mZ3Q7ICAgICAgICA8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDtUaGUgSUVURiBT ZWNyZXRhcmlhdDxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPjwvZGl2Pg== --=-sinamail_alt_8e85e90572c15717b75b79844789ecdb-- From ross@eircom.net Sun Jul 21 14:52:56 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424EC11E8107 for ; Sun, 21 Jul 2013 14:52:51 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWpzgDxfE+-k for ; Sun, 21 Jul 2013 14:52:45 -0700 (PDT) Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by ietfa.amsl.com (Postfix) with SMTP id A373811E8109 for ; Sun, 21 Jul 2013 14:52:44 -0700 (PDT) Received: (qmail 10918 messnum 2751437 invoked from network[213.94.190.11/avas00.vendorsvc.cra.dublin.eircom.net]); 21 Jul 2013 21:52:38 -0000 Received: from avas00.vendorsvc.cra.dublin.eircom.net (213.94.190.11) by mail00.svc.cra.dublin.eircom.net (qp 10918) with SMTP; 21 Jul 2013 21:52:38 -0000 Received: from mac1.home.ross.net ([159.134.196.35]) by avas00.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id 39sb1m0070mJ9Tz019seah; Sun, 21 Jul 2013 22:52:38 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ross Chandler In-Reply-To: Date: Sun, 21 Jul 2013 22:52:35 +0100 Content-Transfer-Encoding: 7bit Message-Id: <365ED714-C8D2-4120-8DCF-AD4E6F80EDD0@eircom.net> References: To: "opsawg@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [OPSAWG] draft-ietf-opsawg-lsn-deployment X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 21:52:58 -0000 Victor, Forwarding this to the list. Best regards Ross On 18 Jul 2013, at 05:30, Victor Kuarsingh wrote: > Ross, > > Thanks for review and sorry for the delay in response. I have some > responses in-line. I would not mind if you sent this exchange to the list > so the working group can see the comments (yours and responses from me). > I can do it as well if you are ok with that. > > On 2013-06-28 9:01 PM, "Ross Chandler" wrote: > >> >> Hello, >> >> I have some questions and feedback on the draft based on a CGN VPN >> solution I >> saw from a router vendor that I think fits in well with our existing >> RADIUS >> based service profile selection at the BNG. > > [VK] Good to hear > >> >> Section 4.1 Service Separation states that IPv4 flows requiring >> translation can >> be separated from traditional IPv4 flows at the initial layer 3 service >> point. >> Are you thinking about pre-separation of the service types in the L2 >> Access Node >> using different S-VLANs coming in from the L2 Access Node? Implementing >> this >> separation could involve extra configuration between the L2 access Node >> and the >> BNG and reduce the flexibility for switching the same user between >> translated >> and traditional unshared services. > > [VK] It is true that the text suggests that L2 separation to steer > traffic is a mode of operation. This is implementable on various access > technologies. That being said, given operator by operator analysis, other > options can be used. Operators can use other techniques to get traffic > into a separate routing context if they wish. > > The technique described (as integrated in our own labs and production) > worked quite well (DOCSIS, Wireless, PON). > > We did keep the document at the architectural level and allowed > readers/operators to consider the system option as a whole. Starting to > state the details at length may draw out the document. > > >> >> I believe separation using policy routing signalled in the RADIUS accept >> can be >> used. It's not clear to me if that case is being covered by the draft. > > [VK] Did did not get into the details of the backend mechanics of how > traffic can be steered. I guess it's possible for me/us to describe the > details of how one can do it with DSL/RADIUS, DOCSIS/DHCP and > 3GPP/RADIUS/HSS etc. The original intent was not to get into those > specific details. Always open to suggestions. > >> >> >> The Internal Service Delivery (4.2) section of the draft mentions a first >> method >> of route leaking between the CGN VRF and the GRT without discussing how >> it >> works. > > [VK] You are correct. If you feel specific text is required, I can > generate some. As a reader of the draft, the expectation was the the > person know MPLS/VPNs, or reviews the citation to RFC4364. I agree Route > leaking is not really covered there. > > >> >> The RADIUS server returns a profile for translation service for the >> user which has an associated policy that policy routes based on >> destination IP. >> If the destination is to an internal service, the next-hop is not changed >> and >> the traffic continues within the GRT along with IPv6 traffic. If the >> destination is not an internal service the traffic is diverted into the >> CGN VRF >> via an "indirect" route to the CGN via the next-hop address leaked from >> the >> BGP/MPLS IP VPN. > > > [VK] Do you think text like this is useful for this document? > > Regards, > > Victor K > >> >> >> Best regards >> Ross Chandler >> Eircom > > From fanpeng@chinamobile.com Sun Jul 21 20:58:52 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8ECA21F8468 for ; Sun, 21 Jul 2013 20:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.244 X-Spam-Level: **** X-Spam-Status: No, score=4.244 tagged_above=-999 required=5 tests=[AWL=-3.014, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dp3j86sXR91 for ; Sun, 21 Jul 2013 20:58:48 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 3004121F9622 for ; Sun, 21 Jul 2013 20:58:46 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee251ecadb0d67-75d67; Mon, 22 Jul 2013 11:57:37 +0800 (CST) X-RM-TRANSID: 2ee251ecadb0d67-75d67 Received: from X6X8D79D8F49E2 (unknown[10.2.43.115]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee251ecadaf924-7a312; Mon, 22 Jul 2013 11:57:37 +0800 (CST) X-RM-TRANSID: 2ee251ecadaf924-7a312 From: "Fan, Peng" To: , "'opsawg'" Date: Mon, 22 Jul 2013 11:59:40 +0800 Message-ID: <001a01ce868f$e4571280$ad053780$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01CE86D2.F27CC380" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6Gh2pN6PS+m9zERl6SFg5NxIERiQ== Content-Language: zh-cn Subject: Re: [OPSAWG] =?gb2312?b?16q3oqO6Rlc6INeqt6I6IE5ldyBWZXJzaW9uIE5vdGlm?= =?gb2312?b?aWNhdGlvbiBmb3IgZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9z?= =?gb2312?b?cy0wMS50eHQ=?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:58:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001B_01CE86D2.F27CC380 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 Thanks for your comment. In the current version we discuss a lot about = using ping as a performance monitoring tool and problems in practical use. Personally, active measurement is rather a limited way to try to = estimate performance, especially when relatively accurate estimation is wanted, = as it is difficult to guarantee that the measurement traffic has the same experience as service traffic to be measured. =20 So we are thinking that we might have to develop a new measurement = scheme or extend an existing protocol (say BFD?) to provide results precise enough = for IP performance monitor. Or we may end up using the packet drop count and other statistics from routers exported by SNMP, though it may not be an agile way. =20 Regards, Peng =20 =B7=A2=BC=FE=C8=CB: Chris Sun [mailto:pinkmgo@sina.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C220=C8=D5 16:13 =CA=D5=BC=FE=C8=CB: fanpeng; opsawg =D6=F7=CC=E2: =D7=AA=B7=A2=A3=BAFW: =D7=AA=B7=A2: New Version = Notification for draft-fan-opsawg-packet-loss-01.txt =20 Hi Peng=20 =20 This's Chris, as a technical engineer , Thanks for you sharing this network traffic reliability measurement = means best practice for us , As I know, we always use the packet loss rate to present the quality = about live network;=20 that's a usual tools as "ping via cli" and "snmp" from NMS monitor ,=20 the draft mention that the mult-behavior about ping on route platform is = so useful ; it could let me understanding the detail process and a clear resulting , = it could trigger I use a collect method to evaluate my network reliability = and quality . =20 =20 BRs Chris Sun=20 > >=B7=A2=BC=FE=C8=CB: Fan Peng [mailto:fanpeng@chinamobile.com] >=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C25=C8=D5 22:56 >=CA=D5=BC=FE=C8=CB: opsawg@ietf.org >=D6=F7=CC=E2: Fwd: New Version Notification for = draft-fan-opsawg-packet-loss-01.txt > >Dear all, > >We have updated a complete revision to the I-D regarding packet loss >measurement , and would like to get feedback from you: > >IP Packet Loss Rate Measurement Testing and Problem Statement >http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01 > >The document aims to review methods for packet loss rate measurement = and >problems with them, and provide some guidelines when performing the >measurement. The document is based on operational experience and needs >especially when doing performance monitoring on the interconnecting = link >between two providers' networks. We also hope we can find after the >discussion a measurement scheme that is convenient enough and provides >consistent results. > >Any comment would be appreciated. Thank you! > >Regards, >Peng > > >-----=D3=CA=BC=FE=D4=AD=BC=FE----- >=B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] >=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C25=C8=D5 21:44 >=CA=D5=BC=FE=C8=CB: Peng Fan; Mach Chen; Lu Huang; Mach (Guoyi) Chen; = Nagendra Kumar >=D6=F7=CC=E2: New Version Notification for = draft-fan-opsawg-packet-loss-01.txt > > >A new version of I-D, draft-fan-opsawg-packet-loss-01.txt >has been successfully submitted by Peng Fan and posted to the IETF >repository. > >Filename: draft-fan-opsawg-packet-loss >Revision: 01 >Title: IP Packet Loss Rate Measurement Testing and Problem Statement >Creation date: 2013-07-05 >Group: Individual Submission >Number of pages: 15 >URL:=20 >http://www.ietf.org/internet-drafts/draft-fan-opsawg-packet-loss-01.txt >Status:=20 >http://datatracker.ietf.org/doc/draft-fan-opsawg-packet-loss >Htmlized:=20 >http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01 >Diff:=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-fan-opsawg-packet-loss-01 > >Abstract: > This document describes common methods for measuring packet loss rate > and their effectiveness. Issues encountered when using the methods > and necessary considerations are also discussed and recommended. > >=20 >=20 > > >The IETF Secretariat > > > > ------=_NextPart_000_001B_01CE86D2.F27CC380 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Chris,

 

Thanks for your comment. In the current version we discuss a lot = about using ping as a performance monitoring tool and problems in = practical use. Personally, active measurement is rather a limited way to = try to estimate performance, especially when relatively accurate = estimation is wanted, as it is difficult to guarantee that the = measurement traffic has the same experience as service traffic to be = measured.

 

So we are thinking that we might have to develop a new measurement = scheme or extend an existing protocol (say BFD?) to provide results = precise enough for IP performance monitor. Or we may end up using the = packet drop count and other statistics from routers exported by SNMP, = though it may not be an agile way.

 

Regards,

Peng

 

=B7=A2=BC=FE=C8=CB: Chris Sun [mailto:pinkmgo@sina.com] =
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C220=C8=D5 = 16:13
=CA=D5=BC=FE=C8=CB: fanpeng; = opsawg
=D6=F7=CC=E2: =D7=AA=B7=A2=A3=BAFW: = =D7=AA=B7=A2: New Version Notification for = draft-fan-opsawg-packet-loss-01.txt

 

Hi Peng 

 

This's Chris, as a technical = engineer ,

Thanks for you sharing this network = traffic reliability measurement means best practice for us = ,

As I know, we always use the packet loss rate to present = the quality about live network; 

that's a usual tools as "ping = via cli" and "snmp" from NMS monitor = , 

the draft mention that the mult-behavior about ping on = route platform is so useful ;

it could let me understanding the = detail process and a clear resulting , it could trigger I use a = collect method to evaluate my network reliability and = quality .

 

 

BRs

Chris = Sun 


>
>=B7=A2=BC=FE=C8=CB: Fan Peng [mailto:fanpeng@chinamob= ile.com]
>=B7=A2=CB=CD=CA=B1=BC=E4: = 2013=C4=EA7=D4=C25=C8=D5 = 22:56
>=CA=D5=BC=FE=C8=CB: opsawg@ietf.org
>=D6=F7=CC= =E2: Fwd: New Version Notification for = draft-fan-opsawg-packet-loss-01.txt
>
>Dear = all,
>
>We have updated a complete revision to the I-D = regarding packet loss
>measurement , and would like to get = feedback from you:
>
>IP Packet Loss Rate Measurement = Testing and Problem Statement
>http:= //tools.ietf.org/html/draft-fan-opsawg-packet-loss-01
>
>= The document aims to review methods for packet loss rate measurement = and
>problems with them, and provide some guidelines when = performing the
>measurement. The document is based on operational = experience and needs
>especially when doing performance monitoring = on the interconnecting link
>between two providers' networks. We = also hope we can find after the
>discussion a measurement scheme = that is convenient enough and provides
>consistent = results.
>
>Any comment would be appreciated. Thank = you!
>
>Regards,
>Peng
>
>
>-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>=B7=A2=BC=FE=C8=CB: = internet-drafts@ietf.org = [mailto:internet-drafts= @ietf.org]
>=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C25=C8=D5 = 21:44
>=CA=D5=BC=FE=C8=CB: Peng Fan; = Mach Chen; Lu Huang; Mach (Guoyi) Chen; Nagendra = Kumar
>=D6=F7=CC=E2: New Version = Notification for = draft-fan-opsawg-packet-loss-01.txt
>
>
>A new version = of I-D, draft-fan-opsawg-packet-loss-01.txt
>has been successfully = submitted by Peng Fan and posted to the = IETF
>repository.
>
>Filename: = draft-fan-opsawg-packet-loss
>Revision: 01
>Title: IP Packet = Loss Rate Measurement Testing and Problem Statement
>Creation = date: 2013-07-05
>Group: Individual Submission
>Number of = pages: 15
>URL:
>http://www.ietf.org/internet-drafts/draft-fan-opsawg-packet-loss-= 01.txt
>Status:
>htt= p://datatracker.ietf.org/doc/draft-fan-opsawg-packet-loss
>Html= ized:
>http:= //tools.ietf.org/html/draft-fan-opsawg-packet-loss-01
>Diff: =
>http://www.ietf.org/rfcdiff?url2=3Ddraft-fan-opsawg-packet-loss-01=
>
>Abstract:
> This document describes common methods = for measuring packet loss rate
> and their effectiveness. Issues = encountered when using the methods
> and necessary considerations = are also discussed and recommended.
>
>
> =
>
>
>The IETF = Secretariat
>
>
>
>

------=_NextPart_000_001B_01CE86D2.F27CC380-- From rzhang.ietf@gmail.com Tue Jul 23 18:50:30 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80EE11E8214 for ; Tue, 23 Jul 2013 18:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yVU1UjhGYvu for ; Tue, 23 Jul 2013 18:50:30 -0700 (PDT) Received: from mail-ob0-x242.google.com (mail-ob0-x242.google.com [IPv6:2607:f8b0:4003:c01::242]) by ietfa.amsl.com (Postfix) with ESMTP id 832DB11E81C9 for ; Tue, 23 Jul 2013 18:50:28 -0700 (PDT) Received: by mail-ob0-f194.google.com with SMTP id v19so2433557obq.9 for ; Tue, 23 Jul 2013 18:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kFmMtMr/1oEE7jp+2O3TFV47nETKCnFmdBFci8mdhSw=; b=EgaAyUdUdXPE4t6uxzc8bMBWq3wvSU1q8bn+9eQ7YhXztHZbliWsNFtLq3ytSnvAWn awUrz75/QhevkgTAt7/SjcOTCSTJVtnwB8J4Takiuwqr+cF/Xps82btm/7MErnlIEOH+ xa4xYB7huGq9En8m7l7glykqcXu/5sTe8TC5xrsHFOSsk2EVvs9i1f2e1dqetRqKNk0e d6nJ8V4AcSkxygTrHDeJJm4Qt9y896EW7Ey0LlUyeVBOODinMsjRSbHCpEtDTYKbqf2X feJpuq1WK41Pbx8VRUoWsAIz2U0yUL4Vg1+1QihhRK6yJZ/AcEohXNmey2gVbTgTpm9S qyww== MIME-Version: 1.0 X-Received: by 10.182.241.71 with SMTP id wg7mr28033874obc.50.1374630627965; Tue, 23 Jul 2013 18:50:27 -0700 (PDT) Received: by 10.76.127.243 with HTTP; Tue, 23 Jul 2013 18:50:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 09:50:27 +0800 Message-ID: From: Rong Zhang To: "Cao,Zhen" Content-Type: multipart/alternative; boundary=001a11c2e0f047002c04e23822d8 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 01:50:30 -0000 --001a11c2e0f047002c04e23822d8 Content-Type: text/plain; charset=ISO-8859-1 Prefer the method of utilizing the current capability other than changing the specs. Regards. Rong On Fri, Jul 19, 2013 at 11:36 AM, Cao,Zhen wrote: > Hello Everyone, > > The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of > draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) with > a new title and a new methodology, based on review of multiple experts > recommended by OPS ADs. > > Here is a highlight of the update in this version: > > The current draft proposes to split data and control plane by having > two elements AC-CP and AC-DP. AC-DP handles all user payload with the > exception of layer 2 management frames between the AC and use such as > IEEE 802.11 association, authentication, probe, Action Frame. AC-CP > handles all control messages between the WTP and AC. In addition, the > AC-CP will handle user payload related to layer-2 management frames > such as those mentioned above. The WTP will have one set of Control > and Data Tunnel to AC-CP and another data-tunnel to AC-DP. > > The key difference from the previous version is that the previous > draft suggested > 1) AC-CP has a control and data channel (instead of only a control > channel in current draft) > 2) EAP messages were sent on Control Channel (instead of Data channel > in current draft) > > We also do an analyze of CAPWAP local bridge model to support such > scenarios, as recommended by Dorothy. > > Thank ALL that reviewed the draft and looking forward to your new comments. > > Best regards, > -cz > > On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen wrote: > > FYI. > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Sun, Jul 14, 2013 at 8:50 PM > > Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Separation of CAPWAP Control and Data Plane: > > Scenarios, Requirements and Solutions > > Author(s) : Rong Zhang > > Zhen Cao > > Hui Deng > > Rajesh S. Pazhyannur > > Sri Gundavelli > > Filename : draft-zhang-opsawg-capwap-cds-00.txt > > Pages : 8 > > Date : 2013-07-14 > > > > Abstract: > > This document describes the scenarios and requirements of separating > > CAPWAP Data and Control plane. This specification provides a CAPWAP > > extension to allow two distinct AC component: AC-DP (AC-Data Plane) > > and AC-CP (AC-Control Plane). AC-DP handles all user payload with > > the exception of layer 2 management frames between the AC and user > > such as IEEE 802.11 association, authentication, probe, Action Frame. > > AC-CP handles all control messages between the WTP and AC. In > > addition, the AC-CP wil handle user payload related to layer-2 > > management frames such as those mentioned above. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a11c2e0f047002c04e23822d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Pref= er=A0the=A0method=A0of=A0utilizing=A0the=A0current=A0capability=A0other=A0t= han=A0changing=A0the=A0specs.=A0


Regards.
=A0
Rong
On Fri, Jul 19, 2013 at 11:36 AM, Cao,Zhen <ze= hn.cao@gmail.com> wrote:
Hello Everyone,

The draft-zhan= g-opsawg-capwap-cds-00.txt is an update/subvert of
draft-zhang-opsawg-ca= pwap-eap-00 (which we presented on Orlando) with
a new title and a new methodology, based on review of multiple experts
r= ecommended by OPS ADs.

Here is a highlight of the update in this ver= sion:

The current draft proposes to split data and control plane by = having
two elements AC-CP and AC-DP. AC-DP handles all user payload with the
ex= ception of layer 2 management frames between the AC and use such as
IEEE= 802.11 association, authentication, probe, Action Frame. AC-CP
handles = all control messages between the WTP and AC. =A0In addition, the
AC-CP will handle user payload related to layer-2 management frames
such= as those mentioned above. The WTP will have one set of Control
and Data= Tunnel to AC-CP and another data-tunnel to AC-DP.

The key differenc= e from =A0the previous version is that the previous
draft suggested
1) AC-CP has a control and data channel (instead of only= a control
channel in current draft)
2) EAP messages were sent on Con= trol Channel (instead of Data channel
in current draft)

We also d= o an analyze of CAPWAP local bridge model to support such
scenarios, as recommended by Dorothy.

Thank ALL that reviewed the dr= aft and looking forward to your new comments.

Best regards,
-cz
On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen <zehn.cao@gmail.com> wrote:
> FYI.
>
>
> ---------- Forwarded message ----------> From: =A0<internet-drafts@ietf.org>
> Date: Sun, Jul 14, 2013 at = 8:50 PM
> Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt
> To: = i-d-announce@iet= f.org
>
>
>
> A New Internet-Draft is available= from the on-line Internet-Drafts directories.
>
>
> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Separation= of CAPWAP Control and Data Plane:
> Scenarios, Requirements and Solu= tions
> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Rong Zhang
> = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Zhen Cao
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hui Deng
> = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rajesh S. Pazhyannur> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sri Gundavelli> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-zhang-opsawg-capwap-c= ds-00.txt
> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-14
>
&g= t; Abstract:
> =A0 =A0This document describes the scenarios and requi= rements of separating
> =A0 =A0CAPWAP Data and Control plane. =A0This= specification provides a CAPWAP
> =A0 =A0extension to allow two distinct AC component: AC-DP (AC-Data Pl= ane)
> =A0 =A0and AC-CP (AC-Control Plane). =A0AC-DP handles all user= payload with
> =A0 =A0the exception of layer 2 management frames bet= ween the AC and user
> =A0 =A0such as IEEE 802.11 association, authentication, probe, Action = Frame.
> =A0 =A0AC-CP handles all control messages between the WTP an= d AC. =A0In
> =A0 =A0addition, the AC-CP wil handle user payload rela= ted to layer-2
> =A0 =A0management frames such as those mentioned above.
>
>= ;
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds=
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00=
>
>
> Internet-Drafts are also available by anonymous FTP at= :
> ftp://ftp.ietf.org/internet-drafts/
>
> __________________= _____________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.= ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt
_______________________________________________
OPSAWG mailing list
<= a href=3D"mailto:OPSAWG@ietf.org" target=3D"_blank">OPSAWG@ietf.org
= = https://www.ietf.org/mailman/listinfo/opsawg

--001a11c2e0f047002c04e23822d8-- From rpazhyan@cisco.com Tue Jul 23 21:40:10 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB43E11E81DF for ; Tue, 23 Jul 2013 21:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-M0pfHWwcTF for ; Tue, 23 Jul 2013 21:40:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3CD11E81E1 for ; Tue, 23 Jul 2013 21:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4390; q=dns/txt; s=iport; t=1374640805; x=1375850405; h=from:to:subject:date:message-id:mime-version; bh=I9gp4eURGf9gVCIZHRrgKDa9KRV43SYgJhGdfhzfRIo=; b=gpd0ydDjiceMCXgwb46EUV5S1SlCjL7lF3F/QqhLHN91yM1vzwv2TQPU j4q0anPVtGXZO6D5kDV+57xp+AhRHbUPVjZI0Uimjfwxrf3rKLwESoN2l 9WnxHVhIDbg3FiN8vrPnWp/cAppXHKzKn26OVBDbzlC2eC8ZTIp4vpvwI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAL1Z71GtJV2d/2dsb2JhbABbgkJEgQXAf4EUFnSCJgEELV4BCAQeViYBBBuICJd7oDGPSYNKbgOpLIFbgTmCKg X-IronPort-AV: E=Sophos;i="4.89,732,1367971200"; d="scan'208,217";a="238641463" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jul 2013 04:40:03 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6O4e3Vs005157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jul 2013 04:40:03 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 23:40:03 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "opsawg@ietf.org" Thread-Topic: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds Thread-Index: Ac6IJ9EV3NXO+qh4THCnzad/MUxNSA== Date: Wed, 24 Jul 2013 04:40:02 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B431DC0DA44@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.238] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B431DC0DA44xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 04:40:11 -0000 --_000_4ED2E36A22261145861BAB2C24088B431DC0DA44xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Dapeng Yes, you are right that we are proposing that all station generated managem= ent messages are encapsulated within a CAPWAP data tunnel. This is, consist= ent, with existing behavior when the AP is either in Local MAC or Split MAC= mode. There are two options for the non-management related station traff= ic: 1) local bridging and 2) tunneled to a WTP/Access Router. For option 2)= , the WTP will need *another* data tunnel. Further, to maintain the simplic= ity and ease of provisioning of the data tunnel end point, we want the tunn= el end point information to be signaled to the WTP (typically after the con= trol channel is established). In the existing CAPWAP model, the data tunnel= is assumed to have the same IP address as the control channel end point, t= hereby eliminating the need for additional signaling. Hopefully, that clarifies why we need 1) multiple data tunnels and 2) need = additional signaling for the establishment of data tunnel. Regards Rajesh ******************************* Hi Zhen, The update of the draft actually proposes a way of encapsulating any new co= ntrolling messages to an independent CAPWAP Data tunnel. This way is straig= htforward, but do you think there is a need of signaling and selection of m= ultiple Data tunnels on the WTP? Regards, Dapeng Liu ******************************* --_000_4ED2E36A22261145861BAB2C24088B431DC0DA44xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Dapeng
 
Yes, you are right that we are proposing that all station generated ma= nagement messages are encapsulated within a CAPWAP data tunnel. This is, co= nsistent, with existing behavior when the AP is either in Local MAC or Spli= t MAC mode.  There are two options for the non-management related station  traffic: 1) local bridging and= 2) tunneled to a WTP/Access Router. For option 2), the WTP will need *a= nother* data tunnel. Further, to maintain the simplicity and ease of pr= ovisioning of the data tunnel end point, we want the tunnel end point information to be signaled to the WTP (typical= ly after the control channel is established). In the existing CAPWAP model,= the data tunnel is assumed to have the same IP address as the control chan= nel end point, thereby eliminating the need for additional signaling.
 
Hopefully, that clarifies why we need 1) multiple data tunnels and 2) = need additional signaling for the establishment of data tunnel. 
 
Regards
 
Rajesh
*******************************
Hi Zhen,
The update of the draft a= ctually proposes a way of encapsulating any new controlling messages to an = independent CAPWAP Data tunnel. This way is straightforward, but do you think there is a need of signaling and selec= tion of multiple Data tunnels on the WTP? 
Regards,
Dapeng Liu<= /div>
*******************************
 
 
 --_000_4ED2E36A22261145861BAB2C24088B431DC0DA44xmbalnx09ciscoc_-- From rpazhyan@cisco.com Tue Jul 23 21:48:48 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E513A11E81E1 for ; Tue, 23 Jul 2013 21:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k65hAQUq6Wbv for ; Tue, 23 Jul 2013 21:48:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 61AAF11E81DE for ; Tue, 23 Jul 2013 21:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3253; q=dns/txt; s=iport; t=1374641321; x=1375850921; h=from:to:subject:date:message-id:mime-version; bh=Y1m1+KYVsTR68a0vfo9JZfWC0lEGTLxxX2oy2+u2Q4o=; b=UBo6PSesVdF3PX+YUa+lb898FI6outaT0xaB3xqbOAsxNGlsMHCGe2PZ h3HaiRNmePPvYLen0O2uTCNEHupipLgIeugTXcOpsTJP2RS3gvxlK2uz3 Xh/5QYk8liMqnDJld5bGMvRtWB9v7RFNdHeycJOC+t30UMwBayghcvlp1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAG5b71GtJXG8/2dsb2JhbABbgkJEgQXAf4EUFnSCJgEELV4BCAQeViYBBBuICJdzoDKPSYNKbgOpLIFbgTmCKg X-IronPort-AV: E=Sophos;i="4.89,732,1367971200"; d="scan'208,217";a="238596131" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jul 2013 04:48:39 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6O4mdPJ002079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jul 2013 04:48:39 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 23 Jul 2013 23:48:39 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "opsawg@ietf.org" Thread-Topic: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds, Thread-Index: Ac6IKQW7BHVi56aESRicamcKX0tXUw== Date: Wed, 24 Jul 2013 04:48:38 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B431DC0DA61@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.238] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B431DC0DA61xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 04:48:49 -0000 --_000_4ED2E36A22261145861BAB2C24088B431DC0DA61xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rong I am not sure I understand your comment. In a way, the proposed approach of= maintaining a control and data channel with the Access Controller (for all= control and station generated management traffic) is consistent with RFC 5= 416. Specifically, in a Local MAC mode, the AP/WTP would maintain a control and = data channel with the Access Controller and user generated (non-management = traffic) could be locally bridged. Hope this clarifies. Regards Rajesh ********************* Prefer the method of utilizing the current capability other than changing t= he specs. Regards. Rong --_000_4ED2E36A22261145861BAB2C24088B431DC0DA61xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Rong
I am not sure I understand= your comment. In a way, the proposed approach of maintaining a control and= data channel with the Access Controller (for all control and station gener= ated management traffic) is consistent with RFC 5416. 
Specifically, in a Local M= AC mode, the AP/WTP would maintain a control and data channel with the Acce= ss Controller and user generated (non-management traffic) could be locally = bridged.
Hope this clarifies.
Regards
Rajesh
*********************
Pr= efer the method of utilizing the current = ;capability other than changing the specs. 

Regards.
&= nbsp;
R= ong 
 
&nbs= p;
 --_000_4ED2E36A22261145861BAB2C24088B431DC0DA61xmbalnx09ciscoc_-- From rzhang.ietf@gmail.com Wed Jul 24 02:50:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6DB11E83C5 for ; Wed, 24 Jul 2013 02:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4ucVmv7TCiC for ; Wed, 24 Jul 2013 02:50:32 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57411E8156 for ; Wed, 24 Jul 2013 02:50:32 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so443010oag.3 for ; Wed, 24 Jul 2013 02:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=flXLtMvqBjrMRQywDzNbr9cJW1RIqEmuhMuJokmLaNw=; b=TqdqM3DvDMI+eNSsoT6LL8DW5hSLUR0Q2VG3hlUaqgVpSmdoigTBru69Js+WQ0wMQk byPcWdi7CA8u/ejJZHNqRZYFNbA9nWv8lIbxcPIjtWeAY61TZHstL1iGKgX1t8XAeEL/ IKrrb6LZzwilRZuAdqoZopiIIefPQTLwF7g4UYojEeS4TrbucRS+ojtLUBelGTRu5w3V MuYlDCI5n3mzP0PYGk8Oe6rFUkaM8K7MNbHfadFd27aIW/OkqGRBbPck3zp+5KuSecq2 awED8VeYzBPGDhEGIxuPXzW2I4JfPS1gFmEuGeHDp3nGoJJMiOPEJvdpxdleRT5tkRk8 7tHA== MIME-Version: 1.0 X-Received: by 10.182.110.164 with SMTP id ib4mr29047346obb.87.1374659431751; Wed, 24 Jul 2013 02:50:31 -0700 (PDT) Received: by 10.76.127.243 with HTTP; Wed, 24 Jul 2013 02:50:31 -0700 (PDT) In-Reply-To: <4ED2E36A22261145861BAB2C24088B431DC0DA61@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B431DC0DA61@xmb-aln-x09.cisco.com> Date: Wed, 24 Jul 2013 17:50:31 +0800 Message-ID: From: Rong Zhang To: "Rajesh Pazhyannur (rpazhyan)" Content-Type: multipart/alternative; boundary=089e011608841de59004e23ed775 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds, X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:50:34 -0000 --089e011608841de59004e23ed775 Content-Type: text/plain; charset=ISO-8859-1 Hello Rajesh, Thanks for clarification. Yes, i like this update of the draft, as you said, it is consistent with RFC5416. So i am in support of such data and control decoupling. Best regards, Rong. On Wed, Jul 24, 2013 at 12:48 PM, Rajesh Pazhyannur (rpazhyan) < rpazhyan@cisco.com> wrote: > Hello Rong > I am not sure I understand your comment. In a way, the proposed approach > of maintaining a control and data channel with the Access Controller (for > all control and station generated management traffic) is consistent with > RFC 5416. > Specifically, in a Local MAC mode, the AP/WTP would maintain a control and > data channel with the Access Controller and user generated (non-management > traffic) could be locally bridged. > Hope this clarifies. > Regards > Rajesh > ********************* > > Prefer the method of utilizing the current capability other than changing the specs. > > Regards. > > Rong > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > --089e011608841de59004e23ed775 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Rajesh,=A0

Thanks for clarificati= on.=A0

Yes, i like this update of the draft, as yo= u said, it is consistent with RFC5416. So i am in support of such data and = control decoupling.=A0

Best regards,
Rong.=A0

On Wed, Jul 24, 2013 at 12:48 P= M, Rajesh Pazhyannur (rpazhyan) <rpazhyan@cisco.com> wrote:=
Hello Rong
I am not sure I understand = your comment. In a way, the proposed approach of maintaining a control and = data channel with the Access Controller (for all control and station genera= ted management traffic) is consistent with RFC 5416.=A0
Specifically, in a Local MA= C mode, the AP/WTP would maintain a control and data channel with the Acces= s Controller and user generated (non-management traffic) could be locally b= ridged.
Hope this clarifies.
Regards
Rajesh
*********************
Pre= fer=A0the=A0method=A0of=A0utilizing=A0the=A0current=A0capability=A0other=A0= than=A0changing=A0the=A0specs.=A0

= Regards.
= =A0
Ro= ng=A0
=A0
=A0

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg


--089e011608841de59004e23ed775-- From tom.taylor.stds@gmail.com Wed Jul 24 05:56:58 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8A311E80F1 for ; Wed, 24 Jul 2013 05:56:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFwem7rz8o3X for ; Wed, 24 Jul 2013 05:56:58 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3F45B11E80E6 for ; Wed, 24 Jul 2013 05:56:58 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id fb19so12855541obc.37 for ; Wed, 24 Jul 2013 05:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=j8NWMFveqodYua8LCGxLjj5jigD2bMLl49/a9RcHleY=; b=nM0dcezLhE3kfCgPzTfFs8tinc2PlIAuJgB5DD5XO5yjaBvtBzYRXQ/DwEfrutXa2b E7pC2K6hyWj+sq/kPUzO48BvpSDk5GRB1ATdvXS2MYC5r6ue+zzX4GzdLIQGzOSsFgz0 D/GWQn/Pet0d6V7JEk/TFpBAAMup/zDFO1rP2iCpNJm5xTCQvFesXzSV3iZlHwytiJAW TcpoJZ8YB0UZdJSCOjMuQ4LRrHrWuYKYmu/02V5c2pvfD9t10DQ7st922gPcHcZKylm2 0Q+CotUxVcV4SpZjk6ic895/bu8Mv7RJhG7nIDUmYBWUAdnjq0L7vPpnlE3JqCRkP/jj GSuQ== X-Received: by 10.182.213.10 with SMTP id no10mr29745389obc.76.1374670615292; Wed, 24 Jul 2013 05:56:55 -0700 (PDT) Received: from [192.168.1.64] (dsl-173-206-92-228.tor.primus.ca. [173.206.92.228]) by mx.google.com with ESMTPSA id tv3sm48979864obb.8.2013.07.24.05.56.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 05:56:54 -0700 (PDT) Message-ID: <51EFCF13.2070103@gmail.com> Date: Wed, 24 Jul 2013 08:56:51 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "George, Wes" References: <51C07769.5040609@gmail.com> <20130618174012.GA23633@elstar.local> <51C0A3FF.4050302@gmail.com> <04f101ce6c50$fd5877a0$f80966e0$@olddog.co.uk> <2671C6CDFBB59E47B64C10B3E0BD592304348389EC@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592304348389EC@PRVPEXVS15.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Use of DHCP to provision routers X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 12:56:58 -0000 On 18/06/2013 4:42 PM, George, Wes wrote: >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On >> Behalf Of Adrian Farrel Sent: Tuesday, June 18, 2013 2:24 PM To: >> 'Tom Taylor'; opsawg@ietf.org Subject: Re: [OPSAWG] Use of DHCP to >> provision routers >> >> I find it a bit surprising that a backbone network router or a >> router in an access network would benefit from "dynamic" >> configuration. > > [WEG] Well, renumbering would be easier in some cases. Instead of > talking about it in terms of DHCP, you may want to think of it more > in terms of separating the IP from the miscellaneous subtending > configuration that depends on it in something like a router (neighbor > config, ACLs, etc). In other words, why does the IP config need to be > static, what actually breaks? You probably can make a distinction > between things like WAN IPs and things like loopbacks. To go further, > how many of those breakage cases are solved if you can refer to the > device via DNS instead of by IP (yes, this adds a failure domain, > just follow me for a second) or use config that works by pulling the > assigned IP into the right places elsewhere in the config? Not trying > to minimize the scale and other issues with the bootstrapping > problem, just framing the question a little differently. 6renum > definitely spent some time talking about things like parameterized > config and inheritance to address the fact that many IP addresses in > a router affect multiple parts of the config such that you have to > change it multiple places. Also things like ILNP focus on splitting > locator and identifier so that one can change without affecting the > other. Making a network work with dynamically configured addresses > goes in that general direction. But that sort of digresses from the > original question... >> >> At this point, I'd probably like to sit down and think about the >> problem before jumping to use DHCP. >> >> A > [WEG] Generally I agree. In a lot of cases, the problem may be better > solved by proper element management systems to push the right config > to the right places, rather than using DHCP in lieu of such, but > depending on the application, DHCP may be the right level of > lightweight where a heavyweight element management system might not > be the right choice, especially for (lots of ) small devices that are > supposed to boot and configure themselves with little or no human > hand-holding or preconfiguration. > ... I dropped this conversation a bit early. I'm informed that we're really talking about mobile backhaul, not core and access. That suggests we meet Wes's conditions and DHCP is OK for the purpose. Tom Taylor From melinda.shore@gmail.com Wed Jul 24 12:42:19 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB96B11E821B for ; Wed, 24 Jul 2013 12:42:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR94-j-2gC+m for ; Wed, 24 Jul 2013 12:42:19 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id DF49C11E8105 for ; Wed, 24 Jul 2013 12:42:17 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so10023354pbc.23 for ; Wed, 24 Jul 2013 12:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=BMjohpxilpTkRefIpIi79NWuIJStBSj33Ykz2YoHEGw=; b=WXE64Gi60PqqVKdiNZZA58NguX2Nq57vX3eGEjhlpm9sStTEeY8lwN1P/2FofxqUa/ veI3QVm6L5ZKcYrar/RlXexGIeAiBE2s4c2VsRlKvskwxDBp/H8fMDGd/mM1EB2sQxzl D/fo/957IurZTkOy/YMtH02iJyrkKSG6kttPPxBdJzN4i0cz721ioq7ABkFrieNWmcwy tLDMjjIALz3VpUpf62Gvzo7oRLvXN1/B7OtHvWR2ybbgQOUsCJDfvhGRVmaCRNJOsRgj QBggfdxXPn8Kqd7r9JV6Eg5RqKSULY5wl3UmH6gU6oDi2Uka8xASNFulvj5Lx36XDGPf +x3g== X-Received: by 10.66.186.12 with SMTP id fg12mr12179238pac.178.1374694936615; Wed, 24 Jul 2013 12:42:16 -0700 (PDT) Received: from spandex.local (66-230-83-143-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.83.143]) by mx.google.com with ESMTPSA id sp4sm49447806pbc.45.2013.07.24.12.42.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 12:42:15 -0700 (PDT) Message-ID: <51F02E15.9050008@gmail.com> Date: Wed, 24 Jul 2013 11:42:13 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 19:42:19 -0000 This is to announce the start of working group last call on: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ It is intended for publication as a standards track RFC. Please give it a careful read and provide any feedback to this mailing list by July 7, 2013. Thanks, opsawg chairs From melinda.shore@gmail.com Wed Jul 24 20:06:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6A521F93E1 for ; Wed, 24 Jul 2013 20:06:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ackHuwD4KnhH for ; Wed, 24 Jul 2013 20:06:35 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EF05221F93F8 for ; Wed, 24 Jul 2013 20:06:34 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so1124658pdd.20 for ; Wed, 24 Jul 2013 20:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=SmXb2cAwbY0F+tSPWFQq+DlRaqkrlidoM4mQbSfK8xg=; b=PAFBNPII/SYJ4o0MX90qi20oRe6EMpgijCFE22LNNdw61ZU0Riu3QDzRrdor8DjD4u /lQ2CojFB9LiVnnlwsa8GL7jQCfMmGAg0wzIQni6Ums0cJdhW2hmelQfCSY0O5T0ddM/ oaKVkPEtCI74v83LN7gXL1uWEzd0ykNiafrlY59wT8JddvK9/HCv0Nh65HTrbjszQw8r 36EM7XcNbluucshfK0szx8KZrTl1JdMjE5UprvI7iD7ehSPVOh/xSt7WSLTEQ8AzbJiT +bO0PuiMVJPYveU1XJHsFfqejOj+XBbAbRpAudV6ZVWn5HHqfnnPK7fgaHmsRRuJQrwx +q0A== X-Received: by 10.68.239.66 with SMTP id vq2mr45717297pbc.182.1374721594687; Wed, 24 Jul 2013 20:06:34 -0700 (PDT) Received: from spandex.local (66-230-83-143-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.83.143]) by mx.google.com with ESMTPSA id tr10sm51048165pbc.22.2013.07.24.20.06.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 20:06:33 -0700 (PDT) Message-ID: <51F09636.1040102@gmail.com> Date: Wed, 24 Jul 2013 19:06:30 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <51F02E15.9050008@gmail.com> In-Reply-To: <51F02E15.9050008@gmail.com> X-Forwarded-Message-Id: <51F02E15.9050008@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 03:06:35 -0000 X-List-Received-Date: Thu, 25 Jul 2013 03:06:35 -0000 It's been pointed out to me that since July 7 was actually several weeks ago I probably meant to write that the deadline for feedback is *August* 7, 2013, and indeed that's the case. WG last call closes on August 7, 2013. Thanks, Melinda -------- Original Message -------- Subject: Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" Date: Wed, 24 Jul 2013 11:42:13 -0800 From: Melinda Shore To: opsawg@ietf.org This is to announce the start of working group last call on: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ It is intended for publication as a standards track RFC. Please give it a careful read and provide any feedback to this mailing list by July 7, 2013. Thanks, opsawg chairs From melinda.shore@gmail.com Thu Jul 25 20:03:31 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B2D21F8476 for ; Thu, 25 Jul 2013 20:03:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRmaKp2GJxFs for ; Thu, 25 Jul 2013 20:03:30 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DBA2F21F8475 for ; Thu, 25 Jul 2013 20:03:30 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so2387380pdd.20 for ; Thu, 25 Jul 2013 20:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=XwGSw8sVwXxOVa0Jpfbz75DzxuLyZRJENEKK2g8tSOo=; b=Mhyw00pVli6pnrqzeLUh7mmSnWjCZRHkktumdgRXscwS6TJKcs2sHbibiO/JPjszXK 0SAC/d7aJ0PZibZkzYpTT44rOjNWo9svDaAq/WyWoaovIlRm3+5cKBluzpXqpNZpabOL 1DVnvcmzZkzF625f37LlIJPZOLsD832IOK8I9iTVLnkrJYPB6bvpIN0l1D00I6svOuYI R4B1NfMGrRUhfw4UkZ4moyGcdJ/64aE4iDLJC6ZcmmciZO4AWH6Rpoon/3ZzjWptFO6H FUT4JEzpaUgW2Rn3/yGzIPd6Q+Iym+RYtzqDRJ/JZHvL54iqC1bCurkiNvKka7HCSmFO 2v3A== X-Received: by 10.68.28.232 with SMTP id e8mr51738367pbh.94.1374807810441; Thu, 25 Jul 2013 20:03:30 -0700 (PDT) Received: from spandex.local (66-230-83-143-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.83.143]) by mx.google.com with ESMTPSA id yk10sm653110pac.16.2013.07.25.20.03.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 20:03:29 -0700 (PDT) Message-ID: <51F1E6FE.9050103@gmail.com> Date: Thu, 25 Jul 2013 19:03:26 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Draft agenda X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 03:03:31 -0000 I've uploaded a first draft of the agenda for Wednesday's session to: http://www.ietf.org/proceedings/87/agenda/agenda-87-opsawg. Items may be added or dropped, and times tweaked. Please let me know if there are problems, errors, etc. Neither Chris nor I will be in Berlin, but Scott will. Melinda From dromasca@avaya.com Fri Jul 26 00:22:25 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18621F88DB for ; Fri, 26 Jul 2013 00:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgIWEq0hiKlR for ; Fri, 26 Jul 2013 00:22:20 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id DD26121F88D2 for ; Fri, 26 Jul 2013 00:22:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAGgj8lHGmAcV/2dsb2JhbABagmUhNVC9Q4EVFnSCJAEBAQEDAQEBDyg0CwwGAQgNBAMBAQELFAUEKAYLFAcBAQUFBA4FCBqHXAMPAQuce5MoDYhHEwSNFYI3MQ2DDG4DlXUBiC+FYYUmgVuBOYIq X-IronPort-AV: E=Sophos;i="4.89,749,1367985600"; d="scan'208";a="21666565" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 Jul 2013 03:22:05 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jul 2013 03:19:27 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0328.009; Fri, 26 Jul 2013 03:22:03 -0400 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] Fwd: Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" Thread-Index: AQHOiOQIKX/4pDAJGUScySTPjcAkfpl1F2FAgADTsKCAAKSLoA== Date: Fri, 26 Jul 2013 07:22:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12881CFF@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Howard Frazier Subject: [OPSAWG] FW: Fwd: Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 07:22:25 -0000 Forwarding a comment from Howard Frazier.=20 Regards, Dan -----Original Message----- From: Howard Frazier [mailto:hfrazier@broadcom.com]=20 Sent: Friday, July 26, 2013 12:33 AM To: Romascanu, Dan (Dan) Subject: RE: [OPSAWG] Fwd: Working group last call on "Ethernet in the Firs= t Mile Copper (EFMCu) Interfaces MIB" Dan, the references to IEEE Std 802.3.1 in rfc5066bis should be updated to IEEE = Std 802.3.1-2013, as the revision has been approved as an IEEE Standard. Howard -----Original Message----- From: ieee-ietf-coord-bounces@ietf.org [mailto:ieee-ietf-coord-bounces@ietf= .org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, July 25, 2013 1:57 AM To: Subject: [ieee-ietf-coord] FW: [OPSAWG] Fwd: Working group last call on "Et= hernet in the First Mile Copper (EFMCu) Interfaces MIB" FYI - the WGLC for rfc5066bis. This LC is related to item #7 on the IEEE802= -IETF shared areas of interest list.=20 Thanks and Regards, Dan -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Melinda Shore Sent: Thursday, July 25, 2013 6:07 AM To: opsawg@ietf.org Subject: [OPSAWG] Fwd: Working group last call on "Ethernet in the First Mi= le Copper (EFMCu) Interfaces MIB" It's been pointed out to me that since July 7 was actually several weeks ag= o I probably meant to write that the deadline for feedback is *August* 7, 2= 013, and indeed that's the case. WG last call closes on August 7, 2013. Thanks, Melinda -------- Original Message -------- Subject: Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" Date: Wed, 24 Jul 2013 11:42:13 -0800 From: Melinda Shore To: opsawg@ietf.org This is to announce the start of working group last call on: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ It is intended for publication as a standards track RFC. Please give it a careful read and provide any feedback to this mailing list= by July 7, 2013. Thanks, opsawg chairs _______________________________________________ ieee-ietf-coord mailing list ieee-ietf-coord@ietf.org https://www.ietf.org/mailman/listinfo/ieee-ietf-coord From ietf@cdl.asgaard.org Fri Jul 26 14:40:11 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3AD11E816D for ; Fri, 26 Jul 2013 14:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj1jQl0-0+75 for ; Fri, 26 Jul 2013 14:40:06 -0700 (PDT) Received: from smtp2.emailarray.com (smtp.emailarray.com [69.28.212.198]) by ietfa.amsl.com (Postfix) with ESMTP id AE17411E8167 for ; Fri, 26 Jul 2013 14:40:06 -0700 (PDT) Received: (qmail 6558 invoked by uid 89); 26 Jul 2013 21:40:05 -0000 Received: from unknown (HELO ?172.16.84.1?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp2.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Jul 2013 21:40:05 -0000 From: "Christopher LILJENSTOLPE" To: opsawg@ietf.org Date: Fri, 26 Jul 2013 14:40:03 -0700 Message-ID: <6AC02B02-B3F9-40EC-BC8D-C24B24A00A4D@cdl.asgaard.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_E2607D79-6F24-4C6D-AE74-DCD20FB22AF3_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.6r3549) X-PolarisMail-Flags: Subject: [OPSAWG] Unable to attend in person X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 21:40:11 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_E2607D79-6F24-4C6D-AE74-DCD20FB22AF3_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings all, I won't be able to attend this time in person. I will be attending remo= tely. Thx Christopher -- =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf --=_MailMate_E2607D79-6F24-4C6D-AE74-DCD20FB22AF3_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJR8uyzAAoJEGmx2Mt/+Iw/xUwIAJHvoCqOdIENXiUi7HF6GOgL sxmXUIYlQ8R00wMyiQM68OjuDYze7Nh+MGXSzesnTUtLClbngOUxkm3EC85YqtX3 uiIN2zR1IB0TCntaTGEldJzqeNN2ecGEqYnUzVq38xC9iRCUc/kvAN97sSVpeA+k 9hEgt5SUHrMJ9uM42eqSD0b60bgl7C0yCPtcvCSnBqFFYUsBIcqmxXD84iAXwUQE ygaWhdiGDFvFGiYagk1hvVpRUHq4lIqNAppsdm1B7IfXy12epmZElDxot4zn5wbB A0iAgbAUw8PCdFJCT2kGtMWn2z759QisAsODdEWQSJjcLHSumsX4NK8tqwCxhk4= =2PbY -----END PGP SIGNATURE----- --=_MailMate_E2607D79-6F24-4C6D-AE74-DCD20FB22AF3_=-- From satoru.matsushima@gmail.com Sun Jul 28 21:41:24 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9721F9F8E for ; Sun, 28 Jul 2013 21:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jod-x7GQ+Yc for ; Sun, 28 Jul 2013 21:41:23 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3F01721F9F8A for ; Sun, 28 Jul 2013 21:41:23 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so81633eek.33 for ; Sun, 28 Jul 2013 21:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cXKQLkt/8yzKDwofxuO9NkbXXE44NlLdh+8cYY8GV1I=; b=OLz+HbabGzBlPe3Nh5tsfcc1K5b1qFbemR9xHU6aCu2olysN+NWQux1tfSLhZFqRw4 49ikRQoELaRDZCuuCzDFbTQu+mv+fWhVUTPS4VUEakm4gREeDnDfnLZKUKZ/7FAC8nvo ZDYKC29g+fo+MsxVpnEJnD3HT5ZxYjJZYkbOOQEIHR/Rt0qdSa6zuov/1tuGmQTO1wxm XTup+cgPBhamehrPJRtR9FloFu06dEp44ctLbSEmxMK7E1ent4uQmR3lH1vhGVVEVI1t P+WUenLw4m4K9q5ny61oFZBKN4WQI+dOjLArMwlZzsIdXD1+3Nr6orQNbeiqG0VOhJts IJXQ== X-Received: by 10.15.26.199 with SMTP id n47mr58122603eeu.88.1375072882363; Sun, 28 Jul 2013 21:41:22 -0700 (PDT) Received: from [192.168.9.7] (h-213.61.227.39.host.de.colt.net. [213.61.227.39]) by mx.google.com with ESMTPSA id 43sm5682996eek.5.2013.07.28.21.41.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 21:41:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Satoru Matsushima In-Reply-To: Date: Mon, 29 Jul 2013 06:41:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <249403D4-C1B2-45B4-8530-85EADDD0FAB8@gmail.com> References: To: "Cao,Zhen" X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 04:41:24 -0000 Hi Zhen, That's sound interesting draft. Just one clarification about AP = configuration. It looks that AP is required an IP address information which is = configured to identify separated CAPWAP-DATA. Otherwise AP send both of = channel packet to single IP address, make sense? cheers, --satoru On 2013/07/19, at 5:36, "Cao,Zhen" wrote: > Hello Everyone, >=20 > The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of > draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) with > a new title and a new methodology, based on review of multiple experts > recommended by OPS ADs. >=20 > Here is a highlight of the update in this version: >=20 > The current draft proposes to split data and control plane by having > two elements AC-CP and AC-DP. AC-DP handles all user payload with the > exception of layer 2 management frames between the AC and use such as > IEEE 802.11 association, authentication, probe, Action Frame. AC-CP > handles all control messages between the WTP and AC. In addition, the > AC-CP will handle user payload related to layer-2 management frames > such as those mentioned above. The WTP will have one set of Control > and Data Tunnel to AC-CP and another data-tunnel to AC-DP. >=20 > The key difference from the previous version is that the previous > draft suggested > 1) AC-CP has a control and data channel (instead of only a control > channel in current draft) > 2) EAP messages were sent on Control Channel (instead of Data channel > in current draft) >=20 > We also do an analyze of CAPWAP local bridge model to support such > scenarios, as recommended by Dorothy. >=20 > Thank ALL that reviewed the draft and looking forward to your new = comments. >=20 > Best regards, > -cz >=20 > On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen wrote: >> FYI. >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: Sun, Jul 14, 2013 at 8:50 PM >> Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt >> To: i-d-announce@ietf.org >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Separation of CAPWAP Control and Data Plane: >> Scenarios, Requirements and Solutions >> Author(s) : Rong Zhang >> Zhen Cao >> Hui Deng >> Rajesh S. Pazhyannur >> Sri Gundavelli >> Filename : draft-zhang-opsawg-capwap-cds-00.txt >> Pages : 8 >> Date : 2013-07-14 >>=20 >> Abstract: >> This document describes the scenarios and requirements of = separating >> CAPWAP Data and Control plane. This specification provides a = CAPWAP >> extension to allow two distinct AC component: AC-DP (AC-Data Plane) >> and AC-CP (AC-Control Plane). AC-DP handles all user payload with >> the exception of layer 2 management frames between the AC and user >> such as IEEE 802.11 association, authentication, probe, Action = Frame. >> AC-CP handles all control messages between the WTP and AC. In >> addition, the AC-CP wil handle user payload related to layer-2 >> management frames such as those mentioned above. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From rpazhyan@cisco.com Mon Jul 29 05:00:49 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E92E21F9C0E for ; Mon, 29 Jul 2013 05:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AaSOefmF96t for ; Mon, 29 Jul 2013 05:00:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2BA21F9C05 for ; Mon, 29 Jul 2013 05:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5013; q=dns/txt; s=iport; t=1375099244; x=1376308844; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=HlU5MzCdh48WzChqmqaPZ8evD3iRJFRJejDkr7hrVvI=; b=Ghz2gp5wsSEM+MYdSk8auvMldo+A1yDQokgEmCJrpxL06qu35t4S3FjG ygUtpcrxGX7Z20QgNYUOk6XDW9ecfaWsBxk1GbS1PKaiVdCaAdrGLtgKT +9pPfQ2HKbXR+fOtND7Od6WeMYKaxpguCWL66qmjrCfB0DKF5hPxAzk1j g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAARZ9lGtJXHA/2dsb2JhbABRCoMGNVC9WIEWFnSCJAEBAQMBAQEBNzEDCwUHBgEIEQMBAQEBChQJKAYLFAkJAQQOBQgBEodjAwkGDK8gDYhejRWBKQaBCDECC4MSbwOVdoMSin0DhSOBW4E5gXE5 X-IronPort-AV: E=Sophos;i="4.89,768,1367971200"; d="scan'208";a="240743496" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2013 12:00:43 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6TC0hqW003119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 12:00:43 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 07:00:42 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Satoru Matsushima , "Cao,Zhen" Thread-Topic: [OPSAWG] CAPWAP Control and Data Plane Separation Draft -draft-zhang-opsawg-capwap-cds Thread-Index: Ac6MUySI3nYEBHVvSOqT9DFtyB7sFg== Date: Mon, 29 Jul 2013 12:00:42 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B431DC0EC53@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft -draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:00:50 -0000 Hello Satoru Thanks for the email.=20 Yes, you are right that the AP requires the IP address of the AC-DP (for th= e separate/new CAPWAP Data-Channel).=20 We expect this IP address to be provided by the AC-CP using an existing CA= PWAP control channel. As you can imagine this would require extensions to C= APWAP (specifically, RFC 5416) Regards Rajesh=20 -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Satoru Matsushima Sent: Sunday, July 28, 2013 9:41 PM To: Cao,Zhen Cc: opsawg@ietf.org Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draf= t-zhang-opsawg-capwap-cds Hi Zhen, That's sound interesting draft. Just one clarification about AP configurati= on. It looks that AP is required an IP address information which is configured = to identify separated CAPWAP-DATA. Otherwise AP send both of channel packet= to single IP address, make sense? cheers, --satoru On 2013/07/19, at 5:36, "Cao,Zhen" wrote: > Hello Everyone, >=20 > The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of > draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) with=20 > a new title and a new methodology, based on review of multiple experts=20 > recommended by OPS ADs. >=20 > Here is a highlight of the update in this version: >=20 > The current draft proposes to split data and control plane by having=20 > two elements AC-CP and AC-DP. AC-DP handles all user payload with the=20 > exception of layer 2 management frames between the AC and use such as=20 > IEEE 802.11 association, authentication, probe, Action Frame. AC-CP=20 > handles all control messages between the WTP and AC. In addition, the=20 > AC-CP will handle user payload related to layer-2 management frames=20 > such as those mentioned above. The WTP will have one set of Control=20 > and Data Tunnel to AC-CP and another data-tunnel to AC-DP. >=20 > The key difference from the previous version is that the previous=20 > draft suggested > 1) AC-CP has a control and data channel (instead of only a control=20 > channel in current draft) > 2) EAP messages were sent on Control Channel (instead of Data channel=20 > in current draft) >=20 > We also do an analyze of CAPWAP local bridge model to support such=20 > scenarios, as recommended by Dorothy. >=20 > Thank ALL that reviewed the draft and looking forward to your new comment= s. >=20 > Best regards, > -cz >=20 > On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen wrote: >> FYI. >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: Sun, Jul 14, 2013 at 8:50 PM >> Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt >> To: i-d-announce@ietf.org >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : Separation of CAPWAP Control and Data Plane: >> Scenarios, Requirements and Solutions >> Author(s) : Rong Zhang >> Zhen Cao >> Hui Deng >> Rajesh S. Pazhyannur >> Sri Gundavelli >> Filename : draft-zhang-opsawg-capwap-cds-00.txt >> Pages : 8 >> Date : 2013-07-14 >>=20 >> Abstract: >> This document describes the scenarios and requirements of separating >> CAPWAP Data and Control plane. This specification provides a CAPWAP >> extension to allow two distinct AC component: AC-DP (AC-Data Plane) >> and AC-CP (AC-Control Plane). AC-DP handles all user payload with >> the exception of layer 2 management frames between the AC and user >> such as IEEE 802.11 association, authentication, probe, Action Frame. >> AC-CP handles all control messages between the WTP and AC. In >> addition, the AC-CP wil handle user payload related to layer-2 >> management frames such as those mentioned above. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From zehn.cao@gmail.com Mon Jul 29 06:06:32 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F1621F9E46 for ; Mon, 29 Jul 2013 06:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-CI36q-+efu for ; Mon, 29 Jul 2013 06:06:31 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1709B21F9ED2 for ; Mon, 29 Jul 2013 06:06:29 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hq12so1455767wib.14 for ; Mon, 29 Jul 2013 06:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WLvdoIx39UnTfZCXyVPdtZfwsarQzLRoS85bKHQtbwc=; b=SCWJHmuM71+ZV0Fu+WP6lkItTXrOJuAAWu6oUh/rvUE0E0a7ir4R2i2kMvUfQM3jLz WsPTkneflFjLORxAC+kkC2ktxYUWZWM+lTUAoBmQacWePirAstt0/evdKsWDB0+jv/1K f46T1WA/YCRLtnyXtlrWnSRwYpNezo+l6e/M0XSJzGB9/EtADTflDp1viaXetb6Ay0sZ vleTlkfRYqJaJIranS2/cK82f3sS/fExttWzFha6qJNdcfgahq4A52vqBuK1cZ8/k8MG HV6vB7EhbMKfLTqKZSGqjjXJ5YaLb7xAbpWT14F+cIQyxHZRUBVHloA9Mhcbm5icBnQA w0Ew== MIME-Version: 1.0 X-Received: by 10.194.234.100 with SMTP id ud4mr43138036wjc.44.1375103189170; Mon, 29 Jul 2013 06:06:29 -0700 (PDT) Received: by 10.216.90.135 with HTTP; Mon, 29 Jul 2013 06:06:29 -0700 (PDT) In-Reply-To: <4ED2E36A22261145861BAB2C24088B431DC0EC53@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B431DC0EC53@xmb-aln-x09.cisco.com> Date: Mon, 29 Jul 2013 15:06:29 +0200 Message-ID: From: "Cao,Zhen" To: "Rajesh Pazhyannur (rpazhyan)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft -draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:06:33 -0000 For the local bridge approach, there is no need of this configuration. For the two data tunnels approach, IP address would be informed to the WTP, CAPWAP extension is one approach, but it is also possible to do that via the existing discovery process in CAPWAP. On Mon, Jul 29, 2013 at 2:00 PM, Rajesh Pazhyannur (rpazhyan) wrote: > Hello Satoru > > Thanks for the email. > Yes, you are right that the AP requires the IP address of the AC-DP (for the separate/new CAPWAP Data-Channel). > We expect this IP address to be provided by the AC-CP using an existing CAPWAP control channel. As you can imagine this would require extensions to CAPWAP (specifically, RFC 5416) > > Regards > > Rajesh > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Satoru Matsushima > Sent: Sunday, July 28, 2013 9:41 PM > To: Cao,Zhen > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds > > Hi Zhen, > > That's sound interesting draft. Just one clarification about AP configuration. > It looks that AP is required an IP address information which is configured to identify separated CAPWAP-DATA. Otherwise AP send both of channel packet to single IP address, make sense? > > cheers, > --satoru > > > On 2013/07/19, at 5:36, "Cao,Zhen" wrote: > >> Hello Everyone, >> >> The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of >> draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) with >> a new title and a new methodology, based on review of multiple experts >> recommended by OPS ADs. >> >> Here is a highlight of the update in this version: >> >> The current draft proposes to split data and control plane by having >> two elements AC-CP and AC-DP. AC-DP handles all user payload with the >> exception of layer 2 management frames between the AC and use such as >> IEEE 802.11 association, authentication, probe, Action Frame. AC-CP >> handles all control messages between the WTP and AC. In addition, the >> AC-CP will handle user payload related to layer-2 management frames >> such as those mentioned above. The WTP will have one set of Control >> and Data Tunnel to AC-CP and another data-tunnel to AC-DP. >> >> The key difference from the previous version is that the previous >> draft suggested >> 1) AC-CP has a control and data channel (instead of only a control >> channel in current draft) >> 2) EAP messages were sent on Control Channel (instead of Data channel >> in current draft) >> >> We also do an analyze of CAPWAP local bridge model to support such >> scenarios, as recommended by Dorothy. >> >> Thank ALL that reviewed the draft and looking forward to your new comments. >> >> Best regards, >> -cz >> >> On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen wrote: >>> FYI. >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Sun, Jul 14, 2013 at 8:50 PM >>> Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt >>> To: i-d-announce@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Separation of CAPWAP Control and Data Plane: >>> Scenarios, Requirements and Solutions >>> Author(s) : Rong Zhang >>> Zhen Cao >>> Hui Deng >>> Rajesh S. Pazhyannur >>> Sri Gundavelli >>> Filename : draft-zhang-opsawg-capwap-cds-00.txt >>> Pages : 8 >>> Date : 2013-07-14 >>> >>> Abstract: >>> This document describes the scenarios and requirements of separating >>> CAPWAP Data and Control plane. This specification provides a CAPWAP >>> extension to allow two distinct AC component: AC-DP (AC-Data Plane) >>> and AC-CP (AC-Control Plane). AC-DP handles all user payload with >>> the exception of layer 2 management frames between the AC and user >>> such as IEEE 802.11 association, authentication, probe, Action Frame. >>> AC-CP handles all control messages between the WTP and AC. In >>> addition, the AC-CP wil handle user payload related to layer-2 >>> management frames such as those mentioned above. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From satoru.matsushima@gmail.com Mon Jul 29 06:45:10 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E736721F9D69 for ; Mon, 29 Jul 2013 06:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz2ynAFujwMl for ; Mon, 29 Jul 2013 06:45:09 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1000821F9D55 for ; Mon, 29 Jul 2013 06:45:08 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so5450235pdi.16 for ; Mon, 29 Jul 2013 06:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3Qmkd7D0UC9xV4lgkWpu+KiF9p0guU0svOtGJFW3w14=; b=UV5lPEJjr5gmqZT/GJ5UNOBUAB2ZrVwosNXXegh57LLopFX29YV2XHXtXcAOijeEjf p79WjupHLdnI8541qCRj5W5mAJVZU2QGceYGIVsXPX/ojt4va59X0f3jiow/Fb6ldaza vQoiQcHYXVCYUDwhRS8hjW2qaEx7jItDmS5dej6wdBkWq+iH6LTrNIyaRzDuzbzsRckl Imod8YvnEld2xkHk33dGcQhj38jyxC1+0B2IVk2ku79uz/WkJ4YTgFZHWpL3m5BDXhVC TkQ2x9cdp0gRaIjRL1+dXfXtqh3Riedg9M+YnNLimoeShRA44BxfEkJyc3c8wbJ1yqJE /oQw== X-Received: by 10.66.136.49 with SMTP id px17mr53166589pab.133.1375105508322; Mon, 29 Jul 2013 06:45:08 -0700 (PDT) Received: from ?IPv6:2001:df8::80:f5f2:57e8:82aa:e06d? ([2001:df8:0:80:f5f2:57e8:82aa:e06d]) by mx.google.com with ESMTPSA id wf7sm20919908pac.20.2013.07.29.06.45.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 06:45:07 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Satoru Matsushima In-Reply-To: Date: Mon, 29 Jul 2013 15:45:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DA1FEDC-0990-4FE3-9E69-3135AF69376F@gmail.com> References: <4ED2E36A22261145861BAB2C24088B431DC0EC53@xmb-aln-x09.cisco.com> To: "Cao,Zhen" X-Mailer: Apple Mail (2.1508) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft -draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:45:10 -0000 On 2013/07/29, at 15:06, "Cao,Zhen" wrote: > For the local bridge approach, there is no need of this configuration. >=20 > For the two data tunnels approach, IP address would be informed to the > WTP, CAPWAP extension is one approach, but it is also possible to do > that via the existing discovery process in CAPWAP. >=20 But existing WTP assumes that the indicated IP address is AC which is = not c-d separated, right? It would be nice to see some text in the draft for those should be = clarified. cheers, --satoru > On Mon, Jul 29, 2013 at 2:00 PM, Rajesh Pazhyannur (rpazhyan) > wrote: >> Hello Satoru >>=20 >> Thanks for the email. >> Yes, you are right that the AP requires the IP address of the AC-DP = (for the separate/new CAPWAP Data-Channel). >> We expect this IP address to be provided by the AC-CP using an = existing CAPWAP control channel. As you can imagine this would require = extensions to CAPWAP (specifically, RFC 5416) >>=20 >> Regards >>=20 >> Rajesh >> -----Original Message----- >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf Of Satoru Matsushima >> Sent: Sunday, July 28, 2013 9:41 PM >> To: Cao,Zhen >> Cc: opsawg@ietf.org >> Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft = - draft-zhang-opsawg-capwap-cds >>=20 >> Hi Zhen, >>=20 >> That's sound interesting draft. Just one clarification about AP = configuration. >> It looks that AP is required an IP address information which is = configured to identify separated CAPWAP-DATA. Otherwise AP send both of = channel packet to single IP address, make sense? >>=20 >> cheers, >> --satoru >>=20 >>=20 >> On 2013/07/19, at 5:36, "Cao,Zhen" wrote: >>=20 >>> Hello Everyone, >>>=20 >>> The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of >>> draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) = with >>> a new title and a new methodology, based on review of multiple = experts >>> recommended by OPS ADs. >>>=20 >>> Here is a highlight of the update in this version: >>>=20 >>> The current draft proposes to split data and control plane by having >>> two elements AC-CP and AC-DP. AC-DP handles all user payload with = the >>> exception of layer 2 management frames between the AC and use such = as >>> IEEE 802.11 association, authentication, probe, Action Frame. AC-CP >>> handles all control messages between the WTP and AC. In addition, = the >>> AC-CP will handle user payload related to layer-2 management frames >>> such as those mentioned above. The WTP will have one set of Control >>> and Data Tunnel to AC-CP and another data-tunnel to AC-DP. >>>=20 >>> The key difference from the previous version is that the previous >>> draft suggested >>> 1) AC-CP has a control and data channel (instead of only a control >>> channel in current draft) >>> 2) EAP messages were sent on Control Channel (instead of Data = channel >>> in current draft) >>>=20 >>> We also do an analyze of CAPWAP local bridge model to support such >>> scenarios, as recommended by Dorothy. >>>=20 >>> Thank ALL that reviewed the draft and looking forward to your new = comments. >>>=20 >>> Best regards, >>> -cz >>>=20 >>> On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen = wrote: >>>> FYI. >>>>=20 >>>>=20 >>>> ---------- Forwarded message ---------- >>>> From: >>>> Date: Sun, Jul 14, 2013 at 8:50 PM >>>> Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt >>>> To: i-d-announce@ietf.org >>>>=20 >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>=20 >>>>=20 >>>> Title : Separation of CAPWAP Control and Data = Plane: >>>> Scenarios, Requirements and Solutions >>>> Author(s) : Rong Zhang >>>> Zhen Cao >>>> Hui Deng >>>> Rajesh S. Pazhyannur >>>> Sri Gundavelli >>>> Filename : draft-zhang-opsawg-capwap-cds-00.txt >>>> Pages : 8 >>>> Date : 2013-07-14 >>>>=20 >>>> Abstract: >>>> This document describes the scenarios and requirements of = separating >>>> CAPWAP Data and Control plane. This specification provides a = CAPWAP >>>> extension to allow two distinct AC component: AC-DP (AC-Data = Plane) >>>> and AC-CP (AC-Control Plane). AC-DP handles all user payload with >>>> the exception of layer 2 management frames between the AC and user >>>> such as IEEE 802.11 association, authentication, probe, Action = Frame. >>>> AC-CP handles all control messages between the WTP and AC. In >>>> addition, the AC-CP wil handle user payload related to layer-2 >>>> management frames such as those mentioned above. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg From zehn.cao@gmail.com Mon Jul 29 08:22:30 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCDC21F9ECA for ; Mon, 29 Jul 2013 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj6Lda7gRQyg for ; Mon, 29 Jul 2013 08:22:29 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5B01111E80F7 for ; Mon, 29 Jul 2013 08:22:28 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so5132926wgh.32 for ; Mon, 29 Jul 2013 08:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=up9bvpdN3IkaE/bCoFmc5TTXgpSQ/wrwVWeujd5sOIs=; b=T25owoPEjAr2KMcw952KUY/qSDkaM1KlfFgT3jCWeuX8Vq4b0K1XX4YPbCJAxraWlU 58/C5rSyrJYrXGl51oJhvA5ZCz9Vbk1y2mt14+m5KDIsmZ9sez/i3e9I8Z3Cg34KblN6 seiofFDJGoHHmG6msc3kgnzlleJfZoAU/vsRgVpg09G0mEBIjfLGiZH6FKq+gPUOmPIl hH5zFNEZUSiQeYvP1Sz/o8C3TuhqnYldS6xxFvnnsH6BFgJjBlQdLPFcrK9UzwKC5B5a zk9wfXZbjuNBEYG2HC74GkYIZukkkUe5kfiQpyjnXQDusthYtAYkO+/7rpXC4h7MBfdZ hdDQ== MIME-Version: 1.0 X-Received: by 10.194.172.228 with SMTP id bf4mr3191384wjc.36.1375111347075; Mon, 29 Jul 2013 08:22:27 -0700 (PDT) Received: by 10.216.90.135 with HTTP; Mon, 29 Jul 2013 08:22:26 -0700 (PDT) In-Reply-To: <4DA1FEDC-0990-4FE3-9E69-3135AF69376F@gmail.com> References: <4ED2E36A22261145861BAB2C24088B431DC0EC53@xmb-aln-x09.cisco.com> <4DA1FEDC-0990-4FE3-9E69-3135AF69376F@gmail.com> Date: Mon, 29 Jul 2013 17:22:26 +0200 Message-ID: From: "Cao,Zhen" To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft -draft-zhang-opsawg-capwap-cds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:22:30 -0000 > But existing WTP assumes that the indicated IP address is AC which is not c-d > separated, right? At least not specified in the RFC 5416. > It would be nice to see some text in the draft for those should be clarified. We will add that. Thanks, -z > cheers, > --satoru > > > > >> On Mon, Jul 29, 2013 at 2:00 PM, Rajesh Pazhyannur (rpazhyan) >> wrote: >>> Hello Satoru >>> >>> Thanks for the email. >>> Yes, you are right that the AP requires the IP address of the AC-DP (for the separate/new CAPWAP Data-Channel). >>> We expect this IP address to be provided by the AC-CP using an existing CAPWAP control channel. As you can imagine this would require extensions to CAPWAP (specifically, RFC 5416) >>> >>> Regards >>> >>> Rajesh >>> -----Original Message----- >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Satoru Matsushima >>> Sent: Sunday, July 28, 2013 9:41 PM >>> To: Cao,Zhen >>> Cc: opsawg@ietf.org >>> Subject: Re: [OPSAWG] CAPWAP Control and Data Plane Separation Draft - draft-zhang-opsawg-capwap-cds >>> >>> Hi Zhen, >>> >>> That's sound interesting draft. Just one clarification about AP configuration. >>> It looks that AP is required an IP address information which is configured to identify separated CAPWAP-DATA. Otherwise AP send both of channel packet to single IP address, make sense? >>> >>> cheers, >>> --satoru >>> >>> >>> On 2013/07/19, at 5:36, "Cao,Zhen" wrote: >>> >>>> Hello Everyone, >>>> >>>> The draft-zhang-opsawg-capwap-cds-00.txt is an update/subvert of >>>> draft-zhang-opsawg-capwap-eap-00 (which we presented on Orlando) with >>>> a new title and a new methodology, based on review of multiple experts >>>> recommended by OPS ADs. >>>> >>>> Here is a highlight of the update in this version: >>>> >>>> The current draft proposes to split data and control plane by having >>>> two elements AC-CP and AC-DP. AC-DP handles all user payload with the >>>> exception of layer 2 management frames between the AC and use such as >>>> IEEE 802.11 association, authentication, probe, Action Frame. AC-CP >>>> handles all control messages between the WTP and AC. In addition, the >>>> AC-CP will handle user payload related to layer-2 management frames >>>> such as those mentioned above. The WTP will have one set of Control >>>> and Data Tunnel to AC-CP and another data-tunnel to AC-DP. >>>> >>>> The key difference from the previous version is that the previous >>>> draft suggested >>>> 1) AC-CP has a control and data channel (instead of only a control >>>> channel in current draft) >>>> 2) EAP messages were sent on Control Channel (instead of Data channel >>>> in current draft) >>>> >>>> We also do an analyze of CAPWAP local bridge model to support such >>>> scenarios, as recommended by Dorothy. >>>> >>>> Thank ALL that reviewed the draft and looking forward to your new comments. >>>> >>>> Best regards, >>>> -cz >>>> >>>> On Mon, Jul 15, 2013 at 11:02 PM, Cao,Zhen wrote: >>>>> FYI. >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: >>>>> Date: Sun, Jul 14, 2013 at 8:50 PM >>>>> Subject: I-D Action: draft-zhang-opsawg-capwap-cds-00.txt >>>>> To: i-d-announce@ietf.org >>>>> >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> >>>>> >>>>> Title : Separation of CAPWAP Control and Data Plane: >>>>> Scenarios, Requirements and Solutions >>>>> Author(s) : Rong Zhang >>>>> Zhen Cao >>>>> Hui Deng >>>>> Rajesh S. Pazhyannur >>>>> Sri Gundavelli >>>>> Filename : draft-zhang-opsawg-capwap-cds-00.txt >>>>> Pages : 8 >>>>> Date : 2013-07-14 >>>>> >>>>> Abstract: >>>>> This document describes the scenarios and requirements of separating >>>>> CAPWAP Data and Control plane. This specification provides a CAPWAP >>>>> extension to allow two distinct AC component: AC-DP (AC-Data Plane) >>>>> and AC-CP (AC-Control Plane). AC-DP handles all user payload with >>>>> the exception of layer 2 management frames between the AC and user >>>>> such as IEEE 802.11 association, authentication, probe, Action Frame. >>>>> AC-CP handles all control messages between the WTP and AC. In >>>>> addition, the AC-CP wil handle user payload related to layer-2 >>>>> management frames such as those mentioned above. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-zhang-opsawg-capwap-cds-00 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> OPSAWG@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsawg >>> >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg > From rpazhyan@cisco.com Tue Jul 30 04:09:22 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585C811E810F for ; Tue, 30 Jul 2013 04:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4CvcVRTPo+R for ; Tue, 30 Jul 2013 04:09:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B748411E81D5 for ; Tue, 30 Jul 2013 04:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3828; q=dns/txt; s=iport; t=1375182545; x=1376392145; h=from:to:subject:date:message-id:mime-version; bh=X0cF/XZ1Sdp6QXnawoMDBdVJJnhbzzbVxUB67x3Wq6M=; b=lyHdxJq6FhZEQLgPjwhbZ8kCx9RgUftIKvZvo/ZWlzjNzbF4oNI1pHqr /i4E+KHwIamzDO2qIP59CRyGmlga3jcZ3SwmGk+Uh3L78KaTBNTuGeAe6 B2/VjvIpMXZotAv1pO7k2RZAurLqLUfugPxf2B0+1FxtdsFmCmwNi9xSK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOad91GtJXHB/2dsb2JhbABbgkJEgQW+D4EdFnSCJgEELV4BDA4QVhcPAQQbiAiYIqBuj02DUG8DqSuDFIIq X-IronPort-AV: E=Sophos;i="4.89,777,1367971200"; d="scan'208,217";a="241224041" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2013 11:09:05 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6UB95Rs020281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jul 2013 11:09:05 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 06:09:04 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: "opsawg@ietf.org" Thread-Topic: Comments on draft-shao-opsawg-capwap-hybridmac-00 Thread-Index: Ac6NFRtlA8dxsJmGROmI2oOeOEJ8/g== Date: Tue, 30 Jul 2013 11:09:04 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B431DC100FC@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.91] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B431DC100FCxmbalnx09ciscoc_" MIME-Version: 1.0 Subject: [OPSAWG] Comments on draft-shao-opsawg-capwap-hybridmac-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:09:22 -0000 --_000_4ED2E36A22261145861BAB2C24088B431DC100FCxmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello First comment/question: It appears that you are proposing a new MAC mode which is very similar to S= plit MAC mode except that it requires 1) Scheduling to *only* at the WTP (instead of allowing it additionall= y at AC) 2) Encryption to *only* at the WTP (instead of allowing it additionall= y at AC) If so, does this require defining a new MAC mode in addition to existing Sp= lit MAC and Local MAC Second comment/question: The Hybrid MAC mode seems to require fragmentation to be done only at the A= C. This choice is a little unclear. Wouldn't the upstream traffic continue to be fragmented by the WTP while do= wnstream traffic be fragmented at the AC. Third comment/question Are you considering variants of the Split MAC mode where the MAC is split (= for example association responses come from the AC) while the traffic is l= ocally bridged. For example this appears to be precluded by text in 5416: In a Split MAC Architecture, the Distribution and Integration services resi= de on the AC, and therefore all user data is tunneled between the WTP and t= he AC. As noted above, all real-time IEEE 802.11 services, including the B= eacon and Probe Response frames, are handled on the WTP. Regards Rajesh --_000_4ED2E36A22261145861BAB2C24088B431DC100FCxmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
First comment/question:
It appears that you are proposing a new MAC mode which is very similar= to Split MAC mode  except that it requires
  1. Scheduling to *only* at the WTP (instead of allowing it addition= ally at AC)
  2. Encryption to *only* at the WTP (instead of all= owing it additionally at AC)
 
If so, does this require defining a new MAC mode in addition to existi= ng Split MAC and Local MAC
 
Second comment/question:
 
The Hybrid MAC mode seems to require fragmentation to be done only at = the AC. This choice is a little unclear.
Wouldn’t the upstream traffic continue to be fragmented by the W= TP while downstream traffic be fragmented at the AC.
 
 
Third comment/question
Are you considering variants of the Split MAC mode where the MAC is sp= lit (for example association responses come from the AC)  while the tr= affic is locally bridged.
For example this appears to be precluded by text in 5416:
In a Split MAC Architecture, the Distribution and Integration <= i>services reside on the AC, and therefore all user data is tunneled betwee= n the WTP and the AC.  As noted above, all real-time IEEE 802.1= 1 services, including the Beacon and Probe Response frames, are handled on the WTP.
 
 
Regards
 
Rajesh
 
 
 
 --_000_4ED2E36A22261145861BAB2C24088B431DC100FCxmbalnx09ciscoc_-- From denghui02@gmail.com Tue Jul 30 08:56:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A252411E8228 for ; Tue, 30 Jul 2013 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLFtxsTT8ZVe for ; Tue, 30 Jul 2013 08:56:26 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 571CF11E8108 for ; Tue, 30 Jul 2013 08:56:05 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id o19so2437871qap.7 for ; Tue, 30 Jul 2013 08:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EepNN0bp77CDU2QU3+X4/f4x8QL0k96/jr4zsEI0ICs=; b=O83sfOOU9QldhdMDRmR5Y9Zw4wLBpCoQfnieo21F9zXtKAv/U5eReyGmN9T+5cMy52 MEQQVs4DXZJbAq0+qY3dxOQ9nu899LKSCayZbiR8UCHmXJgipFGP8kpkL+3DHD95RZlU 8juMeqUgLaqdHIR8rwa9YDK9beICtKVO4+wNipNPcsyAIlKbdWt8Q6l8GyVnFf7oY1HT LrJ+gjq1uIYSm9ZSfahswSb9kXEi5z5R8SgaWbqGTcFHxa4gLsIxHctAlhB8VgJlEUvo XYXRH+93c8I7gdNwj59HxE0TSyFqDpb43NJpLAxE/MsS2y4X/iX0M4q1YfSJwiZUAtNx tNig== MIME-Version: 1.0 X-Received: by 10.224.131.4 with SMTP id v4mr33156389qas.44.1375199764743; Tue, 30 Jul 2013 08:56:04 -0700 (PDT) Received: by 10.49.16.42 with HTTP; Tue, 30 Jul 2013 08:56:04 -0700 (PDT) In-Reply-To: <4ED2E36A22261145861BAB2C24088B431DC100FC@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B431DC100FC@xmb-aln-x09.cisco.com> Date: Tue, 30 Jul 2013 17:56:04 +0200 Message-ID: From: Hui Deng To: "Rajesh Pazhyannur (rpazhyan)" Content-Type: multipart/alternative; boundary=047d7b673a80792cee04e2bca53b Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Comments on draft-shao-opsawg-capwap-hybridmac-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:56:28 -0000 --047d7b673a80792cee04e2bca53b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rajesh, Thanks for your comments, I will bring your comments for tomorrow discussion. thanks a lot -Hui 2013/7/30 Rajesh Pazhyannur (rpazhyan) > Hello > > First comment/question: > It appears that you are proposing a new MAC mode which is very similar to > Split MAC mode except that it requires > > 1. Scheduling to **only** at the WTP (instead of allowing it > additionally at AC) > 2. Encryption to **only** at the WTP (instead of allowing it > additionally at AC) > > > If so, does this require defining a new MAC mode in addition to existing > Split MAC and Local MAC > > Second comment/question: > > The Hybrid MAC mode seems to require fragmentation to be done only at the > AC. This choice is a little unclear. > Wouldn=92t the upstream traffic continue to be fragmented by the WTP whil= e > downstream traffic be fragmented at the AC. > > > Third comment/question > Are you considering variants of the Split MAC mode where the MAC is split > (for example association responses come from the AC) while the traffic i= s > locally bridged. > For example this appears to be precluded by text in 5416: > *In a Split MAC Architecture, the Distribution and Integration* *services > reside on the AC, and therefore all user data is tunneled between the WTP > and the AC. As noted above, all real-time IEEE* *802.11 services, > including the Beacon and Probe Response frames, are handled on the WTP.* > > > Regards > > Rajesh > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > --047d7b673a80792cee04e2bca53b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Rajesh,
=A0
Thanks for your co= mments, I will bring your comments for tomorrow discussion.
thank= s a lot
=A0
-Hui
=A0


2013/7/30 Rajesh Pazhyannur (rpazhyan) <= span dir=3D"ltr"><rpazhyan@cisco.com>
Hello
=A0
First comment/question:
It appears that you are proposing a new MAC mode which is very similar= to Split MAC mode=A0 except that it requires
  1. Scheduling to *only* at the WTP (instead of allowing it addition= ally at AC)
  2. Encryption to *only* at the WTP (instead of all= owing it additionally at AC)
=A0
If so, does this require defining a new MAC mode in addition to existi= ng Split MAC and Local MAC
=A0
Second comment/question:
=A0
The Hybrid MAC mode seems to require fragmentation to be done only at = the AC. This choice is a little unclear.
Wouldn=92t the upstream traffic continue to be fragmented by the WTP w= hile downstream traffic be fragmented at the AC.
=A0
=A0
Third comment/question
Are you considering variants of the Split MAC mode where the MAC is sp= lit (for example association responses come from the AC)=A0 while the traff= ic is locally bridged.
For example this appears to be precluded by text in 5416:
In a Split MAC Architecture, the Distribution and Integration <= i>services reside on the AC, and therefore all user data is tunneled betwee= n the WTP and the AC.=A0 As noted above, all real-time IEEE 802.11 s= ervices, including the Beacon and Probe Response frames, are handled on the WTP.
=A0
=A0
Regards
=A0
Rajesh
=A0
=A0
=A0

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg


--047d7b673a80792cee04e2bca53b-- From j.schoenwaelder@jacobs-university.de Wed Jul 31 06:03:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2CD21F9EDF for ; Wed, 31 Jul 2013 06:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHPL7iMe4e-4 for ; Wed, 31 Jul 2013 06:02:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E59C121F9F6F for ; Wed, 31 Jul 2013 06:02:55 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49EC620BEF; Wed, 31 Jul 2013 15:02:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id thlNirGz599Y; Wed, 31 Jul 2013 15:02:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9943C2096B; Wed, 31 Jul 2013 15:02:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7971E27A0686; Wed, 31 Jul 2013 15:02:51 +0200 (CEST) Date: Wed, 31 Jul 2013 15:02:51 +0200 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20130731130251.GA22726@elstar.local> Mail-Followup-To: opsawg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [OPSAWG] vm-mib - missing pieces - please provide details X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:03:03 -0000 Hi, there were a few statements during today's WG meeting that the MIB in draft-asai-vmm-mib-04 lacks a few critical counters and some details concerning the networking aspects. In order to sort this out, it would be extremely helpful if more detailed information can be provided what is missing. We generally tried to avoid any duplication of information that can be obtained form other existing MIBs and it might be that we simply need more description and examples. But to sort this out, we really need more input. Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103