From ramk@Brocade.com Wed Oct 3 16:42:28 2012 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 3246C1F0C82 for ; Wed, 3 Oct 2012 16:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYkAUsZB6SOm for ; Wed, 3 Oct 2012 16:42:27 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9E51F0C80 for ; Wed, 3 Oct 2012 16:42:27 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id q93NfSMF004376; Wed, 3 Oct 2012 16:42:26 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 17rb5b0kq9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 03 Oct 2012 16:42:26 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 3 Oct 2012 16:42:38 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 3 Oct 2012 16:42:20 -0700 From: ramki Krishnan To: "fred@cisco.com" Date: Wed, 3 Oct 2012 16:42:14 -0700 Thread-Topic: some thoughts on the draft Thread-Index: Ac2c7c2rGXGmnf7xQm+vYrxPAXc0yAABhURwAQqjGgA= Message-ID: References: In-Reply-To: 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_C7634EB63EFD984A978DFB46EA5174F2BF4F5F83F9HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-03_06:2012-10-03, 2012-10-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1210030295 Cc: Sanjay Khanna , "opsawg@ietf.org" Subject: [OPSAWG] some thoughts on the draft 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 Oct 2012 23:42:28 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F5F83F9HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fred, http://www.ietf.org/proceedings/84/id/draft-ietf-opsawg-firewalls-00.txt - It is definitely worth mentioning behavioral analysis techniques li= ke sFlow/Netflow; a suggested place for this would be section 2.3. - Deep packet inspection (DPI) in firewalls (e.g. signature analysis)= comes at a performance cost. It would be worthwhile to mention that some c= ategory of flows from a source to a destination, say long-lived large flows= like long-form video content can bypass DPI in firewalls. A suggested plac= e for this would be the recommendations section. If you desire, I can write up detailed text which can be added to the draft= . thanks, ramki --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F5F83F9HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fred,=

 

http://www.ietf.org/proceedings/84/id/draft-ietf-opsawg-firew= alls-00.txt

 

=

-     &n= bsp; It is definitely worth mentioning behavioral a= nalysis techniques like sFlow/Netflow; a suggested place for this would be = section 2.3.

- = ;      Deep packet inspect= ion (DPI) in firewalls (e.g. signature analysis) comes at a performance cos= t. It would be worthwhile to mention that some category of flows from a sou= rce to a destination, say long-lived large flows like long-form video conte= nt can bypass DPI in firewalls. A suggested place for this would be the rec= ommendations section.

 

If you desire, I can write up detailed text w= hich can be added to the draft.

=  

thanks, ramki

<= /body>= --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F5F83F9HQ1EXCH01corp_-- From fred@cisco.com Wed Oct 3 17:56:27 2012 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 5B08611E8097 for ; Wed, 3 Oct 2012 17:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOSnf+CU5Smb for ; Wed, 3 Oct 2012 17:56:26 -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 7A40111E8091 for ; Wed, 3 Oct 2012 17:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7538; q=dns/txt; s=iport; t=1349312186; x=1350521786; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zHH81sDyGcsQkgjKeuiiwgYV+h446Dr3X/ZWT0MlAmk=; b=V5QEBPgm30dpnTcvHOS6F9Zmnz4LL+B4CCclXTx96uSJAchf2CrgYfgp JkggJ1pQxxH/dQZ935RwiSlDNdk2qt+cI2F5pjtzuKPWjJYzLN4Ibodtm KCZhvEI0cOo1Ud/bmIjqscPnKosfDLKX1Xkrp2HtRWyX7bxugPdLMlMe0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHTdbFCtJV2Y/2dsb2JhbABFgku8RIEIgiEBAQQSAWYQAgEIIiQyJQIEDg0BGYdjC5g8n2+LI4VaYAOkK4Fpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,530,1344211200"; d="scan'208,217";a="128119823" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 04 Oct 2012 00:56:26 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q940uPBc006987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Oct 2012 00:56:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.182]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 19:56:25 -0500 From: "Fred Baker (fred)" To: ramki Krishnan Thread-Topic: some thoughts on the draft Thread-Index: AQHNocC/cfGn2AgjhU+MlUhkgJ6jQ5eopncA Date: Thu, 4 Oct 2012 00:56:25 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B15FD2F@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.3] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--29.857300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_8C48B86A895913448548E6D15DA7553B15FD2Fxmbrcdx09ciscocom_" MIME-Version: 1.0 Cc: Sanjay Khanna , "opsawg@ietf.org" Subject: Re: [OPSAWG] some thoughts on the draft 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 Oct 2012 00:56:27 -0000 --_000_8C48B86A895913448548E6D15DA7553B15FD2Fxmbrcdx09ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable wait until you see -01 On Oct 3, 2012, at 4:42 PM, ramki Krishnan wrote: Hi Fred, http://www.ietf.org/proceedings/84/id/draft-ietf-opsawg-firewalls-00.txt - It is definitely worth mentioning behavioral analysis techniques li= ke sFlow/Netflow; a suggested place for this would be section 2.3. - Deep packet inspection (DPI) in firewalls (e.g. signature analysis)= comes at a performance cost. It would be worthwhile to mention that some c= ategory of flows from a source to a destination, say long-lived large flows= like long-form video content can bypass DPI in firewalls. A suggested plac= e for this would be the recommendations section. If you desire, I can write up detailed text which can be added to the draft= . thanks, ramki ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan --_000_8C48B86A895913448548E6D15DA7553B15FD2Fxmbrcdx09ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable wait until you see -01

On Oct 3, 2012, at 4:42 PM, ramki Krishnan wrote:

Hi Fred,
 
http://www.ie= tf.org/proceedings/84/id/draft-ietf-opsawg-firewalls-00.txt<= /div>
 
-       It is definitely worth mentioning behaviora= l analysis techniques like sFlow/Netflow; a suggested place for this would be section 2.3.
-       Deep packet inspection (DPI) in firewalls (= e.g. signature analysis) comes at a performance cost. It would be worthwhil= e to mention that some category of flows from a source to a destination, say= long-lived large flows like long-form video content can bypass DPI in fire= walls. A suggested place for this would be the recommendations section.
 
If you desire, I can write up detailed text which can be added to the draft= .
 
thanks, ramki

----------------------------------------------------
The = ;ignorance of how to use new=  = knowledge stockpiles exponentially. 
   - Marshall McLuhan

--_000_8C48B86A895913448548E6D15DA7553B15FD2Fxmbrcdx09ciscocom_-- From melinda.shore@gmail.com Thu Oct 4 12:21:31 2012 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 4BB3221F86A4 for ; Thu, 4 Oct 2012 12:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQRcDzICgO1S for ; Thu, 4 Oct 2012 12:21:30 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70A7821F8672 for ; Thu, 4 Oct 2012 12:21:26 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so855788pad.31 for ; Thu, 04 Oct 2012 12:21:26 -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=TNVV+LfNikpxkkqzvKk57DgMkyq5i426iVzH/PtbWGo=; b=WDQ//sO0nmTxKWcGm2cqXpK0LXs51Rch/wlrrppb4LgXN6uscfZq8nXaZvxkZfQlP8 fz9/MhqB+abGJBjPJnhnygbMMViYVrDEFiM9Q0Tw8NivKmTZATZjTIiatV04zyinJKyo bN8pRE9Dam/lulVNgBbdn/uEoxUTFH0Xqv8hee9OnfRNFGCNpVvw8pLgeSaQ+jfOFOwZ MSVrUAhkPlWzm6EP4gcm6rtFKRopV5s1goWOB9/Nc5oEAk1L0/K5SBumGa6zjtRLKju3 4sJ5gORb2QNVgdK5JgAWRphY+mCycZBOnF0pjR8lPMJVNeiWHVhuSZIp5SqXAIPSva3L mcwA== Received: by 10.68.234.36 with SMTP id ub4mr24663140pbc.68.1349378486147; Thu, 04 Oct 2012 12:21:26 -0700 (PDT) Received: from spandex.local (66-230-86-185-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.185]) by mx.google.com with ESMTPS id jw14sm4760740pbb.36.2012.10.04.12.21.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 12:21:25 -0700 (PDT) Message-ID: <506DE1B2.6010600@gmail.com> Date: Thu, 04 Oct 2012 11:21:22 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] IETF 85 schedule 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 Oct 2012 19:21:31 -0000 We're tentatively scheduled for Tuesday, 7 November from 1300-1500. As with recent meetings, we're meeting jointly with opsarea. Melinda From ramk@Brocade.com Thu Oct 4 18:43:26 2012 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 7BAE421F843E for ; Thu, 4 Oct 2012 18:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jOKRMIfR6rN for ; Thu, 4 Oct 2012 18:43:26 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id AD3EA1F041F for ; Thu, 4 Oct 2012 18:43:18 -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 q951dsQJ019325; Thu, 4 Oct 2012 18:43:17 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 17sj7p03v2-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 04 Oct 2012 18:43:17 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 4 Oct 2012 18:39:57 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 4 Oct 2012 18:39:28 -0700 From: ramki Krishnan To: Melinda Shore , "opsawg@ietf.org" Date: Thu, 4 Oct 2012 18:39:20 -0700 Thread-Topic: [OPSAWG] IETF 85 schedule Thread-Index: Ac2iZYCHX3yL1umLSAmOTXUQeeeKsgANGXwQ Message-ID: References: <506DE1B2.6010600@gmail.com> In-Reply-To: <506DE1B2.6010600@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-05_01:2012-10-04, 2012-10-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1210040328 Subject: Re: [OPSAWG] IETF 85 schedule 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 Oct 2012 01:43:26 -0000 HiMelinda, Nov. 7th is a Wednesday, please confirm. Thanks,ramki -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Melinda Shore Sent: Thursday, October 04, 2012 12:21 PM To: opsawg@ietf.org Subject: [OPSAWG] IETF 85 schedule We're tentatively scheduled for Tuesday, 7 November from 1300-1500. As with recent meetings, we're meeting jointly with opsarea. Melinda _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Thu Oct 4 19:00:30 2012 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 3F64411E8099 for ; Thu, 4 Oct 2012 19:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0jdR3Ze0yTl for ; Thu, 4 Oct 2012 19:00:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4869A11E8091 for ; Thu, 4 Oct 2012 19:00:27 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1212106pbb.31 for ; Thu, 04 Oct 2012 19:00:27 -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=9wxUXqetXdGUrAfP0LFMaO2puze0FOj1lWaLNf8zp7A=; b=Y63k4aQOnYD+SuncULDx4Z9Z1SduM5gBPktk/LPTTBFNYt1IKgrCc7VwIoD+y6Uu/p 903jJnX2+OouPf+CkaXttubk/3tnhF7b7MW9dry7hYKMnnKDpI76BcJdrWOfHV3x1io9 w4FpZcJNOLAFRu3oJArGasSL6xhzFB34xw2OS4OKlR8w8kgcLIS6IaRrGmIEmIg24MUP 3mLYpjUohhri8bQL9SyHnGP7H/k6C1tltkKVwL9A9CId61BW2LNLQayAYX46wdYqZurV Dpb3b3JGknteodw7QUznOVPhHUOlHFCLUAyLk/TwqyhSSQgGEYGqXG02t1MLtK+2dSep +MvQ== Received: by 10.68.138.170 with SMTP id qr10mr26545500pbb.53.1349402427577; Thu, 04 Oct 2012 19:00:27 -0700 (PDT) Received: from spandex.local (66-230-86-185-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.185]) by mx.google.com with ESMTPS id c5sm5162023pay.5.2012.10.04.19.00.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 19:00:27 -0700 (PDT) Message-ID: <506E3F38.3050902@gmail.com> Date: Thu, 04 Oct 2012 18:00:24 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ramki Krishnan References: <506DE1B2.6010600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] IETF 85 schedule 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 Oct 2012 02:00:30 -0000 On 10/4/12 5:39 PM, ramki Krishnan wrote: > Nov. 7th is a Wednesday, please confirm. Right you are: I should have written Tuesday, 6 Nov. We are scheduled opposite: certrans BOF l2vpn core softwire clue lisp precis Melinda From reid@snmp.com Fri Oct 5 09:34:22 2012 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 6945321F87A4 for ; Fri, 5 Oct 2012 09:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxOPl5p2PbDk for ; Fri, 5 Oct 2012 09:34:21 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61F21F879B for ; Fri, 5 Oct 2012 09:34:21 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA24513 for ; Fri, 5 Oct 2012 12:34:16 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA26300 for ; Fri, 5 Oct 2012 12:34:15 -0400 (EDT) Message-Id: <201210051634.MAA26300@adminfs.snmp.com> To: opsawg@ietf.org Date: Fri, 05 Oct 2012 12:34:15 -0400 From: David Reid Subject: [OPSAWG] Addition of Available Space to Host-Resources-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, 05 Oct 2012 16:34:22 -0000 >> This discussion has thus far not touched on (1) at all, and I note that >> the folks who I know were most visible in Host-Resources-MIB >> implementations have been conspicuously absent from this discussion. >> Without some interest in (1), or at least some assurance that the >> major code bases might get updated, the main value of a document >> would be to describe the shortcoming and other possible operational >> workarounds, if they exist. > >Speaking with my vendor hat on: Net-SNMP would almost certainly add >support for them. >-- >Wes Hardaker >SPARTA, Inc. SNMP Research would most likely add support for these enhancements as well. We have had similar requests from our customers. -David Reid From melinda.shore@gmail.com Fri Oct 5 11:49:55 2012 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 DEDCC21F864A for ; Fri, 5 Oct 2012 11:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1Z1SK0aWwDZ for ; Fri, 5 Oct 2012 11:49:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4718B21F8671 for ; Fri, 5 Oct 2012 11:49:55 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2223973pbb.31 for ; Fri, 05 Oct 2012 11:49: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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lBDhxx+cfow41Dey1YSlWVB2iWgdCyrZ5gbW+v5ZwSc=; b=aouRRO3CorKH1P0132hR5b6rIR3rQ4t9UaBf5/RUEve+HDTEDIUB1oW645Q5DpqLiX t4tclJ8mAZwodMgFIZ/6baRFMHVVdPPy85lG450eWBqP5S8nzv4eHY9xeEPNW4HWPTfo 8yZuCabs4xK3w6Wp8C1cNadDesTe91D8P2Ygk1H+DT2pO10QEQ4Ciy5eOusj6UlYkJX9 jb8o6Fj8u3SB0go2IYdqURnNjerXoVB9Xeoy3aZVtbiV6L4/l3+w7fXfKcKAmY2qz/KO o66FLZ5WnOqNrlTUv6Ms+rLbTNphhpFjvSU0n4tToVKi+uJSpdjpxAU8Y7gfHYVx9sPn OMGg== Received: by 10.68.228.98 with SMTP id sh2mr33157298pbc.95.1349462995188; Fri, 05 Oct 2012 11:49:55 -0700 (PDT) Received: from spandex.local (66-230-86-185-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.185]) by mx.google.com with ESMTPS id vj8sm6443747pbc.6.2012.10.05.11.49.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 11:49:54 -0700 (PDT) Message-ID: <506F2BD0.8090507@gmail.com> Date: Fri, 05 Oct 2012 10:49:52 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <201210051634.MAA26300@adminfs.snmp.com> In-Reply-To: <201210051634.MAA26300@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 05 Oct 2012 18:49:56 -0000 How are we doing on getting a draft together on this? Melinda From melinda.shore@gmail.com Fri Oct 12 14:04:27 2012 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 969E421F8757 for ; Fri, 12 Oct 2012 14:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUdJ3wi5-OXZ for ; Fri, 12 Oct 2012 14:04:26 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 982CA21F8712 for ; Fri, 12 Oct 2012 14:04:26 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3261194pbb.31 for ; Fri, 12 Oct 2012 14:04:26 -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=Pj8lp7OzdsFKukDoYs2Se6vqRIV0pa2LThyq+uMhkWo=; b=Zmlt31Ml6Mq7Dk/UyjkQcenkDgfAN32VaqvqsHAL00U3P6yLEFsrtSU6vWWKAqpBol 4OkpJm35VYgc5+ix1FpvSkFwOB3RzcAhTrN8mQK5tWBZ/y5Yq5GpZdTu65jfw+96GTpo LuleXawNufueHXubUT81V0z8Vw5u6euaJl4uUAgLnn5ubT+AFYJ9O6r1kC29ZEsiamEN pMTR45TjHO9S8vvmFYNSPLkHezR458pozsercAvEoMH/BC7C8nB+7jrzCl0Jk3ds5WAk MIFdRvfvI9c88gvT+Mid5sYzYPVbYWuPxP7QjFhIWNmT5ILRBaS4Bv9G+WEabRGBoxiD zCEA== Received: by 10.68.125.133 with SMTP id mq5mr16796757pbb.138.1350075866428; Fri, 12 Oct 2012 14:04:26 -0700 (PDT) Received: from spandex.local (66-230-86-185-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.185]) by mx.google.com with ESMTPS id kj10sm4947589pbc.72.2012.10.12.14.04.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 14:04:25 -0700 (PDT) Message-ID: <507885D7.7010003@gmail.com> Date: Fri, 12 Oct 2012 13:04:23 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <24B20D14B2CD29478C8D5D6E9CBB29F62BF03947@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F62BF03947@Hermes.columbia.ads.sparta.com> X-Forwarded-Message-Id: <24B20D14B2CD29478C8D5D6E9CBB29F62BF03947@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Upcoming dates 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, 12 Oct 2012 21:04:27 -0000 Sandra Murphy (sidr) put together this handy list of dates. If you'll be asking for time in the opsawg session, this is a great time to post to the list and get some discussion started. Thanks, Melinda -------- Original Message -------- Subject: [sidr] upcoming important events Date: Fri, 12 Oct 2012 20:50:08 +0000 From: Murphy, Sandra To: sidr@ietf.org Here are some important dates to keep in mind for IETF85: 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00. 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00. 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00. 2012-10-26 (Friday): Early Bird registration and payment cut-off at UTC 24:00. 2012-10-29 (Monday): Revised Working Group agendas due by UTC 24:00. 2012-10-29 (Monday): Registration cancellation cut-off at UTC 24:00. If anyone is proposing submitting a -00 draft with a wg name (draft-ietf-sidr-yadayada), you should let the co-chairs know. Chairs must approve any -00 wg draft. It helps if we know it is coming. --Sandy, speaking as wg co-chair _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From fred@cisco.com Sat Oct 13 21:36:51 2012 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 F12621F041C for ; Sat, 13 Oct 2012 21:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.295 X-Spam-Level: X-Spam-Status: No, score=-110.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6P2bJQe3Wga for ; Sat, 13 Oct 2012 21:36:49 -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 A949F21F8452 for ; Sat, 13 Oct 2012 21:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=623; q=dns/txt; s=iport; t=1350189406; x=1351399006; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/sthD5pwZUPXtpxHwQMVOxDf6BnyEEuX/ZwIyJTe62Y=; b=dFQM+R2KMHoJ7w4gUNpEVsYAGIXLUSyC/r7YockEm78pNhJZgsJZrF5w LPTW5Xya3aLFnL83zP4n2pBjY4HoJYJ0/r57QHAY3DYLZEUbd0c0FPH7/ jI6rYgmPkYzebUhcnc3yTdiKsg+lSJW08hvKeMP4timXeOwgKz1cCwQ27 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANxAelCtJXG+/2dsb2JhbABFv3CBCIIhAQEEEgEnPxACAQgiFBAyJQEBBA4NGodinQKfDJE2YAOkMYFrgm2CFw X-IronPort-AV: E=Sophos;i="4.80,583,1344211200"; d="scan'208";a="131337402" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 14 Oct 2012 04:36:46 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9E4ajV1009390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Oct 2012 04:36:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 23:36:45 -0500 From: "Fred Baker (fred)" To: ramki Krishnan Thread-Topic: [OPSAWG] new IETF draft - large flow load-balancing Thread-Index: Ac2av6rrKUaKQo5ATLKGesZWpiOTUwAgOoQQABXWhtAAFCDHoAOBvgqA Date: Sun, 14 Oct 2012 04:36:45 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B176C4D@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.153] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--28.865500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <6FB7ECC7A6C10542A1C919BA3A8D1503@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sanjay Khanna , Chris Liljenstolpe , "opsawg@ietf.org" Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing 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, 14 Oct 2012 04:36:51 -0000 A general remark: it would be good to spell out an acronym before using it = extensively in a paper. LAG is, I presume, Link Aggregation, and ECMP is Eq= ual-cost Multipath Routing. Should there be a reference to RFC 2991, 2992, or 4814? My general comment is that while this is an interesting algorithm that a ve= ndor might choose to implement and sell, it is far from the only algorithm = that could be used, and opportunistic load balancing could be automated rat= her than requiring continuous operator intervention. My personal recommenda= tion for the draft is that it should seek experimental status.= From ramk@Brocade.com Sun Oct 14 10:40:48 2012 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 A7B5D21F84D8 for ; Sun, 14 Oct 2012 10:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyBLr5hvYVkb for ; Sun, 14 Oct 2012 10:40:48 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFB121F846F for ; Sun, 14 Oct 2012 10:40:48 -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 q9EHei4w011756; Sun, 14 Oct 2012 10:40:44 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1801x8r01a-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Oct 2012 10:40:44 -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.2.309.2; Sun, 14 Oct 2012 10:40:55 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sun, 14 Oct 2012 10:40:55 -0700 From: ramki Krishnan To: "Fred Baker (fred)" Date: Sun, 14 Oct 2012 10:40:36 -0700 Thread-Topic: [OPSAWG] new IETF draft - large flow load-balancing Thread-Index: Ac2av6rrKUaKQo5ATLKGesZWpiOTUwAgOoQQABXWhtAAFCDHoAOBvgqAAA/fT2A= Message-ID: References: <8C48B86A895913448548E6D15DA7553B176C4D@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B176C4D@xmb-rcd-x09.cisco.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-14_04:2012-10-12, 2012-10-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1210140209 Cc: Sanjay Khanna , Chris Liljenstolpe , "opsawg@ietf.org" Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing 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, 14 Oct 2012 17:40:48 -0000 Hi Fred, Thanks for the comments. Please find answers inline. I will be uploading a new version shortly. Thanks, ramki -----Original Message----- From: Fred Baker (fred) [mailto:fred@cisco.com]=20 Sent: Saturday, October 13, 2012 9:37 PM To: ramki Krishnan Cc: Scott O. Bradner; Chris Liljenstolpe; Melinda Shore; opsawg@ietf.org; S= anjay Khanna Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing A general remark: it would be good to spell out an acronym before using it = extensively in a paper. LAG is, I presume, Link Aggregation, and ECMP is Eq= ual-cost Multipath Routing. [ramki Krishnan] will do. Should there be a reference to RFC 2991, 2992, or 4814? [ramki Krishnan] Probably not - these RFCs treat all flows alike and do no= t distinguish between large and small flows. My general comment is that while this is an interesting algorithm that a ve= ndor might choose to implement and sell, it is far from the only algorithm = that could be used, and opportunistic load balancing could be automated rat= her than requiring continuous operator intervention. My personal recommenda= tion for the draft is that it should seek experimental status. [ramki Krishnan] The draft suggests various techniques and their tradeoffs= for a locally optimized solution addressing the following scenarios 1) Dif= ferent links in the network experience different levels of utilization and,= thus, a more "targeted" solution is needed for those few hot-spots in the = network 2) Some networks may lack end-to-end visibility. This is based on f= eedback from Network Operators (especially Shane Amante from Level-3). The feedback from Network Operators was the preference for a manual interve= ntion for load-balancing, given the fact that moving large flows may have s= ome side effects. I will add automation of load balancing as a possible opt= ion. I would agree on the experimental status. From fred@cisco.com Sun Oct 14 13:15:39 2012 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 631CD21F849D for ; Sun, 14 Oct 2012 13:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.315 X-Spam-Level: X-Spam-Status: No, score=-110.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZniOLOhlmXx6 for ; Sun, 14 Oct 2012 13:15:35 -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 48FE421F849C for ; Sun, 14 Oct 2012 13:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=309; q=dns/txt; s=iport; t=1350245735; x=1351455335; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XSiUZwa5gAQ7iqVBnjfkQs1EClZohk7Ugnpo847IeRk=; b=Ttz66XBVGVdJnl5wGvLTldUFcLzWhOQNVWLmO4F+Mo5AhT2XFetVIXST LfD3MejGh2cwsoSL2VtUuUW8rybDyh93Vz1iH8YFQ4ShqDsZ5yQDfonQN 6RHg8ae3PMZ/ODdMidYFQ0LJs+kJv21nekUFfPnJ1VdrgomxdtwMERFbM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGcce1CtJXG9/2dsb2JhbABFv3GBCIIgAQEBBBIBJz8QAgEIGAoUEDIlAgQODRqHYp0RnnuLWYVdYAOkMYFrgm2CFw X-IronPort-AV: E=Sophos;i="4.80,584,1344211200"; d="scan'208";a="131467159" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 14 Oct 2012 20:15:35 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9EKFY2n006101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Oct 2012 20:15:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 15:15:34 -0500 From: "Fred Baker (fred)" To: ramki Krishnan Thread-Topic: [OPSAWG] new IETF draft - large flow load-balancing Thread-Index: Ac2av6rrKUaKQo5ATLKGesZWpiOTUwAgOoQQABXWhtAAFCDHoAOBvgqAAA/fT2AADwXHAA== Date: Sun, 14 Oct 2012 20:15:33 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B177335@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B176C4D@xmb-rcd-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.13] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--27.607800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <2EBDF549871A4545805DA0DEA7CB92C5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sanjay Khanna , Chris Liljenstolpe , "opsawg@ietf.org" Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing 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, 14 Oct 2012 20:15:39 -0000 On Oct 15, 2012, at 4:40 AM, ramki Krishnan wrote: > Should there be a reference to RFC 2991, 2992, or 4814? >=20 > [ramki Krishnan] Probably not - these RFCs treat all flows alike and do n= ot distinguish between large and small flows. True. But they describe the hashing algorithms you refer to.= From internet-drafts@ietf.org Sun Oct 14 15:03:00 2012 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 21A2521F8501; Sun, 14 Oct 2012 15:03:00 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTjVi1xZE4hE; Sun, 14 Oct 2012 15:02:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7621521F84F6; Sun, 14 Oct 2012 15:02:59 -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.34 Message-ID: <20121014220259.8893.32592.idtracker@ietfa.amsl.com> Date: Sun, 14 Oct 2012 15:02:59 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-lsn-deployment-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: Sun, 14 Oct 2012 22:03:00 -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 : CGN Deployment with BGP/MPLS IP VPNs Author(s) : Victor Kuarsingh John Cianfarani Filename : draft-ietf-opsawg-lsn-deployment-01.txt Pages : 17 Date : 2012-10-14 Abstract: This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also contain a NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows the CGN platform to be integrated into the network meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-lsn-deployment-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From victor.kuarsingh@gmail.com Sun Oct 14 15:07:49 2012 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 5B78521F84FC for ; Sun, 14 Oct 2012 15:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wal2MDy6--eR for ; Sun, 14 Oct 2012 15:07:48 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C084621F84F8 for ; Sun, 14 Oct 2012 15:07:48 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so8110566iec.31 for ; Sun, 14 Oct 2012 15:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=Byr+lrX7FBybGifASnrG5IfH40FPmxNqjFjq8ayLVYA=; b=bRtMrps9bjYnS4xJNV8fgXSsnzD2m6d3fgQyrxnnVa2Wp940pbrciWW+of4loiXWUK MSclTt88nEdSit7Wo9QZS9JCwKIVQBSTiBGFCSh1RFjRKDVa5Y8YDzN+WNS2kr21Zukf 9TBL9oKId8t91owuM1D2Q2AjKqHD2EOTe39gOFcmiLo5y7E8p+ova97FjQC1y+dr5L82 2YAFk8hQl/QUfryC1StF64bWZUpWzv1anPlHdC3rEdBo6Yx7V6nL1t0rBe6Vn2TiZ2lk mb53HufCpgpnS4Wd7LHPikk9dgfVzyFm74H935zX63vK2EHpFgcV5eM4R5E/AlE4J+Xx AnbA== Received: by 10.50.194.132 with SMTP id hw4mr7177469igc.35.1350252467464; Sun, 14 Oct 2012 15:07:47 -0700 (PDT) Received: from [192.168.100.204] ([67.224.83.162]) by mx.google.com with ESMTPS id ez8sm4831538igb.17.2012.10.14.15.07.38 (version=SSLv3 cipher=OTHER); Sun, 14 Oct 2012 15:07:43 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 14 Oct 2012 18:07:30 -0400 From: Victor Kuarsingh To: , Message-ID: Thread-Topic: New Version Notification for draft-ietf-opsawg-lsn-deployment-01.txt In-Reply-To: <20121014220259.8893.39384.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [OPSAWG] FW: New Version Notification for draft-ietf-opsawg-lsn-deployment-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: Sun, 14 Oct 2012 22:07:49 -0000 Chairs/Group, I have posted an update to the LSN deployment draft. I have removed some of the original content around CGN performance and replaced it with a referent to [donley-nat444-impacts] since that document is more complete (which was not available when this draft was first posted a while back). Made some other minor edits/changes. Overall, I have not receive much in the way of comments. I would appreciate comments, but given the historical conversation on this draft, I am not sure if I will get much more. I did email (following IETF84) v4sunset behave previously for comments, but did not receive any. If the group/chairs are willing, I would like to move to WGLC if possible. Regards, Victor Kuarsingh On 2012-10-14 6:02 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-opsawg-lsn-deployment-01.txt >has been successfully submitted by Victor Kuarsingh and posted to the >IETF repository. > >Filename: draft-ietf-opsawg-lsn-deployment >Revision: 01 >Title: CGN Deployment with BGP/MPLS IP VPNs >Creation date: 2012-10-15 >WG ID: opsawg >Number of pages: 17 >URL: >http://www.ietf.org/internet-drafts/draft-ietf-opsawg-lsn-deployment-01.tx >t >Status: >http://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment >Htmlized: >http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-01 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-lsn-deployment-01 > >Abstract: > This document specifies a framework to integrate a Network Address > Translation layer into an operator's network to function as a Carrier > Grade NAT (also known as CGN or Large Scale NAT). The CGN > infrastructure will often form a NAT444 environment as the subscriber > home network will likely also contain a NAT function. Exhaustion of > the IPv4 address pool is a major driver compelling some operators to > implement CGN. Although operators may wish to deploy IPv6 to > strategically overcome IPv4 exhaustion, near term needs may not be > satisfied with an IPv6 deployment alone. This document provides a > practical integration model which allows the CGN platform to be > integrated into the network meeting the connectivity needs of the > subscriber while being mindful of not disrupting existing services > and meeting the technical challenges that CGN brings. The model > included in this document utilizes BGP/MPLS IP VPNs which allow for > virtual routing separation helping ease the CGNs impact on the > network. This document does not intend to defend the merits of CGN. > > > > > >The IETF Secretariat > From ramk@Brocade.com Sun Oct 14 16:02:50 2012 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 BE63721F851B for ; Sun, 14 Oct 2012 16:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC2T544qMF0I for ; Sun, 14 Oct 2012 16:02:50 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 30D0F21F851A for ; Sun, 14 Oct 2012 16:02:50 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id q9EN2nOH031148 for ; Sun, 14 Oct 2012 16:02:49 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 17yx0t851k-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 14 Oct 2012 16:02:49 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 14 Oct 2012 16:02:59 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Sun, 14 Oct 2012 16:02:47 -0700 From: ramki Krishnan To: "opsawg@ietf.org" Date: Sun, 14 Oct 2012 16:02:45 -0700 Thread-Topic: New Version Notification for draft-krishnan-large-flow-load-balancing-01.txt Thread-Index: Ac2qX7glxrLRQ+IlSsiptonk0rKnbgAABZmw Message-ID: 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.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-14_06:2012-10-12, 2012-10-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1210140307 Subject: [OPSAWG] FW: New Version Notification for draft-krishnan-large-flow-load-balancing-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: Sun, 14 Oct 2012 23:02:50 -0000 QWxsLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cyBzbyBmYXIuIEEgbmV3IHZlcnNpb24gb2Yg dGhlIGRyYWZ0IGhhcyBiZWVuIHBvc3RlZC4gV291bGQgYmUgZ2xhZCB0byByZWNlaXZlIG1vcmUg Y29tbWVudHMuDQoNClRoYW5rcywgcmFta2kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQpTZW50OiBTdW5kYXksIE9jdG9iZXIgMTQsIDIwMTIgNDowMCBQTQ0KVG86IHJh bWtpIEtyaXNobmFuDQpDYzogcmFta2kgS3Jpc2huYW47IFNhbmpheSBLaGFubmE7IGFub29wQGFs dW1uaS5kdWtlLmVkdTsgYmh1bWlwLmtoYXNuYWJpc2hAenRldXNhLmNvbQ0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rcmlzaG5hbi1sYXJnZS1mbG93LWxvYWQt YmFsYW5jaW5nLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1rcmlzaG5h bi1sYXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSByYW0ga3Jpc2huYW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWtyaXNobmFuLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNp bmcNClJldmlzaW9uOgkgMDENClRpdGxlOgkJIEJlc3QgUHJhY3RpY2VzIGZvciBPcHRpbWFsIExB Ry9FQ01QIENvbXBvbmVudCBMaW5rIFV0aWxpemF0aW9uIGluIFByb3ZpZGVyIEJhY2tib25lIG5l dHdvcmtzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0xMC0xNA0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE1DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtyaXNobmFuLWxhcmdlLWZsb3ctbG9h ZC1iYWxhbmNpbmctMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQta3Jpc2huYW4tbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZw0KSHRt bGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rcmlzaG5hbi1s YXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWtyaXNobmFuLWxhcmdlLWZsb3ctbG9hZC1iYWxh bmNpbmctMDENCg0KQWJzdHJhY3Q6DQogICBUaGUgZGVtYW5kcyBvbiB0aGUgbmV0d29ya2luZyBp bmZyYXN0cnVjdHVyZSBhcmUgZ3Jvd2luZw0KICAgZXhwb25lbnRpYWxseTsgdGhlIGRyaXZlcnMg YXJlIGJhbmR3aWR0aCBodW5ncnkgcmljaCBtZWRpYQ0KICAgYXBwbGljYXRpb25zLCBpbnRlciBk YXRhIGNlbnRlciBjb21tdW5pY2F0aW9ucyBldGMuIEluIHRoaXMgY29udGV4dCwNCiAgIGl0IGlz IGltcG9ydGFudCB0byBvcHRpbWFsbHkgdXNlIHRoZSBiYW5kd2lkdGggaW4gdGhlIHNlcnZpY2UN CiAgIHByb3ZpZGVyIGJhY2tib25lIG5ldHdvcmtzIHdoaWNoIGV4dGVuc2l2ZWx5IHVzZSBMQUcv RUNNUCB0ZWNobmlxdWVzDQogICBmb3IgYmFuZHdpZHRoIHNjYWxpbmcuIFRoaXMgaW50ZXJuZXQg ZHJhZnQgZGVzY3JpYmVzIHRoZSBpc3N1ZXMgZmFjZWQNCiAgIGluIHRoZSBzZXJ2aWNlIHByb3Zp ZGVyIGJhY2tib25lIGluIHRoZSBjb250ZXh0IG9mIExBRy9FQ01QIGFuZA0KICAgZm9ybXVsYXRl cyBiZXN0IHByYWN0aWNlIHJlY29tbWVuZGF0aW9ucyBmb3IgbWFuYWdpbmcgdGhlIGJhbmR3aWR0 aA0KICAgZWZmaWNpZW50bHkgaW4gdGhlIHNlcnZpY2UgcHJvdmlkZXIgYmFja2JvbmUuDQoNCklu dGVybmV0LURyYWZ0ICAgQmVzdCBQcmFjdGljZXMgZm9yIE9wdGltYWwgTEFHL0VDTVAgQ29tcG9u ZW50IExpbmsNCiAgICAgICAgICBVdGlsaXphdGlvbiBpbiBQcm92aWRlciBCYWNrYm9uZSBuZXR3 b3JrcyAgICAgICAgT2N0b2JlciAyMDEyDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From melinda.shore@gmail.com Mon Oct 15 11:05:15 2012 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 A733221F889A for ; Mon, 15 Oct 2012 11:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdl91LRHvUfq for ; Mon, 15 Oct 2012 11:05:10 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF74F21F8898 for ; Mon, 15 Oct 2012 11:05:09 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so2678461dan.31 for ; Mon, 15 Oct 2012 11:05:06 -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=2EkPsSkYQVYAIzghOsC9h4u2aDrNATNB+fnLWD3AfTg=; b=TfqAz/piznopHUvhN+DbE1ioj6VvtDPureOOwN6e6aCu6dkVTrPlPxF15pUTRBxSHS WuPKONfnhlMQkOm4N/0+05y1JLafKBnsywEy1bvTfJR7t+mKyhsEp98CzRubvuHLZqVL F3cMTayHOF84udwB0Zpbh8SyhH5P4rqt43wyu1rZ+eXfotMFc7QiNFCbPTQsbIKNAsje LXNx5aZOhDwp3YgZqNdCWdcpIpXxm86+zEl5YMSWS3fNoEGeFiMq6KgPshw+P9Gxlkkj KWT/XvztsshHy5GsDb+1NpQdYj5mZJTSrWD0NBKqBiDbq3UWhI5stVj0Vasl5W6R9w8P 1kag== Received: by 10.68.217.104 with SMTP id ox8mr39358880pbc.35.1350324306304; Mon, 15 Oct 2012 11:05:06 -0700 (PDT) Received: from spandex.local (66-230-86-185-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.185]) by mx.google.com with ESMTPS id mn5sm9393034pbc.12.2012.10.15.11.05.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Oct 2012 11:05:04 -0700 (PDT) Message-ID: <507C504F.8080807@gmail.com> Date: Mon, 15 Oct 2012 10:05:03 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <20121015175109.26451.17876.idtracker@ietfa.amsl.com> In-Reply-To: <20121015175109.26451.17876.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121015175109.26451.17876.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: Internet Draft Initial Version (-00) Cut-Off Today 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 Oct 2012 18:05:16 -0000 FYI. Melinda -------- Original Message -------- Subject: Internet Draft Initial Version (-00) Cut-Off Today Date: Mon, 15 Oct 2012 10:51:09 -0700 From: IETF Secretariat To: IETF Announcement List This is a reminder that the Internet Draft Initial Version (-00) cut-off is today, Monday, October 15, 2012. All Initial Version (-00) submissions are due by UTC 24:00. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 85 can be found at: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85 Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. From iesg-secretary@ietf.org Tue Oct 16 08:22:37 2012 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 3DAFB21F8973; Tue, 16 Oct 2012 08:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkudIVOxMWUN; Tue, 16 Oct 2012 08:22:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA4B21F89C5; Tue, 16 Oct 2012 08:22:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121016152235.17162.48485.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 08:22:35 -0700 Cc: opsawg WG Subject: [OPSAWG] WG Action: Rechartered Operations and Management Area Working Group (opsawg) 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 Oct 2012 15:22:38 -0000 The Operations and Management Area Working Group (opsawg) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Operations and Management Area Working Group (opsawg) ------------------------------------------------ Current Status: Active Working Group Chairs: Scott Bradner Chris Liljenstolpe Melinda Shore Assigned Area Director: Ronald Bonica Mailing list Address: opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: http://www.ietf.org/mail-archive/web/opsawg Charter of Working Group: The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. The OPSAWG will serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. All new work items and rechartering proposals will be brought for approval with the IESG. The focus of the work will be on topics that govern the behavior or WGs in the O&M area (e.g., manageability requirements) and on small, highly focused projects that don't merit a WG of their own or belong to WGs that have already concluded (e.g. advancement of documents on the standards track, application statements, extensions of MIB modules). The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers. It is not within the scope of the OPSAWG to pick up failed WG work or parts of a WG charter items that could not come to convergence on what they were chartered to do. The currently active OPSAWG work items mostly fall under the following topics: (A) Templates and tools for Operations and Management Area Documents (B) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). (C) The RFC 5066 "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" has transitioned to the IEEE 802.3. However, as agreed with the IEEE, the IF-CAP-STACK-MIB MIB module (from RFC5066) is generic by nature and should continue to be supported by the IETF. The WG will develop a document extracting the IF-CAP-STACK-MIB from RFC5066, emphasizing the generic nature of this module, and obsolete RFC5066. (D) Documenting the list of RFCs transitioned to the IEEE 802.3.1-2011. Considering RFC 4663 "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" as an reference, the following pieces of information would the foundation for the document: a table mapping the old IETF MIB names with the corresponding new IEEE ones, clarifications/rules on the IETF-IEEE interactions (mailing lists, reviews), and clarifications on the intellectual property considerations. Milestones: Done - Initial submission for the 'SNMP Engine ID Discovery' Internet-Draft Done - Initial submission for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Initial submission for the 'Template for Generic Management Data Models' Internet-Draft Done - Initial submission for the 'Structured Data Elements (SDEs) for syslog' Internet-Draft Done - WGLC for the 'SNMP Engine ID Discovery' Internet-Draft Done - Submit the 'SNMP Engine ID Discovery' Internet-Draft to the IESG for consideration as Proposed Standard Done - WGLC for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Submit the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft to the IESG for consideration as BCP Done - WGLC for the 'Structured Data Elements (SDEs) for syslog' Done - Submit the 'Structured Data Elements (SDEs) for syslog' to the IESG for consideration as Proposed Standard Oct 2012 - Initial submission for the 'IF-CAP-STACK-MIB MIB module' Internet-Draft Oct 2012 - Initial submission for the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft Mar 2013 - Submit the 'IF-CAP-STACK-MIB MIB module' Internet-Draft to the IESG for consideration as Proposed Standard Mar 2013 - Submit the 'RFCs transitioned to the IEEE 802.3.1-2011' Internet-Draft to the IESG for consideration as Informational From mehmet.ersue@nsn.com Wed Oct 17 01:18:04 2012 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 2D0E821F879F; Wed, 17 Oct 2012 01:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve0MDJ3nsF0I; Wed, 17 Oct 2012 01:18:03 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0DB21F8771; Wed, 17 Oct 2012 01:18:02 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9H8Hxbl016776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Oct 2012 10:17:59 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9H8HqMJ016304; Wed, 17 Oct 2012 10:17:59 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Oct 2012 10:17:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Oct 2012 10:17:48 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt Thread-Index: Ac2sP+SCkqdxpWNGTieoJPjKQSY0pA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 17 Oct 2012 08:17:49.0553 (UTC) FILETIME=[E56B1610:01CDAC3F] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1790 X-purgate-ID: 151667::1350461879-000048BF-F962D7E1/0-0/0-0 Cc: opsawg@ietf.org Subject: [OPSAWG] FW: New Version Notification for draft-ersue-constrained-mgmt-02.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, 17 Oct 2012 08:18:04 -0000 Hi All, we submitted an update for the constrained-mgmt draft on the "Management of Networks with Constrained Devices: Use Cases and Requirements". The draft hopefully addresses most of the issues we discussed in the last meeting.=20 I think it is already time to split the draft into three; e.g. problem statement, use cases and requirements. But this can be done after getting your feedback before and during IETF 85. I would highly appreciate your comments and any kind of discussion on the draft content especially on the requirements section. Thank you. Cheers,=20 Mehmet=20 -----Original Message----- From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 15, 2012 9:59 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: dromasca@avaya.com; j.schoenwaelder@jacobs-university.de Subject: New Version Notification for draft-ersue-constrained-mgmt-02.txt A new version of I-D, draft-ersue-constrained-mgmt-02.txt has been successfully submitted by Mehmet Ersue and posted to the IETF repository. Filename: draft-ersue-constrained-mgmt Revision: 02 Title: Management of Networks with Constrained Devices: Use Cases and Requirements Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 78 URL: http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt Status: http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt Htmlized: http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrained-mgmt-02 Abstract: This document raises the questions on and discusses the use cases and requirements for the management of networks with constrained devices. =20 The IETF Secretariat From denghui02@gmail.com Thu Oct 18 01:36:48 2012 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 4AE9121F84DF for ; Thu, 18 Oct 2012 01:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.05 X-Spam-Level: X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUIsCIfGAH42 for ; Thu, 18 Oct 2012 01:36:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B965121F84EE for ; Thu, 18 Oct 2012 01:36:47 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so9983497obq.31 for ; Thu, 18 Oct 2012 01:36:47 -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=Zeffc2AF0ug1PPOj/UY+dgqczTs2oW/hgtQYMXW3ni4=; b=MDx/oaiU7YnCyYcVKnA8t9y7xQX2N8ltjIh4ORMcziF8rp8nrgaOCePUu4k4sXzrrO zhTBdOdQx1FIMcqfCrssjcyWLftDKZ4cF4+PAwhq/R/2gg9RVu/ErThuvLdPzR04Huhc xeUW2cmkqkaYBxAclhkR1WgVRc0qUS4POaQzvmql+xSwJep6paypNPqEoVmJKCCa6z+T EFVfQKsyEUlp7lBXsS6lt/RYZ3XVVyiGV3xspEy7FLIc2sidnftDXILTvbUt8KeSjccY NHO1PB4jY8+kW/PXCfHVZ2hsz+RSGuKxAvNGhoIZPcbUkW1ZVz95lXFfLGvCgybJh9sx w9nQ== MIME-Version: 1.0 Received: by 10.60.1.40 with SMTP id 8mr16553092oej.55.1350549407214; Thu, 18 Oct 2012 01:36:47 -0700 (PDT) Received: by 10.182.17.164 with HTTP; Thu, 18 Oct 2012 01:36:47 -0700 (PDT) Date: Thu, 18 Oct 2012 16:36:47 +0800 Message-ID: From: Hui Deng To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=e89a8f643544ab2a8004cc5149b0 Subject: [OPSAWG] Request for comments on CAPWAP related draft 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, 18 Oct 2012 08:36:48 -0000 --e89a8f643544ab2a8004cc5149b0 Content-Type: text/plain; charset=ISO-8859-1 Hello OPS Quite recently, there are large carrier grade wifi deployment because of mobile Internet data congestion in the air interface. And there become more strong demand about the successful usage of CAPWAP protocl which is invented by IETF. It will help operator to deploy more than couple of millions of Wifi APs, in this case, we have writen drafts about further work on capwap extension, Hope you could kindly help to review and comment them, PS: https://datatracker.ietf.org/doc/draft-shao-capwap-plus-ps/ EAP extension http://www.ietf.org/internet-drafts/draft-cao-capwap-eap-00.txt Thanks a lot for your kind review. Best regards, -Hui --e89a8f643544ab2a8004cc5149b0 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hello OPS
 
Quite recently, there are large c= arrier grade wifi deployment because of mobile Internet data congestion in = the air interface. And there become more strong demand about the successful= usage of CAPWAP protocl which is invented by IETF. It will help operator t= o deploy more than couple of millions of Wifi APs, in this case, we have wr= iten drafts about further work on capwap extension, Hope you could kindly h= elp to review and comment them,
 
PS:

EAP extension

http://www.ietf.org/internet-drafts/draft-cao-capwap-eap-00.tx= t

Thanks a lot for y= our kind review.
Be= st regards,
=  
-Hui
--e89a8f643544ab2a8004cc5149b0-- From satoru.matsushima@gmail.com Thu Oct 18 02:41:21 2012 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 93EAA21F85A7 for ; Thu, 18 Oct 2012 02:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saGyh2jyIt1w for ; Thu, 18 Oct 2012 02:41:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC9B21F85A4 for ; Thu, 18 Oct 2012 02:41:21 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so8162639pbb.31 for ; Thu, 18 Oct 2012 02:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=GBL4bVOmB7jnKkLitqYeFhnNGK2wScl8JmvLXcUpAbE=; b=GKBgz4SyW7xeshxjWmyDATsvc+KXrCZuvH/qLZHK5sy1TZZjeY1UmEGhFKk4chZwso 02mr3Ppujea6TgAj0jaReD9g1/BqKS2VHX+wr/HD5BTnK4KqY15U8lRpCp++4/sftmAP pVG5Tvww/yVxJBXRv6aQFu8K286dcBW/zqp1wTUIwvRdAQIPeFyoXFmpwUtXYCBbALOy xS+KU+cmXgn1e8CrPrSO9hL6u8VtlcPFxFPIzRSD6X9kITYQ2NTSwLuyRqk5mq+WuPsq i4L/TwUpI1c0DwOgejudXfYvC3yAwhRfBIB6PxWAAm1GdY/3zfvAP9qHKDMDzLqyzsMP 9CMg== Received: by 10.68.237.231 with SMTP id vf7mr32068310pbc.63.1350553280891; Thu, 18 Oct 2012 02:41:20 -0700 (PDT) Received: from [10.201.82.236] ([202.45.12.141]) by mx.google.com with ESMTPS id ka4sm13976995pbc.61.2012.10.18.02.41.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 02:41:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=GB2312 From: Satoru Matsushima In-Reply-To: Date: Thu, 18 Oct 2012 18:41:14 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> References: To: opsawg@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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, 18 Oct 2012 09:41:21 -0000 Hello Hui, Looks interesting. My first impression for these drafts is that the = local-mac, another capwap model, has also supported EAP. Why do you need = split-mac for EAP particularly? BTW, the right place in the IETF to discuss them would be capwap but it = has already closed. Does the IETF work work CAPWAP stuff again? cheers, --satoru >=20 > Hello OPS > =20 > Quite recently, there are large carrier grade wifi deployment because = of mobile Internet data congestion in the air interface. And there = become more strong demand about the successful usage of CAPWAP protocl = which is invented by IETF. It will help operator to deploy more than = couple of millions of Wifi APs, in this case, we have writen drafts = about further work on capwap extension, Hope you could kindly help to = review and comment them, > =20 > PS: > https://datatracker.ietf.org/doc/draft-shao-capwap-plus-ps/ > EAP extension > http://www.ietf.org/internet-drafts/draft-cao-capwap-eap-00.txt > Thanks a lot for your kind review. > Best regards, > =20 > -Hui >=20 From denghui02@gmail.com Thu Oct 18 07:21:09 2012 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 9B0E521F8822 for ; Thu, 18 Oct 2012 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFLzANFWMsTE for ; Thu, 18 Oct 2012 07:21:08 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8748F21F8829 for ; Thu, 18 Oct 2012 07:21:08 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so7767572qcg.31 for ; Thu, 18 Oct 2012 07:21:08 -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=vCkoAKqiFpdESN40M3B7ZdCE0tbrwT576z/ZpkiPs/w=; b=hrgFBS4U+ZnqE331I2mcV1Kx4lZetnPDZdnkDZ0K5MCtC70T/oYVeucWZexkjZ1HHJ csaeQvpFkZHjHK3zJgi4teNAU/pXKo3uHmq5Tr/4XfZA+UXmYC3JuoMzU5GDNpTD1AWv U55W13TTWRAeDDlPvMe97Dzna+Ukm0VEqwjDh2OoYAUjisF3WfPLL+aEbf2sc2wd+Nyh SwkPGld8AjzqytoayqRq7DDOuSpDuzyA836qmZEyrJIX6cYnrgZ/iRZIimn5eOquUAL0 3lVkaZn3Q9w6slS5NPthTf4gw9klSm09Ny5TwiGOVjQ0MuCrJVWXzpK4063Shlf0iTAR UR9g== MIME-Version: 1.0 Received: by 10.229.209.220 with SMTP id gh28mr9536180qcb.19.1350570067979; Thu, 18 Oct 2012 07:21:07 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Thu, 18 Oct 2012 07:21:07 -0700 (PDT) In-Reply-To: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> References: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> Date: Thu, 18 Oct 2012 22:21:07 +0800 Message-ID: From: Hui Deng To: Satoru Matsushima Content-Type: multipart/alternative; boundary=0016e6d2746d256c2d04cc561973 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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, 18 Oct 2012 14:21:10 -0000 --0016e6d2746d256c2d04cc561973 Content-Type: text/plain; charset=ISO-8859-1 Hello Satoru, Thanks a lot for your comments, I guess it is not clear in our document, because chapter says. 3. Supporting EAP authencation in Wifi network . . . . . . . . . . 3 3.1. Scenario Description . . . . . . . . . . . . . . . . . . . 3 4. The scope of definition of split MAC mode . . . . . . . . . . . 4 Section 4 could lead people think that we are only working on the split MAC, actually the local MAC don't need define the scope, we specify both split and local MAC. Thanks again for your kind review. Best regards, -Hui 2012/10/18 Satoru Matsushima > Hello Hui, > > Looks interesting. My first impression for these drafts is that the > local-mac, another capwap model, has also supported EAP. Why do you need > split-mac for EAP particularly? > > BTW, the right place in the IETF to discuss them would be capwap but it > has already closed. Does the IETF work work CAPWAP stuff again? > > cheers, > --satoru > > > > > Hello OPS > > > > Quite recently, there are large carrier grade wifi deployment because of > mobile Internet data congestion in the air interface. And there become more > strong demand about the successful usage of CAPWAP protocl which is > invented by IETF. It will help operator to deploy more than couple of > millions of Wifi APs, in this case, we have writen drafts about further > work on capwap extension, Hope you could kindly help to review and comment > them, > > > > PS: > > https://datatracker.ietf.org/doc/draft-shao-capwap-plus-ps/ > > EAP extension > > http://www.ietf.org/internet-drafts/draft-cao-capwap-eap-00.txt > > Thanks a lot for your kind review. > > Best regards, > > > > -Hui > > > > --0016e6d2746d256c2d04cc561973 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Satoru,
=A0
Thanks a lot for your comments, =
=A0
I guess it is not clear in our document, because c= hapter says.
3. Supporting EAP authencation in Wifi network . . = . . . . . . . . 3
3.1. Scenario Description . . . . . . . . . . . . . . . . . . . 3
4= . The scope of definition of split MAC mode . . . . . . . . . . . 4
Sec= tion 4 could lead people think that we are only working on the split MAC, a= ctually the local MAC don't need define the scope,

we specify both split and local MAC.
=A0
Thank= s again for your kind review.
Best regards,
=A0
-Hui
=A0
2012/10/18 Satoru Mat= sushima <satoru.matsushima@gmail.com>
Hello Hui,

Looks interesting. My first impression for these drafts is that the local-m= ac, another capwap model, has also supported EAP. Why do you need split-mac= for EAP particularly?

BTW, the right place in the IETF to discuss them would be capwap but it has= already closed. Does the IETF work work CAPWAP stuff again?

cheers,
--satoru

>
> Hello OPS
>
> Quite recently, there are large carrier grade wifi deployment because = of mobile Internet data congestion in the air interface. And there become m= ore strong demand about the successful usage of CAPWAP protocl which is inv= ented by IETF. It will help operator to deploy more than couple of millions= of Wifi APs, in this case, we have writen drafts about further work on cap= wap extension, Hope you could kindly help to review and comment them,
>
> PS:
> https://datatracker.ietf.org/doc/draft-shao-capwap-plus= -ps/
> EAP extension
> http://www.ietf.org/internet-drafts/draft-cao-capwa= p-eap-00.txt
> Thanks a lot for your kind review.
> Best regards,
>
> -Hui
>


--0016e6d2746d256c2d04cc561973-- From satoru.matsushima@gmail.com Thu Oct 18 08:47:52 2012 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 A189621F87FB for ; Thu, 18 Oct 2012 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGK7uNumUYo6 for ; Thu, 18 Oct 2012 08:47:52 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D70A121F87E3 for ; Thu, 18 Oct 2012 08:47:51 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2420082eaa.31 for ; Thu, 18 Oct 2012 08:47:51 -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=H/GB+LmnDfyADr2Z/AjYZCh+OVwg7yRlD9eLXxta874=; b=zAhL3P8tACurjWjntGBXO5pW0TrI/lX3lSA+e0EQp80uivIMvm1wp1b3x3MfRkV7/f dvndDuON0lYV/nmvFLvrGsWnXKSqTKGU4Qt7xvoSsUssVz+Mnm8Y6VMiNxljlPfwYUBY M7+OhLMfZbLHB+h4jDMBjWUOIHvJWciqLnuUxt5cBVDFEZjaMied8II7f0OrDUpz/xU3 BU9SRG9A1Stf4/Tuk29M2xs6hycX7MuFFwoV+UOp75QYH9rap/yc2Y+7lXW39GLFfvGk g0OTWS+PZE/RDbH+nkFUQIOH8jqkjniJ0CoVg5o11SNVy7d+R6y9CIlbhFSoy/jcW8u6 BtbQ== MIME-Version: 1.0 Received: by 10.14.203.69 with SMTP id e45mr31999119eeo.38.1350575270987; Thu, 18 Oct 2012 08:47:50 -0700 (PDT) Received: by 10.14.208.195 with HTTP; Thu, 18 Oct 2012 08:47:50 -0700 (PDT) In-Reply-To: References: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> Date: Fri, 19 Oct 2012 00:47:50 +0900 Message-ID: From: Satoru Matsushima To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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, 18 Oct 2012 15:47:52 -0000 Hui, On Thu, Oct 18, 2012 at 11:21 PM, Hui Deng wrote: > Hello Satoru, > > Thanks a lot for your comments, > > I guess it is not clear in our document, because chapter says. > 3. Supporting EAP authencation in Wifi network . . . . . . . . . . 3 > 3.1. Scenario Description . . . . . . . . . . . . . . . . . . . 3 > 4. The scope of definition of split MAC mode . . . . . . . . . . . 4 > Section 4 could lead people think that we are only working on the split MAC, > actually the local MAC don't need define the scope, > Thanks your clarification. In addition, split-mac mode is also assumed in section 3. > we specify both split and local MAC. > My question is why local-mac couldn't solve your problem. As far as I know, any local-mac mode AP needs to encapsulate EAP packet into neither CAPWAP-DATA nor CTL because AP send messages to AAA server as EAP authenticator. cheers, --satoru From internet-drafts@ietf.org Thu Oct 18 15:50:56 2012 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 1456E1F0417; Thu, 18 Oct 2012 15:50:56 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JypJRFembosa; Thu, 18 Oct 2012 15:50:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F3D21F85C2; Thu, 18 Oct 2012 15:50:55 -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.34 Message-ID: <20121018225055.13626.59722.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 15:50:55 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-firewalls-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: Thu, 18 Oct 2012 22:50:56 -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 : On Firewalls in Internet Security Author(s) : Fred Baker Paul Hoffman Filename : draft-ietf-opsawg-firewalls-01.txt Pages : 10 Date : 2012-10-18 Abstract: This document discusses the most important operational and security implications of using modern firewalls in networks. It makes recommendations for operators of firewalls, as well as for firewall vendors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-firewalls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-firewalls-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zehn.cao@gmail.com Thu Oct 18 19:16:48 2012 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 4D2DD1F042A for ; Thu, 18 Oct 2012 19:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JRB8PRjS57i for ; Thu, 18 Oct 2012 19:16:47 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE621F849F for ; Thu, 18 Oct 2012 19:16:46 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so16978777iec.31 for ; Thu, 18 Oct 2012 19:16:46 -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=SYVMV223W8kzNFQ8cA3dyB5VbwisNaVTpfDgnYYV18c=; b=gKdqn92cL+jiGEPIske2Sf79lsAEr/kw2YDHQR257V2L0m3vavSmXZZIO3VhioSXbq OIXQJT3v6wC9FKa0eiy7qLDYISUfsXbeRqy3xgop3J0Tabiv17YP9aYZvtuz8G1flkdr 1/4cOal1YzM4yTeCDk2kYCAKXBzNN6uuKIrUSQGPvNJQHPir9VvXbjnAhMMK3MKHOPXC Vkd2GCxwRg2UXNpUKC/wVvsX2AMRjU2HZm/uhyWw+UQZA7vhZ+FEPo0HRRRFvAa/Tnjs J6I4HWKh4RMxU0/tKIdB0lufoJxJ6s9EHqS7VeVhYKfcR8eE8V6U5ed9g9MTTQT8yM0O COSA== MIME-Version: 1.0 Received: by 10.50.209.71 with SMTP id mk7mr6894846igc.34.1350613006555; Thu, 18 Oct 2012 19:16:46 -0700 (PDT) Received: by 10.64.64.102 with HTTP; Thu, 18 Oct 2012 19:16:46 -0700 (PDT) In-Reply-To: References: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> Date: Fri, 19 Oct 2012 10:16:46 +0800 Message-ID: From: Zhen Cao To: Satoru Matsushima Content-Type: multipart/alternative; boundary=14dae93404f97c192a04cc601825 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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 Oct 2012 02:16:48 -0000 --14dae93404f97c192a04cc601825 Content-Type: text/plain; charset=ISO-8859-1 Hi Satoru, Inline please. On Thu, Oct 18, 2012 at 11:47 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hui, > > On Thu, Oct 18, 2012 at 11:21 PM, Hui Deng wrote: > > Hello Satoru, > > > > Thanks a lot for your comments, > > > > I guess it is not clear in our document, because chapter says. > > 3. Supporting EAP authencation in Wifi network . . . . . . . . . . 3 > > 3.1. Scenario Description . . . . . . . . . . . . . . . . . . . 3 > > 4. The scope of definition of split MAC mode . . . . . . . . . . . 4 > > Section 4 could lead people think that we are only working on the split > MAC, > > actually the local MAC don't need define the scope, > > > > Thanks your clarification. In addition, split-mac mode is also assumed > in section 3. > > > we specify both split and local MAC. > > > > My question is why local-mac couldn't solve your problem. As far as I > know, any local-mac mode AP needs to encapsulate EAP packet into > neither CAPWAP-DATA nor CTL as far as i understand, the local-mac mode will encapsulate the CAPWAP message into 802.3 header. +-+wireless frames +-+ 802.3 frames +-+ | |----------------| |--------------| | | | | | | | | |----------------| |--------------| | | |wireless PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC > because AP send messages to AAA server as > EAP authenticator. > This way, when UE handover between different AP, the security session cannot be switched to the new AP. --cz > > cheers, > --satoru > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --14dae93404f97c192a04cc601825 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Satoru,=A0

Inline please.=A0

On Thu, Oct 18, 2012 at 11:47 PM, Satoru Matsushima <s= atoru.matsushima@gmail.com> wrote:
Hui,

On Thu, Oct 18, 2012 at 11:21 PM, Hui Deng <denghui02@gmail.com> wrote:
> Hello Satoru,
>
> Thanks a lot for your comments,
>
> I guess it is not clear in our document, because chapter says.
> 3. Supporting EAP authencation in Wifi network . . . . . . . . . . 3 > 3.1. Scenario Description . . . . . . . . . . . . . . . . . . . 3
> 4. The scope of definition of split MAC mode . . . . . . . . . . . 4 > Section 4 could lead people think that we are only working on the spli= t MAC,
> actually the local MAC don't need define the scope,
>

Thanks your clarification. In addition, split-mac mode is also assume= d
in section 3.

> we specify both split and local MAC.
>=A0

My question is why local-mac couldn't solve your problem. As far = as I
know, any local-mac mode AP needs to encapsulate EAP packet into
neither CAPWAP-DATA nor CTL

as far as i un= derstand, the local-mac mode will encapsulate the CAPWAP message into 802.3= header.
              +-+wireless frames +-+ 802.3 frames +-+
              | |----------------| |--------------| |
              | |                | |              | |
              | |----------------| |--------------| |
              | |wireless PHY/   | |     CAPWAP   | |
              | | MAC sublayer   | |              | |
              +-+                +-+              +-+
              STA                WTP               AC

=A0
because AP send messages to AAA server as
EAP authenticator.

This way, when UE ha= ndover between different AP, the security session cannot be switched to the= new AP.=A0

--cz
=A0

cheers,
--satoru
___________________________________= ____________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--14dae93404f97c192a04cc601825-- From satoru.matsushima@gmail.com Thu Oct 18 19:45:44 2012 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 079D821F8512 for ; Thu, 18 Oct 2012 19:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdV0sGl6jLm5 for ; Thu, 18 Oct 2012 19:45:43 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8868E21F852C for ; Thu, 18 Oct 2012 19:45:43 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2063pad.31 for ; Thu, 18 Oct 2012 19:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=sX9E5MU5bQGsFOWkpDZtpr8yON7Pl4cMprlh4lY4MyM=; b=n9UuQOtVfJSPqNzV8zMTLubBunlXmc/4toaw4Nx3qP9d6KPsf040SL+ObclryeSaZ4 cN4CW5F3SmTYHqsH/ZpHyRhFGcWPcqRNDoztB6FJ7lxDH8+tb45h7/QT0unNGJar/8sL J8+PJ4oXN+qNMXTVgPdog8tutUSS3kHPyTKWwKdnLVWC8YzpQbcJA5QEEMRApmtkPmlb JvOw3I1wj+YHs2Y2wArc3N46kEeszGLw1ngkGXKGEewL0AX1BnGNdTGslXhZ8bIhyPFf Bnz4BQDU+IGF0lbtNstUfT/ptGXFyCO8vNEm7LwHoCwH2ewdtyd+omc6/kIl1oBcuocl x9bw== Received: by 10.68.203.228 with SMTP id kt4mr856434pbc.87.1350614743340; Thu, 18 Oct 2012 19:45:43 -0700 (PDT) Received: from [10.201.82.236] ([202.45.12.141]) by mx.google.com with ESMTPS id pj10sm439971pbb.46.2012.10.18.19.45.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 19:45:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Fri, 19 Oct 2012 11:45:30 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> To: Zhen Cao X-Mailer: Apple Mail (2.1283) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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 Oct 2012 02:45:44 -0000 Hi Zhen, On 2012/10/19, at 11:16, Zhen Cao wrote: > My question is why local-mac couldn't solve your problem. As far as I > know, any local-mac mode AP needs to encapsulate EAP packet into > neither CAPWAP-DATA nor CTL >=20 > as far as i understand, the local-mac mode will encapsulate the CAPWAP = message into 802.3 header. > +-+wireless frames +-+ 802.3 frames +-+ > | |----------------| |--------------| | > | | | | | | > | |----------------| |--------------| | > | |wireless PHY/ | | CAPWAP | | > | | MAC sublayer | | | | > +-+ +-+ +-+ > STA WTP AC >=20 Thanks, same view on me. The local-mac isn't designed to encapsulate EAP = packet into CAPWAP-{CTL|DATA} but the split-mac is the mode which = CAPWAP-DATA deliver the EAP packet. > =20 > because AP send messages to AAA server as > EAP authenticator. >=20 > This way, when UE handover between different AP, the security session = cannot be switched to the new AP.=20 >=20 Well, I understand that what problem you want to solve is keep 802.11i = security session continuously in UE handover between different APs. If = so, I may suggest that you can clarify the comparison of solutions in = the document that local-mac + ERP, which a product of the IETF hokey wg, = vs. split-mac + EAP encapsulation into CAPWAP-CTL for example. cheers, --satoru= From zehn.cao@gmail.com Thu Oct 18 20:08:49 2012 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 09A661F0C59 for ; Thu, 18 Oct 2012 20:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOrTPST0DK+E for ; Thu, 18 Oct 2012 20:08:48 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5688A1F0C4C for ; Thu, 18 Oct 2012 20:08:48 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so24024iec.31 for ; Thu, 18 Oct 2012 20:08:48 -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=GEejQOlrWvISeqE+nTevj/fxEcftGshW6utXdDBODXQ=; b=rOQZPS9F5lF1AtcdPxPAPINB5xLzCHVg+NmhKvqKuKHBxHCI8GwA/p1Apfy0B6YuWC 938RkhdU7Gl90lBZpfBJ6EFS2cjzn9ismVv9CCLGYzjpw1tBiCu9a0Ocf9CpDIaw5tUv qLTxfPr7RL6MW6PEAgHXNafFAo3b2ksgtyRq3jBI1bJSfRkxR/IAJKD1Tlvy/YnUUlRO c6eJu+KXLm4m1eEOgrP+ttV/QacGDlapBJG1a3OhacORpd9sh0O6A0+ASb6RJq/1L9Uf dIyReoMpFrnzXEJrmqUdSpikN1p6dOYxsuerORH7RY37JMNFfZI/E6zQIPLiBJfTKVb4 2Lvw== MIME-Version: 1.0 Received: by 10.50.179.36 with SMTP id dd4mr7025595igc.64.1350616127936; Thu, 18 Oct 2012 20:08:47 -0700 (PDT) Received: by 10.64.64.102 with HTTP; Thu, 18 Oct 2012 20:08:47 -0700 (PDT) In-Reply-To: References: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> Date: Fri, 19 Oct 2012 11:08:47 +0800 Message-ID: From: Zhen Cao To: Satoru Matsushima Content-Type: multipart/alternative; boundary=f46d04479f8b88998904cc60d2c3 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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 Oct 2012 03:08:49 -0000 --f46d04479f8b88998904cc60d2c3 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 19, 2012 at 10:45 AM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hi Zhen, > > On 2012/10/19, at 11:16, Zhen Cao wrote: > > > My question is why local-mac couldn't solve your problem. As far as I > > know, any local-mac mode AP needs to encapsulate EAP packet into > > neither CAPWAP-DATA nor CTL > > > > as far as i understand, the local-mac mode will encapsulate the CAPWAP > message into 802.3 header. > > +-+wireless frames +-+ 802.3 frames +-+ > > | |----------------| |--------------| | > > | | | | | | > > | |----------------| |--------------| | > > | |wireless PHY/ | | CAPWAP | | > > | | MAC sublayer | | | | > > +-+ +-+ +-+ > > STA WTP AC > > > > Thanks, same view on me. The local-mac isn't designed to encapsulate EAP > packet into CAPWAP-{CTL|DATA} but the split-mac is the mode which > CAPWAP-DATA deliver the EAP packet. > Not actually. EAP is not exempted from the tunnel by RFC5415. > > > > > because AP send messages to AAA server as > > EAP authenticator. > > > > This way, when UE handover between different AP, the security session > cannot be switched to the new AP. > > > > Well, I understand that what problem you want to solve is keep 802.11i > security session continuously in UE handover between different APs. If so, > I may suggest that you can clarify the comparison of solutions in the > document that local-mac + ERP, which a product of the IETF hokey wg, vs. > split-mac + EAP encapsulation into CAPWAP-CTL for example. > Thanks for the suggestion. Before that I need to clarify another aspect: now that in the non-EAP authentication WLAN, we already have the AP not directly interfacing with AAA, for a smooth upgrade, we had better keep this arch. > > cheers, > --satoru --f46d04479f8b88998904cc60d2c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 19, 2012 at 10:45 AM, Satoru= Matsushima <satoru.matsushima@gmail.com> wrote:
Hi Zhen,

On 2012/10/19, at 11:16, Zhen Cao wrote:

> My question is why local-mac couldn't solve your problem. As far a= s I
> know, any local-mac mode AP needs to encapsulate EAP packet into
> neither CAPWAP-DATA nor CTL
>
> as far as i understand, the local-mac mode will encapsulate the CAPWAP= message into 802.3 header.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-+wireless frames +-+ 802.3 frames +-+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 | |----------------| |--------------| | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| | =A0= =A0 =A0 =A0 =A0 =A0 =A0| |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | |----------------| |--------------| | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 | |wireless PHY/ =A0 | | =A0 =A0 CAPWAP = =A0 | |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | | MAC sublayer =A0 | | =A0 =A0 =A0 =A0 = =A0 =A0 =A0| |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-+ =A0= =A0 =A0 =A0 =A0 =A0 =A0+-+
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 STA =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0WTP =A0= =A0 =A0 =A0 =A0 =A0 =A0 AC
>

Thanks, same view on me. The local-mac isn't designed to encapsul= ate EAP packet into CAPWAP-{CTL|DATA} but the split-mac is the mode which C= APWAP-DATA deliver the EAP packet.

Not actually. EAP is not exempted from the tunnel by RFC5415.=A0
= =A0

>
> because AP send messages to AAA server as
> EAP authenticator.
>
> This way, when UE handover between different AP, the security session = cannot be switched to the new AP.
>

Well, I understand that what problem you want to solve is keep 802.11= i security session continuously in UE handover between different APs. If so= , I may suggest that you can clarify the comparison of solutions in the doc= ument that local-mac + ERP, which a product of the IETF hokey wg, vs. split= -mac + EAP encapsulation into CAPWAP-CTL for example.

Thanks for the suggestion. Before that I n= eed to clarify another aspect: now that=A0in the non-EAP authentication WLA= N, we already have the AP not directly interfacing with AAA, for a smooth u= pgrade, we had better keep this arch.=A0
=A0

cheers,
--satoru

--f46d04479f8b88998904cc60d2c3-- From satoru.matsushima@gmail.com Thu Oct 18 21:00:09 2012 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 B39DA11E808A for ; Thu, 18 Oct 2012 21:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKqmbPAeS5tk for ; Thu, 18 Oct 2012 21:00:08 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D39151F0C44 for ; Thu, 18 Oct 2012 21:00:08 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so44235pad.31 for ; Thu, 18 Oct 2012 21:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jgJeu6UxgT4igZIRYDdnhiBjojxXpYHDBL6ABT77crg=; b=yyg/p+q6X7V1NrCJ/AykuC0PFdtfFMvXDxZyh8WL6QyCZo+4Ax0w5nDwYqocqaEIeN KyeU2LmnBtUIc//jpW0bzFE8hTIRwm/I4kCA4WQWJZsiY+VPKSa7VGn0oUh1wdF+vWYd AMf3grQBBBpWiBAjl7IARQ+un5ExlqGnvkMZ/2rSv8j0sgEQWTfxJNziiXm20onlJ6RM 4GOF6yICc42enyy/iVJo1AT+OvDvIm3f58jwmLNqROeTUq26PPmtyLkf2JDwVH/rn2Yj aeesiZMnGqgxkj2CUK6N243fKjhmERNIeTGXFvZSXRxA9zSiwvs9kjHt9uyCoNiWM4id yVRg== Received: by 10.68.226.167 with SMTP id rt7mr1411844pbc.94.1350619208697; Thu, 18 Oct 2012 21:00:08 -0700 (PDT) Received: from [10.201.82.236] ([202.45.12.141]) by mx.google.com with ESMTPS id ro5sm536982pbc.66.2012.10.18.21.00.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Oct 2012 21:00:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Fri, 19 Oct 2012 12:59:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> To: Zhen Cao X-Mailer: Apple Mail (2.1283) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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 Oct 2012 04:00:09 -0000 Hi Zhen, On 2012/10/19, at 12:08, Zhen Cao wrote: > > My question is why local-mac couldn't solve your problem. As far as = I > > know, any local-mac mode AP needs to encapsulate EAP packet into > > neither CAPWAP-DATA nor CTL > > > > as far as i understand, the local-mac mode will encapsulate the = CAPWAP message into 802.3 header. > > +-+wireless frames +-+ 802.3 frames +-+ > > | |----------------| |--------------| | > > | | | | | | > > | |----------------| |--------------| | > > | |wireless PHY/ | | CAPWAP | | > > | | MAC sublayer | | | | > > +-+ +-+ +-+ > > STA WTP AC > > >=20 > Thanks, same view on me. The local-mac isn't designed to encapsulate = EAP packet into CAPWAP-{CTL|DATA} but the split-mac is the mode which = CAPWAP-DATA deliver the EAP packet. >=20 > Not actually. EAP is not exempted from the tunnel by RFC5415.=20 I think that tunneling EAP packet through AP-AC link in the local-mac = mode is nothing worth. I think that it should be significant to share = that there is any implementation with that, or not. Can you include some = results of implementation survey in the document? > =20 >=20 > > > > because AP send messages to AAA server as > > EAP authenticator. > > > > This way, when UE handover between different AP, the security = session cannot be switched to the new AP. > > >=20 > Well, I understand that what problem you want to solve is keep 802.11i = security session continuously in UE handover between different APs. If = so, I may suggest that you can clarify the comparison of solutions in = the document that local-mac + ERP, which a product of the IETF hokey wg, = vs. split-mac + EAP encapsulation into CAPWAP-CTL for example. >=20 > Thanks for the suggestion. Before that I need to clarify another = aspect: now that in the non-EAP authentication WLAN, we already have the = AP not directly interfacing with AAA, for a smooth upgrade, we had = better keep this arch.=20 >=20 It seems slightly different discussion. EAP is a layer 2 authentication = protocol but non-EAP authentication, whatever web or WISPr, is layer 3 = based authentication. These are in orthogonal. --satoru From zehn.cao@gmail.com Fri Oct 19 01:42:43 2012 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 6268F21F85FE for ; Fri, 19 Oct 2012 01:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTQRp9fxvENC for ; Fri, 19 Oct 2012 01:42:42 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABCA221F85EA for ; Fri, 19 Oct 2012 01:42:42 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so360008iec.31 for ; Fri, 19 Oct 2012 01:42: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 :cc:content-type; bh=vCsPkJCsFsVIUexw1Ms6RubHT+L2LETdqzyQV3B9pWo=; b=CRWzNdMYazuI8iXD2GOiy2PbUukEOLp+GlCl2VLzaWyCD24blp8BJuuBN1USFnJhlZ NaZjmrAR1t0TnYhKNmdai1AmUB8r2q/FoMYhZVOkHh7nOEiDnFwt+bKHGcZ7XlxlicZ7 NDBOwokxkbVzp8yPBdtGfACm+4HJAOUgGnN6TinM2WHOtvpYmax549K4drtAWRp9Vinu NQYrIkuH4ixhtPLgbLshkbXALAnQUT5TOSzuShdxZygUvJxOy5SqxRMMD0dwBIxZhh/H LIf5fhetHG9x8suZdxJkthlgJXKWWfJJGVH29qyK9PPHLuwMghcs5gVeBgEgu5QSiCJK NETQ== MIME-Version: 1.0 Received: by 10.43.48.129 with SMTP id uw1mr407049icb.10.1350636162255; Fri, 19 Oct 2012 01:42:42 -0700 (PDT) Received: by 10.64.64.102 with HTTP; Fri, 19 Oct 2012 01:42:42 -0700 (PDT) In-Reply-To: References: <6668D878-3AB3-4746-A7C1-683538E583EC@gmail.com> Date: Fri, 19 Oct 2012 16:42:42 +0800 Message-ID: From: Zhen Cao To: Satoru Matsushima Content-Type: multipart/alternative; boundary=bcaec5299febac0d6b04cc657c53 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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 Oct 2012 08:42:43 -0000 --bcaec5299febac0d6b04cc657c53 Content-Type: text/plain; charset=ISO-8859-1 Hi Satoru, Thank you for the suggestion, and my comments inline. On Fri, Oct 19, 2012 at 11:59 AM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > > Thanks, same view on me. The local-mac isn't designed to encapsulate EAP > packet into CAPWAP-{CTL|DATA} but the split-mac is the mode which > CAPWAP-DATA deliver the EAP packet. > > > > Not actually. EAP is not exempted from the tunnel by RFC5415. > > I think that tunneling EAP packet through AP-AC link in the local-mac mode > is nothing worth. I think that it should be significant to share that there > is any implementation with that, or not. Can you include some results of > implementation survey in the document? Very good point and suggestion. We are glad to include such survey. Could you help conduct the survey? > > Thanks for the suggestion. Before that I need to clarify another aspect: > now that in the non-EAP authentication WLAN, we already have the AP not > directly interfacing with AAA, for a smooth upgrade, we had better keep > this arch. > > > > It seems slightly different discussion. EAP is a layer 2 authentication > protocol but non-EAP authentication, whatever web or WISPr, is layer 3 > based authentication. These are in orthogonal. > Anyway the problem we have is that the Thin-AP does not have the interface with AAA or not enabled at all. -cz > --satoru > > --bcaec5299febac0d6b04cc657c53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Satoru,

Thank you for the suggestion, and my comments= inline.

On Fri, Oct 19, 2012 at 11:59 AM= , Satoru Matsushima <satoru.matsushima@gmail.com> = wrote:
> Thanks, same view on = me. The local-mac isn't designed to encapsulate EAP packet into CAPWAP-= {CTL|DATA} but the split-mac is the mode which CAPWAP-DATA deliver the EAP = packet.
>
> Not actually. EAP is not exempted from the tunnel by RFC5415.

I think that tunneling EAP packet through AP-AC link in the local-mac= mode is nothing worth. I think that it should be significant to share that= there is any implementation with that, or not. Can you include some result= s of implementation survey in the document?

Very good point and suggestion. =A0We are glad to inclu= de such survey. =A0Could you help conduct the survey?=A0
=A0
> Thanks for the suggestion. Before that I need to cla= rify another aspect: now that in the non-EAP authentication WLAN, we alread= y have the AP not directly interfacing with AAA, for a smooth upgrade, we h= ad better keep this arch.
>

It seems slightly different discussion. EAP is a layer 2 authenticati= on protocol but non-EAP authentication, whatever web or WISPr, is layer 3 b= ased authentication. These are in orthogonal.

Anyway the problem we have is that the Thin-AP does not have the= interface with AAA or not enabled at all.=A0

-cz<= /div>
=A0
--satoru


--bcaec5299febac0d6b04cc657c53-- From j.schoenwaelder@jacobs-university.de Fri Oct 19 23:46:03 2012 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 9FC5C21F8610; Fri, 19 Oct 2012 23:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2SPYWKjX4Bl; Fri, 19 Oct 2012 23:46: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 ECE8C21F860F; Fri, 19 Oct 2012 23:46:02 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D016820C00; Sat, 20 Oct 2012 08:46:00 +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 BnmkQGc6bL01; Sat, 20 Oct 2012 08:46:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02F9220BFE; Sat, 20 Oct 2012 08:45:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 137092258B4F; Sat, 20 Oct 2012 08:45:59 +0200 (CEST) Date: Sat, 20 Oct 2012 08:45:59 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20121020064558.GA93702@elstar.local> Mail-Followup-To: Carsten Bormann , "Ersue, Mehmet (NSN - DE/Munich)" , coman@ietf.org, opsawg@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <3921D6F6-57AA-43BA-8B71-D8C7465B7F26@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3921D6F6-57AA-43BA-8B71-D8C7465B7F26@tzi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: coman@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt 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: Sat, 20 Oct 2012 06:46:03 -0000 On Sat, Oct 20, 2012 at 06:33:20AM +0200, Carsten Bormann wrote: > > The classes have been defined the way they are because they mirror a > step function in capabilities. > (They also haven been defined on approximate orders of magnitude > because you can't nail these steps down to a kilobyte.) > > What do you think is missing? > Hijacking the thread, I do actually think we should have some more classes. For coman, in the use cases also devices included that have the memory to run embedded linux. I think we would do well to cover devices such xports or even raspberrys. Yes, those boxes probably are not the target of lwig but they will exist in the internet of things and some of them will exhibit properties (like mostly sleeping) that coman I think needs to address. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From satoru.matsushima@gmail.com Sat Oct 20 02:40:59 2012 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 E059A21F8588 for ; Sat, 20 Oct 2012 02:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S88CCcyd9OFF for ; Sat, 20 Oct 2012 02:40:58 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A498321F8584 for ; Sat, 20 Oct 2012 02:40:58 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so657313wgb.13 for ; Sat, 20 Oct 2012 02:40:57 -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=t8zSnnLw7lulYkzpUKT/KqKtqxSe29LOIRoIgOVmFTM=; b=I7bno9eIMOIoHHlZZWZDElDS3AyEu7O/hYlNA7wwiMynwYukzlA/YCGv5s3LF4bp/9 Qjzu6WeBrxh6lpyCymBflUQu0hav4sPrdG3/yKDeA+DyVFW3hgZTwjP9wgdjeT7v1Ia/ 0ax4QfNFUN05YMebaiO1EGC57wTok/+Me1RIh0Ipxkm/UgJ2JWaWUJWYNpkIHXSqMrsB mkcCqK4Gm9pHnNX2+4hgkd5BzK5EOfMsYvrnmEcKk3Nf0GCkOahm7TyWXu54EBBpxnxJ 1+FUXd5YT7ENxmBRQh8YU8y5D1Z84MP7CsC1CpESKsgELTKrCIKweK0SYIE1bu+q4sln ww4A== MIME-Version: 1.0 Received: by 10.216.210.16 with SMTP id t16mr2176904weo.175.1350726057732; Sat, 20 Oct 2012 02:40:57 -0700 (PDT) Received: by 10.217.4.133 with HTTP; Sat, 20 Oct 2012 02:40:57 -0700 (PDT) In-Reply-To: <50812199.8ac1440a.1f93.ffffbe94SMTPIN_ADDED@mx.google.com> References: <50812199.8ac1440a.1f93.ffffbe94SMTPIN_ADDED@mx.google.com> Date: Sat, 20 Oct 2012 18:40:57 +0900 Message-ID: From: Satoru Matsushima To: zhangr@gsta.com Content-Type: text/plain; charset=ISO-8859-1 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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: Sat, 20 Oct 2012 09:41:00 -0000 Zhen, Rong, On Fri, Oct 19, 2012 at 6:47 PM, wrote: > > Hello Satoru, > > If you kind help to start the survey, we can support you as well. > I think I can help you anything what I can do. But if you want to achieve your goal, you need much more support from the community. I believe that the first step should be more clear problem statement. One of my idea as ToC of the PS doc is following: 1. Why CAPWAP 2. What is Split-MAC and Local-MAC in CAPWAP 3. A clarification of use case of both Split-MAC and Local-MAC 4. Problem statement 5. A survey of current implementation of CAPWAP 4.1. Supported mode and function 4.2. Interoperability 4.3. Scalability 6. Goal of CAPWAP improvement > By the way, network architecture of AP-AC-AAA has been proved good for wifi > handover performance, > I think that you may answer in the document for how much improved performance should be your target. cheers, --satoru From denghui02@gmail.com Sun Oct 21 06:47:03 2012 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 1DC5121F8979 for ; Sun, 21 Oct 2012 06:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcU3jQlFNnuh for ; Sun, 21 Oct 2012 06:47:02 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18C6821F8917 for ; Sun, 21 Oct 2012 06:47:02 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so1274865qcg.31 for ; Sun, 21 Oct 2012 06:47: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=fGQ6/0+m24adXXS/YkxbUy4oKTV0916m/VuCt17CwQQ=; b=fArVGdYu1OFF5+MhxfO7gr+vPgVSS7G9jTejCNh/sjRZ7Qk/NemiosgLwjg93PJPXP u5BNIQKPnwQeiecA5InV1Eo1HAH1CpUXXIH56J+UEI95m1t1ekEDXlQtcdjsN3qyWEf/ ov3Zkak8HDp9EPFl5Pxvnf+5zN7RoDGT7xjr8n0aW+erSo359mDjWv5euYDfpQWZDZXm q/r7Gth2UcphBUU9OY4Je9yaBp577atDSV9Cf3YeEireObSElWhm1isiPalgf+PWJkL/ /Fhv+ONq9kGWxBBRV/Xo2dmsQCqW3GwnISKJfgKsmSfttUEAkSRfwlKZZd0ifr9pZRGR Rp6Q== MIME-Version: 1.0 Received: by 10.224.180.205 with SMTP id bv13mr1133208qab.7.1350827221566; Sun, 21 Oct 2012 06:47:01 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Sun, 21 Oct 2012 06:47:01 -0700 (PDT) In-Reply-To: References: <50812199.8ac1440a.1f93.ffffbe94SMTPIN_ADDED@mx.google.com> Date: Sun, 21 Oct 2012 21:47:01 +0800 Message-ID: From: Hui Deng To: Satoru Matsushima Content-Type: multipart/alternative; boundary=20cf30363f8db1c5ad04cc91f878 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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 Oct 2012 13:47:03 -0000 --20cf30363f8db1c5ad04cc91f878 Content-Type: text/plain; charset=ISO-8859-1 Hi Satoru, Thanks a lot for your review and proposal. For the difference of split mac and Local Mac, it's all of matter of either 802.11 or 802.3 over CAPWAP Ctrl/Data Tunnel. For Local Mac, all functions will be based on AC, because 802.11 will be terminated at AC other than AP. This is the reason in our current PS draft to only define Split MAC function scope. Most of above has been stated by previous CAPWAP RFCs. For us, we have both of them deployed, it depends on the operators's strategy. If there is a problem about how Local MAC has Interop issue, this PS draft would be happy to include them, the draft is still open. I am think that AP pass all 802.11 to ACs, it may not have an issue, because 802.11 is a standard. Other problems described in current PS draft are not tighted with either Split MAC or Local MAC. thanks a lot for your review and discussion. Best regards, -Hui 2012/10/20 Satoru Matsushima > Zhen, Rong, > > On Fri, Oct 19, 2012 at 6:47 PM, wrote: > > > > Hello Satoru, > > > > If you kind help to start the survey, we can support you as well. > > > > I think I can help you anything what I can do. But if you want to > achieve your goal, you need much more support from the community. I > believe that the first step should be more clear problem statement. > One of my idea as ToC of the PS doc is following: > > 1. Why CAPWAP > 2. What is Split-MAC and Local-MAC in CAPWAP > 3. A clarification of use case of both Split-MAC and Local-MAC > 4. Problem statement > 5. A survey of current implementation of CAPWAP > 4.1. Supported mode and function > 4.2. Interoperability > 4.3. Scalability > 6. Goal of CAPWAP improvement > > > > By the way, network architecture of AP-AC-AAA has been proved good for > wifi > > handover performance, > > > > I think that you may answer in the document for how much improved > performance should be your target. > > cheers, > --satoru > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --20cf30363f8db1c5ad04cc91f878 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Satoru,
=A0
Thanks a lot for your review and pr= oposal.
=A0
For the difference of split mac and Local M= ac, it's all of matter of either 802.11 or=A0802.3=A0over CAPWAP Ctrl/D= ata Tunnel.
=A0
For Local Mac, all functions will be based on AC, becaus= e 802.11 will be terminated at AC other than AP. This is the reason
in our current PS draft to only define Split MAC function scope.

Most of above has been stated by previous CAPWAP RFCs.
=A0
<= div>For us, we have both of them deployed, it depends on the operators'= s strategy.
=A0
If there is a problem about how Local M= AC has Interop issue,=A0 this PS draft would be happy to include them, the = draft is still open.
I am think that=A0AP pass all 802.11 to ACs, it may not have an issue,= =A0 because 802.11 is a standard.
=A0
Other problems de= scribed in current PS draft are not tighted with either Split MAC or Local = MAC.
=A0
thanks a lot for your review and discussion.
B= est regards,
=A0
-Hui
2= 012/10/20 Satoru Matsushima <satoru.matsushima@gmail.com>=
Zhen, Rong,

On Fri, Oct 19, 2012 at 6:47 PM, =A0<= zhangr@gsta.com> wrote:
>
> Hello Satoru,
>
> If you kind help to start the survey, we can support you as well.
>

I think I can help you anything what I can do. But if you want to
achieve your goal, you need much more support from the community. I
believe that the first step should be more clear problem statement.
One of my idea as ToC of the PS doc is following:

1. Why CAPWAP
2. What is Split-MAC and Local-MAC in CAPWAP
3. A clarification of use case of both Split-MAC and Local-MAC
4. Problem statement
5. A survey of current implementation of CAPWAP
=A0 =A0 4.1. Supported mode and function
=A0 =A0 4.2. Interoperability
=A0 =A0 4.3. Scalability
6. Goal of CAPWAP improvement


> By the way, network architecture of AP-AC-AAA has been proved good for= wifi
> handover performance,
>

I think that you may answer in the document for how much improved
performance should be your target.

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

--20cf30363f8db1c5ad04cc91f878-- From satoru.matsushima@gmail.com Sun Oct 21 18:56:56 2012 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 51F2C21F8A96 for ; Sun, 21 Oct 2012 18:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58X-W4Mmnjwn for ; Sun, 21 Oct 2012 18:56:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD45321F8A12 for ; Sun, 21 Oct 2012 18:56:55 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1620896pbb.31 for ; Sun, 21 Oct 2012 18:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=en7/g3tgPOt+RkDvQK/p6okZ10XGFjQWjGt3hLsWo70=; b=xFlQh2ckpex3dHWcqqCnHVRv9RGXjDXqwTxgBoNa42rXCJFplwH4dWvZSRo2w7oRWd iO9kgdGDG6Oo+LqN90lQ4k5S7j/sLCfWhAX47rOjA1De8T+lTLKjDf6zk6BVAF2xm0io oYgS313p974H16p0F6lHVre9sigSKLdc/EtKy+Fl67tF9VuryAlULt8YQgcqp3nyn3Ul 60LZ4B9BHUYyjNeW3oTtFFQ5n6CzGyloPls6bzSLMIBt1u21AEQV4o0S3x4319w1iXpz Ucnl738FnAtub5M0K0CI9NvTkyhlNIQcCDhTD0wvZieviTbVmG9ixlaEw9Qz/PuuTTbK rA6g== Received: by 10.68.233.230 with SMTP id tz6mr25826705pbc.36.1350871015530; Sun, 21 Oct 2012 18:56:55 -0700 (PDT) Received: from [10.201.82.236] ([202.45.12.141]) by mx.google.com with ESMTPS id po4sm5090257pbb.13.2012.10.21.18.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 18:56:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 22 Oct 2012 10:56:49 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50812199.8ac1440a.1f93.ffffbe94SMTPIN_ADDED@mx.google.com> To: Hui Deng X-Mailer: Apple Mail (2.1283) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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 Oct 2012 01:56:56 -0000 Hui, On 2012/10/21, at 22:47, Hui Deng wrote: > For the difference of split mac and Local Mac, it's all of matter of = either 802.11 or 802.3 over CAPWAP Ctrl/Data Tunnel. > =20 > For Local Mac, all functions will be based on AC, because 802.11 will = be terminated at AC other than AP. This is the reason in our current PS = draft to only define Split MAC function scope. >=20 > Most of above has been stated by previous CAPWAP RFCs. I think you meant that the remote-mac terminated _all_ 802.11 frame at = AC other than AP. Yes, RFC4118, which you might cite in a further draft, = has described well CAPWAP models like as follow. >=20 > +--------------+--- +---------------+--- = +--------------+--- > | CAPWAP | | CAPWAP | | CAPWAP | > | functions |AC | functions |AC | functions | > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D = |---------------| |--------------| > | | | non RT MAC | | = |AC > | 802.11 MAC | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D|=3D=3D=3D | 802.11 MAC | > | |WTP | Realtime MAC | | | > |--------------| |---------------|WTP = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D > | 802.11 PHY | | 802.11 PHY | | 802.11 PHY = |WTP > +--------------+--- +---------------+--- = +--------------+--- >=20 > (a) "Local MAC" (b) "Split MAC" (c) "Remote MAC" >=20 > =20 > For us, we have both of them deployed, it depends on the operators's = strategy. > =20 I do understand that. We also operate wifi service too. > If there is a problem about how Local MAC has Interop issue, this PS = draft would be happy to include them, the draft is still open. > I am think that AP pass all 802.11 to ACs, it may not have an issue, = because 802.11 is a standard. > =20 > Other problems described in current PS draft are not tighted with = either Split MAC or Local MAC. > =20 So you mean that local-mac and remote-mac doesn't have interoperability = issues in your experience but split-mac does have that. I think it would = be nice if the draft describe well why the IETF need to revisit CAPWAP = for split-mac interoperability as you requested even other two could be = interoperable. I guess that those would be to make much better AP = hand-over experience, scalability and rich control functions which the = current CAPWAP doesn't have. > thanks a lot for your review and discussion. > Best regards, You are welcome, hope that helps you. --satoru From denghui02@gmail.com Sun Oct 21 22:58:48 2012 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 8CE9321F8B85 for ; Sun, 21 Oct 2012 22:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbJFrY2-upNp for ; Sun, 21 Oct 2012 22:58:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E97721F8B83 for ; Sun, 21 Oct 2012 22:58:47 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so1537189qcg.31 for ; Sun, 21 Oct 2012 22:58:47 -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=EP1Fh5bP9TiDp49Ore8fRNl/qm1c/EHhIGm7ibmfeDw=; b=BkSXCpFLfa6xffoSjQqOAGvbJWxpizWMIjLRq1YxxbkZKGsOX7TtMLRAPPlZeJawbT 49513kqg9fPG0yy6wbYHA9AHpvKueTNkkKWse84rD63zwknYOZCgPYGcdtgvh4wsAmBU Px2rYyPn88uquyF/tqXgRyx5AtqLXkyDmEnKDfbUWMfl4OuLiMy1a4synMyccDADKt5Z eUce4kqwv6C2Qe8mqQCqXN50wa2f2jEesBAgko3IIhDpnna4iIiY0UrQaTmPzYoILwFV DYyUu4HaSUqk8uFEHnEOYOyKevquvdTE6D/WyhrFoLY7zJKdvo33v5867Rldx2Znt7CV Q5jw== MIME-Version: 1.0 Received: by 10.224.9.138 with SMTP id l10mr3715699qal.58.1350885527020; Sun, 21 Oct 2012 22:58:47 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Sun, 21 Oct 2012 22:58:46 -0700 (PDT) In-Reply-To: References: <50812199.8ac1440a.1f93.ffffbe94SMTPIN_ADDED@mx.google.com> Date: Mon, 22 Oct 2012 13:58:46 +0800 Message-ID: From: Hui Deng To: Satoru Matsushima Content-Type: multipart/alternative; boundary=bcaec517ab7af8658204cc9f8b3f Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Request for comments on CAPWAP related draft 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 Oct 2012 05:58:48 -0000 --bcaec517ab7af8658204cc9f8b3f Content-Type: text/plain; charset=ISO-8859-1 Satoru, I understand better now, excuse me, that I made some confusion about local mac and split mac, exactly, we have done some work before, below are analysze: there are 3 of them defined: 1) functions Distribution Service Integration Service Beacon Generation Probe Response Generation Power Mgmt/Packet Buffering Fragmentation/Defragmentation Assoc/Disassoc/Reassoc 2)QoS Classifying Scheduling Queuing 3) RSN (WPA2) IEEE 802.1X/EAP RSNA Key Management IEEE 802.11 Encryption/Decryption The problem is both split and local mac don't have precise definition where to do this work, some of them are done in AP, others are done in AC. like: Distribution service, Fragmentation, Scheduling, Encryption. For this reason it is not good for interoperation between AP and AC. we had survey already, depends on survey company about 48 percentage of them support Local MAC, others are supporting Split MAC, what we want to propose is to define a hybrid -mac model which has precise requirement about all of the functions, if you are interested in this, we welcome to on board. thanks a lot for the discussion Best regards, -Hui 2012/10/22 Satoru Matsushima > Hui, > > On 2012/10/21, at 22:47, Hui Deng wrote: > > > For the difference of split mac and Local Mac, it's all of matter of > either 802.11 or 802.3 over CAPWAP Ctrl/Data Tunnel. > > > > For Local Mac, all functions will be based on AC, because 802.11 will be > terminated at AC other than AP. This is the reason in our current PS draft > to only define Split MAC function scope. > > > > Most of above has been stated by previous CAPWAP RFCs. > > I think you meant that the remote-mac terminated _all_ 802.11 frame at AC > other than AP. Yes, RFC4118, which you might cite in a further draft, has > described well CAPWAP models like as follow. > > > > > +--------------+--- +---------------+--- +--------------+--- > > | CAPWAP | | CAPWAP | | CAPWAP | > > | functions |AC | functions |AC | functions | > > |==============|=== |---------------| |--------------| > > | | | non RT MAC | | |AC > > | 802.11 MAC | |===============|=== | 802.11 MAC | > > | |WTP | Realtime MAC | | | > > |--------------| |---------------|WTP |==============|=== > > | 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP > > +--------------+--- +---------------+--- +--------------+--- > > > > (a) "Local MAC" (b) "Split MAC" (c) "Remote MAC" > > > > > > > > > For us, we have both of them deployed, it depends on the operators's > strategy. > > > > I do understand that. We also operate wifi service too. > > > > If there is a problem about how Local MAC has Interop issue, this PS > draft would be happy to include them, the draft is still open. > > I am think that AP pass all 802.11 to ACs, it may not have an issue, > because 802.11 is a standard. > > > > Other problems described in current PS draft are not tighted with either > Split MAC or Local MAC. > > > > So you mean that local-mac and remote-mac doesn't have interoperability > issues in your experience but split-mac does have that. I think it would be > nice if the draft describe well why the IETF need to revisit CAPWAP for > split-mac interoperability as you requested even other two could be > interoperable. I guess that those would be to make much better AP hand-over > experience, scalability and rich control functions which the current CAPWAP > doesn't have. > > > > thanks a lot for your review and discussion. > > Best regards, > > You are welcome, hope that helps you. > --satoru > > --bcaec517ab7af8658204cc9f8b3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Satoru,
=A0
I understand better now, excuse=A0me, = that I made some confusion about local mac and split mac,
exactly= , we have done some work before, below are analysze:
=A0
there are 3 of them defined:
1) functions

Distribution Service

Integration Service

Beacon Generation

Probe Response Generation

Power Mgmt/Packet Buffering

Fragmentation/Defragmentation

Assoc/Disassoc/Reassoc

=A0
2)QoS

Classifying

Scheduling

Queuing

=A0

3) RSN (WPA2)

=A0

IEEE 802.1X/EAP

RSNA Key Management

IEEE 802.11 Encryption/Decryption

The problem is both split and local mac don't have precise definition w= here to do this work, some of them are done in AP, others are done in AC. l= ike: Distribution service, Fragmentation, Scheduling, Encryption. For this reason it is not good for interoperation between AP and AC= .

=A0

=A0

what we want to propose is to def= ine a hybrid -mac model which has precise requirement about all of the func= tions, if you are interested in this, we welcome to on board.

=A0
thanks a lot for the discussion
Best regards,
=A0
=
-Hui

2012/10/22 Satoru Matsush= ima <satoru.matsushima@gmail.com>
Hui,

On 2012/10/21, at 22:47, Hui Deng wrote:

> For the difference of split mac and Local Mac, it's all of matter = of either 802.11 or 802.3 over CAPWAP Ctrl/Data Tunnel.
>
> For Local Mac, all functions will be based on AC, because 802.11 will = be terminated at AC other than AP. This is the reason in our current PS dra= ft to only define Split MAC function scope.
>
> Most of above has been stated by previous CAPWAP RFCs.

I think you meant that the remote-mac terminated _all_ 802.11 frame a= t AC other than AP. Yes, RFC4118, which you might cite in a further draft, = has described well CAPWAP models like as follow.

>
> =A0 =A0 =A0 +--------------+--- =A0 =A0+---------------+--- =A0 =A0+--= ------------+---
> =A0 =A0 =A0 | =A0CAPWAP =A0 =A0 =A0| =A0 =A0 =A0 | =A0CAPWAP =A0 =A0 = =A0 | =A0 =A0 =A0 | =A0CAPWAP =A0 =A0 =A0|
> =A0 =A0 =A0 | =A0functions =A0 |AC =A0 =A0 | =A0functions =A0 =A0|AC = =A0 =A0 | =A0functions =A0 |
> =A0 =A0 =A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D =A0 = =A0|---------------| =A0 =A0 =A0 |--------------|
> =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 | =A0non RT MAC= =A0 | =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0|AC
> =A0 =A0 =A0 | =A0802.11 MAC =A0| =A0 =A0 =A0 |=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D =A0 =A0| =A0802.11 MAC =A0|
> =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0|WTP =A0 =A0| Realtime MAC = =A0| =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 =A0 |--------------| =A0 =A0 =A0 |---------------|WTP =A0 =A0|= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D
> =A0 =A0 =A0 | =A0802.11 PHY =A0| =A0 =A0 =A0 | =A0802.11 PHY =A0 | =A0= =A0 =A0 | =A0802.11 PHY =A0|WTP
> =A0 =A0 =A0 +--------------+--- =A0 =A0+---------------+--- =A0 =A0+--= ------------+---
>
> =A0 =A0 =A0 =A0(a) "Local MAC" =A0 =A0 =A0 =A0 (b) "Spl= it MAC" =A0 =A0 =A0 =A0(c) "Remote MAC"
>



>
> For us, we have both of them deployed, it depends on the operators'= ;s strategy.
>

I do understand that. We also operate wifi service too.


> If there is a problem about how Local MAC has Interop issue, =A0this P= S draft would be happy to include them, the draft is still open.
> I am think that AP pass all 802.11 to ACs, it may not have an issue, = =A0because 802.11 is a standard.
>
> Other problems described in current PS draft are not tighted with eith= er Split MAC or Local MAC.
>

So you mean that local-mac and remote-mac doesn't have interopera= bility issues in your experience but split-mac does have that. I think it w= ould be nice if the draft describe well why the IETF need to revisit CAPWAP= for split-mac interoperability as you requested even other two could be in= teroperable. I guess that those would be to make much better AP hand-over e= xperience, scalability and rich control functions which the current CAPWAP = doesn't have.


> thanks a lot for your review and discussion.
> Best regards,

You are welcome, hope that helps you.
--satoru


--bcaec517ab7af8658204cc9f8b3f-- From mehmet.ersue@nsn.com Mon Oct 22 03:55:39 2012 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 B51CA21F8A10; Mon, 22 Oct 2012 03:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4hMIcevHCic; Mon, 22 Oct 2012 03:55:34 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 79EE121F8A2F; Mon, 22 Oct 2012 03:55:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9MAtRhs021835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Oct 2012 12:55:27 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9MAtP9K032180; Mon, 22 Oct 2012 12:55:25 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 12:55:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDB043.BD20BFE6" Date: Mon, 22 Oct 2012 12:55:23 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt Thread-Index: Ac2uU9pfo1K6uzZVTMS7jQJxzNvPGAB3OHBg References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ulrich Herberg" , "Carsten Bormann" X-OriginalArrivalTime: 22 Oct 2012 10:55:25.0195 (UTC) FILETIME=[BD7C4DB0:01CDB043] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 31107 X-purgate-ID: 151667::1350903327-00006DFC-B9AE0A9A/0-0/0-0 Cc: coman@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.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, 22 Oct 2012 10:55:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB043.BD20BFE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ulrich, =20 see my comments below. =20 Cheers,=20 Mehmet=20 =20 From: ext Ulrich Herberg [mailto:ulrich@herberg.name]=20 Sent: Saturday, October 20, 2012 1:46 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: coman@ietf.org; opsawg@ietf.org Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt =20 Hi Mehmet, =20 thank you for updating the draft. There is a huge amount of great work in it, and I think this will provide a great basis for further discussions. Indeed, splitting up the document would be required at some point. =20 Some high-level comments: - Section 1.2 (Terminology): The definition of MANET and Intermediate entity (in COAP) come a bit surprising, since there has been no discussion before. Also, it seems inconsistent to define MANET, but not all the other use cases, such as AMI. =20 [ME]: The terminology section is incomplete and should be extended e.g. with AMI. =20 - Section 1.3 (Constrained Device Classes): I know that this definition is taken from Lwig, but I doubt that it is of much use. The absolute values will change. While now there are still many C0 devices out, in five years, they will not exist (or rather, the number 10KB would need to be replaced by a larger number). I think I would prefer a classification based on the capabilities (e.g. can support full IP stack, or not) =20 [ME]: The definition was actually first introduced by Carsten in the Smart Object workshop before IETF 80 in Prague. This is an important point. See my other mail. =20 - Section 1.4 (constrained networks): I don't think this is a very consistent classification of networks. First, CN0 seems to be the least constrained network, whereas C0 devices are the most constrained. I would suggest the remain the same ordering (0 the most constrained up to a positive number). =20 [ME]: The "0" in CN0 and C0 don't relate to each other. The constrainedness of a network is mostly dependent on the wireless technology used. I found it more useful to differentiate the type of the network, where the wireless technology can be manifold. =20 More importantly, there is a mixture with constrained devices in this definition. Since we talk about the network only, we should only talk about topology, lossy links, multi-hop, mobility etc. but not constrained devices.=20 =20 [ME]: I agree, we should talk here on devices only. =20 I don't understand why MANETs are not supported. Several of the use cases, such as the military use case, community networks and AMI are multi-hop networks with dynamic topology and lossy links. That is what I call a MANET.=20 =20 [ME]: The agreement in our last f2f meeting was that we want to include the MANET use case to highlight what it is but exclude from the requirements discussion. The reason is that MANETs can be based on very distinct scenarios and have specifics which are unique compared to other networks. The essential point is that MANETs are infrastructureless (i.e. without any hierarchy), which seems to be not the case in other network types the draft describes and makes network management essentially different. =20 Even the definition of CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are nothing else than MANETs (only difference is that routers are usually non-mobile; nevertheless, the topology is still dynamic because of fluctuating links.).=20 =20 [ME]: There might be similarities between a MANET and a Mesh network, however they are not the same thing. I have to admit we don't conceive sufficiently the special MANET use cases for frequent movement of routing devices without infrastructure. If we agree that a Mesh network covers the essential part of a MANET then I would suggest to focus on a Mesh network instead of trying to cover everything. =20 Is the intention to focus on non-mobile devices? =20 [ME]: There is no intention to exclude non-mobile devices. The draft currently assumes that, from the "network management" pov., both mobile and non-mobile devices have similar characteristics (I think we should describe this somewhere). The draft further assumes that the managing entity is not moving. =20 I might be wrong in this. Please describe which mobility aspects you think should be covered from "network management" pov. Managing the IP mobility itself, e.g. the IP address etc., is not network management per se. =20 Constrained networks are more difficult to define, as there are several aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I think that we need more discussion (but maybe after a BOF has been initiated?) =20 [ME]: We can start such a discussion already today. However, I assume it is mostly following the capabilities and limitations of the wireless technology. What would be your proposal for a classification of constrained networks? =20 - Section 1.5: (Network Topology Options): I think there is a mix between the topology (i.e., the graph that represents routers and communication links), traffic flows (which devices communicate with which other devices), and application layer (proxies and NMS). - Section 1.6: I like that. =20 - Section 1.7: There is mixture of constrained networks (first bullet); I thought that constrained devices only means that they have little CPU power and memory. Can't that device still use cable connectivity (i.e. unconstrained network)? Or is it necessarily linked? I am unclear about the purpose of this whole section. What does it serve for? =20 [ME]: Section 1.7 in general tries to list and discuss the issues a constrained device might have and how these issues influence the management of such a device. As described in section 1.4 and 2. we include non-constrained networks with constrained devices. =20 - Section 2: I think that the problem statement is not quite clear yet. It is hard to identify what the problems are; there are so many useful requirements in section 4, so maybe it could be better matched to these requirements. It would be nice to read section 4, and then say "ah, requirement x indeed logically follows from the problem y that has been described in section 2". =20 [ME]: I agree the problem statement in section 2 (which I didn't have time to update yet) could benefit from a revision aligning it with the new sections 1.7 and section 4. =20 - Section 3: I like the diverse use cases. That can be very useful to identify different requirements and problems. =20 - Section 4: I very much appreciate the enormous effort for gathering the requirements. There will be detailed discussions about them (hopefully), but this is a very good list to start from.=20 We have to define if the security related requirements also fit in this discussion, or better some place else (SOLACE?).=20 =20 [ME]: We see authentication and access control (to the extend it matters) as part of network management. This is probably the part where Coman and Solace can profit from and complement each other. =20 Again, I appreciate the effort of the authors, and hope that we can continue the discussions in Atlanta. I apologize that I only provided this high-level review, but the last weeks were very busy for me. If you need help authoring the documents once they are split up, I could help out. =20 Is there a meeting already planned?=20 =20 [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it once the room is known. Stay tuned. =20 Best regards Ulrich=20 =20 On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: Hi All, we submitted an update for the constrained-mgmt draft on the "Management of Networks with Constrained Devices: Use Cases and Requirements". The draft hopefully addresses most of the issues we discussed in the last meeting. I think it is already time to split the draft into three; e.g. problem statement, use cases and requirements. But this can be done after getting your feedback before and during IETF 85. I would highly appreciate your comments and any kind of discussion on the draft content especially on the requirements section. Thank you. Cheers, Mehmet -----Original Message----- From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 15, 2012 9:59 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: dromasca@avaya.com; j.schoenwaelder@jacobs-university.de Subject: New Version Notification for draft-ersue-constrained-mgmt-02.txt A new version of I-D, draft-ersue-constrained-mgmt-02.txt has been successfully submitted by Mehmet Ersue and posted to the IETF repository. Filename: draft-ersue-constrained-mgmt Revision: 02 Title: Management of Networks with Constrained Devices: Use Cases and Requirements Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 78 URL: http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt Status: http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt Htmlized: http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrained-mgmt-02 Abstract: This document raises the questions on and discusses the use cases and requirements for the management of networks with constrained devices. The IETF Secretariat _______________________________________________ coman mailing list coman@ietf.org https://www.ietf.org/mailman/listinfo/coman =20 ------_=_NextPart_001_01CDB043.BD20BFE6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Ulrich,

=  

= see my comments below.

=  

= Cheers,=
= Mehmet=

=  

From:= = ext Ulrich Herberg [mailto:ulrich@herberg.name] =
Sent: Saturday, October 20, 2012 1:46 AM
To: Ersue, = Mehmet (NSN - DE/Munich)
Cc: coman@ietf.org; opsawg@ietf.org
Subject: = Re: [coman] FW: New Version Notification for = draft-ersue-constrained-mgmt-02.txt

 

Hi = Mehmet,

 

thank you for updating the draft. There is a huge = amount of great work in it, and I think this will provide a great basis = for further discussions. Indeed, splitting up the document would be = required at some point.

 

Some high-level comments:

  - Section 1.2 (Terminology): The definition of = MANET and Intermediate entity (in COAP) come a bit surprising, since = there has been no discussion before. Also, it seems inconsistent to = define MANET, but not all the other use cases, such as = AMI.

 

= [ME]: The terminology section is incomplete and should be extended e.g. = with AMI.

=  

  - = Section 1.3 (Constrained Device Classes): I know that this definition is = taken from Lwig, but I doubt that it is of much use. The absolute values = will change. While now there are still many C0 devices out, in five = years, they will not exist (or rather, the number 10KB would need to be = replaced by a larger number). I think I would prefer a classification = based on the capabilities (e.g. can support full IP stack, or = not)

 

= [ME]: The definition was actually first introduced by Carsten in the = Smart Object workshop before IETF 80 in Prague. This is an important = point. See my other mail.

=  

  - = Section 1.4 (constrained networks): I don't think this is a very = consistent classification of networks. First, CN0 seems to be the least = constrained network, whereas C0 devices are the most constrained. I = would suggest the remain the same ordering (0 the most constrained up to = a positive number).

=  

= [ME]: The “0” in CN0 and C0 don’t relate to each = other. The constrainedness of a network is mostly dependent on the = wireless technology used. I found it more useful to differentiate the = type of the network, where the wireless technology can be = manifold.

=  

More = importantly, there is a mixture with constrained devices in this = definition. Since we talk about the network only, we should only talk = about topology, lossy links, multi-hop, mobility etc. but not = constrained devices. 

=  

= [ME]: I agree, we should talk here on devices = only.

=  

I don't = understand why MANETs are not supported. Several of the use cases, such = as the military use case, community networks and AMI are multi-hop = networks with dynamic topology and lossy links. That is what I call a = MANET.

=  

= [ME]: The agreement in our last f2f meeting was that we want to include = the MANET use case to highlight what it is but exclude from the = requirements discussion. The reason is that MANETs can be based on very = distinct scenarios and have specifics which are unique compared to other = networks. The essential point is that MANETs are infrastructureless = (i.e. without any hierarchy), which seems to be not the case in other = network types the draft describes and makes network management = essentially different.

=  

Even the definition of = CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are = nothing else than MANETs (only difference is that routers are usually = non-mobile; nevertheless, the topology is still dynamic because of = fluctuating links.).

=  

= [ME]: There might be similarities between a MANET and a Mesh network, = however they are not the same thing. I have to admit we don’t = conceive sufficiently the special MANET use cases for frequent movement = of routing devices without infrastructure. If we agree that a Mesh = network covers the essential part of a MANET then I would suggest to = focus on a Mesh network instead of trying to cover = everything.

=  

Is the intention to = focus on non-mobile devices?

=  

= [ME]: There is no intention to exclude non-mobile devices. The draft = currently assumes that, from the “network management” pov., = both mobile and non-mobile devices have similar characteristics (I think = we should describe this somewhere). The draft further assumes that the = managing entity is not moving.

=  

= I might be wrong in this. Please describe which mobility aspects you = think should be covered from “network management” pov. = Managing the IP mobility itself, e.g. the IP address etc., is not = network management per se.

=  

Constrained = networks are more difficult to define, as there are several aspects: = bandwidth, loss rates of the channel, MTU, topology, etc. I think that = we need more discussion (but maybe after a BOF has been = initiated?)

=  

= [ME]: We can start such a discussion already today. However, I assume it = is mostly following the capabilities and limitations of the wireless = technology. What would be your proposal for a classification of = constrained networks?

 

- = Section 1.5: (Network Topology Options): I think there is a mix between = the topology (i.e., the graph that represents routers and communication = links), traffic flows (which devices communicate with which other = devices), and application layer (proxies and = NMS).

- Section 1.6: I = like that.

 

- = Section 1.7: There is mixture of constrained networks (first bullet); I = thought that constrained devices only means that they have little CPU = power and memory. Can't that device still use cable connectivity (i.e. = unconstrained network)? Or is it necessarily = linked?

I am unclear about = the purpose of this whole section. What does it serve = for?

 

= [ME]: Section 1.7 in general tries to list and discuss the issues a = constrained device might have and how these issues influence the = management of such a device. As described in section 1.4 and 2. we = include non-constrained networks with constrained = devices.

=  

- Section 2: = I think that the problem statement is not quite clear yet. It is hard to = identify what the problems are; there are so many useful requirements in = section 4, so maybe it could be better matched to these requirements. It = would be nice to read section 4, and then say "ah, requirement x = indeed logically follows from the problem y that has been described in = section 2".

=  

= [ME]: I agree the problem statement in section 2 (which I didn’t = have time to update yet) could benefit from a revision aligning it with = the new sections 1.7 and section 4.

 

- = Section 3: I like the diverse use cases. That can be very useful to = identify different requirements and = problems.

 

- = Section 4: I very much appreciate the enormous effort for gathering the = requirements. There will be detailed discussions about them (hopefully), = but this is a very good list to start = from. 

We have to = define if the security related requirements also fit in this discussion, = or better some place else (SOLACE?). 

=  

= [ME]: We see authentication and access control (to the extend it = matters) as part of network management. This is probably the part where = Coman and Solace can profit from and complement each = other.

 

Again, I appreciate the effort of the authors, and = hope that we can continue the discussions in Atlanta. I apologize that I = only provided this high-level review, but the last weeks were very busy = for me. If you need help authoring the documents once they are split up, = I could help out.

 

Is there a meeting already = planned? 

 

= [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it = once the room is known. Stay tuned.

=  

Best = regards

Ulrich 

 

On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - = DE/Munich) <mehmet.ersue@nsn.com> wrote:

Hi All,

we submitted an update for the = constrained-mgmt draft on the "Management
of Networks with = Constrained Devices: Use Cases and Requirements". The
draft = hopefully addresses most of the issues we discussed in the = last
meeting.

I think it is already time to split the draft = into three; e.g. problem
statement, use cases and requirements. But = this can be done after
getting your feedback before and during IETF = 85.

I would highly appreciate your comments and any kind of = discussion on
the draft content especially on the requirements = section. Thank you.

Cheers,
Mehmet


-----Original = Message-----
From: ext internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - = DE/Munich)
Cc: dromasca@avaya.com; j.schoenwaelder@jaco= bs-university.de
Subject: New Version Notification = for
draft-ersue-constrained-mgmt-02.txt


A new version of = I-D, draft-ersue-constrained-mgmt-02.txt
has been successfully = submitted by Mehmet Ersue and posted to the
IETF = repository.

Filename:       =  draft-ersue-constrained-mgmt
Revision:       =  02
Title:           Management of = Networks with Constrained Devices: Use
Cases and = Requirements
Creation date:   2012-10-15
WG ID:     =       Individual Submission
Number of pages: = 78
URL:
http://www.ietf.org/internet-drafts/draft-ersue-constra= ined-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained= -mgmt
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt= -02
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrai= ned-mgmt-02

Abstract:
   This document raises = the questions on and discusses the use cases and
  =  requirements for the management of networks with constrained = devices.





The IETF = Secretariat


_______________________________________________coman mailing list
coman@ietf.org
https://www.ietf.org/mailman/listinfo/coman

 

------_=_NextPart_001_01CDB043.BD20BFE6-- From mehmet.ersue@nsn.com Mon Oct 22 07:19:23 2012 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 44A8F21F84F3; Mon, 22 Oct 2012 07:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn1n-qZZp05Q; Mon, 22 Oct 2012 07:19:17 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8FE21F842A; Mon, 22 Oct 2012 07:19:16 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q9MEJEvb020412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Oct 2012 16:19:14 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q9MEJDOw020311; Mon, 22 Oct 2012 16:19:14 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Oct 2012 16:19:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDB060.36187F76" Date: Mon, 22 Oct 2012 16:19:13 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640455DA5B@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt Thread-Index: Ac2uU9pfo1K6uzZVTMS7jQJxzNvPGAB3OHBgAAvVLcA= References: <80A0822C5E9A4440A5117C2F4CD36A640450885C@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A64045094C0@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ulrich Herberg" , "Carsten Bormann" X-OriginalArrivalTime: 22 Oct 2012 14:19:13.0937 (UTC) FILETIME=[36624010:01CDB060] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 34188 X-purgate-ID: 151667::1350915554-00006DFC-88711FE1/0-0/0-0 Cc: coman@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.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, 22 Oct 2012 14:19:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB060.36187F76 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > [ME]: There is no intention to exclude non-mobile devices. =20 s/non-mobile/mobile/ =20 Cheers,=20 Mehmet=20 =20 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, October 22, 2012 12:55 PM To: ext Ulrich Herberg; Carsten Bormann Cc: coman@ietf.org; opsawg@ietf.org Subject: Re: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt =20 Hi Ulrich, =20 see my comments below. =20 Cheers,=20 Mehmet=20 =20 From: ext Ulrich Herberg [mailto:ulrich@herberg.name]=20 Sent: Saturday, October 20, 2012 1:46 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: coman@ietf.org; opsawg@ietf.org Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt =20 Hi Mehmet, =20 thank you for updating the draft. There is a huge amount of great work in it, and I think this will provide a great basis for further discussions. Indeed, splitting up the document would be required at some point. =20 Some high-level comments: - Section 1.2 (Terminology): The definition of MANET and Intermediate entity (in COAP) come a bit surprising, since there has been no discussion before. Also, it seems inconsistent to define MANET, but not all the other use cases, such as AMI. =20 [ME]: The terminology section is incomplete and should be extended e.g. with AMI. =20 - Section 1.3 (Constrained Device Classes): I know that this definition is taken from Lwig, but I doubt that it is of much use. The absolute values will change. While now there are still many C0 devices out, in five years, they will not exist (or rather, the number 10KB would need to be replaced by a larger number). I think I would prefer a classification based on the capabilities (e.g. can support full IP stack, or not) =20 [ME]: The definition was actually first introduced by Carsten in the Smart Object workshop before IETF 80 in Prague. This is an important point. See my other mail. =20 - Section 1.4 (constrained networks): I don't think this is a very consistent classification of networks. First, CN0 seems to be the least constrained network, whereas C0 devices are the most constrained. I would suggest the remain the same ordering (0 the most constrained up to a positive number). =20 [ME]: The "0" in CN0 and C0 don't relate to each other. The constrainedness of a network is mostly dependent on the wireless technology used. I found it more useful to differentiate the type of the network, where the wireless technology can be manifold. =20 More importantly, there is a mixture with constrained devices in this definition. Since we talk about the network only, we should only talk about topology, lossy links, multi-hop, mobility etc. but not constrained devices.=20 =20 [ME]: I agree, we should talk here on devices only. =20 I don't understand why MANETs are not supported. Several of the use cases, such as the military use case, community networks and AMI are multi-hop networks with dynamic topology and lossy links. That is what I call a MANET.=20 =20 [ME]: The agreement in our last f2f meeting was that we want to include the MANET use case to highlight what it is but exclude from the requirements discussion. The reason is that MANETs can be based on very distinct scenarios and have specifics which are unique compared to other networks. The essential point is that MANETs are infrastructureless (i.e. without any hierarchy), which seems to be not the case in other network types the draft describes and makes network management essentially different. =20 Even the definition of CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are nothing else than MANETs (only difference is that routers are usually non-mobile; nevertheless, the topology is still dynamic because of fluctuating links.).=20 =20 [ME]: There might be similarities between a MANET and a Mesh network, however they are not the same thing. I have to admit we don't conceive sufficiently the special MANET use cases for frequent movement of routing devices without infrastructure. If we agree that a Mesh network covers the essential part of a MANET then I would suggest to focus on a Mesh network instead of trying to cover everything. =20 Is the intention to focus on non-mobile devices? =20 [ME]: There is no intention to exclude non-mobile devices. The draft currently assumes that, from the "network management" pov., both mobile and non-mobile devices have similar characteristics (I think we should describe this somewhere). The draft further assumes that the managing entity is not moving. =20 I might be wrong in this. Please describe which mobility aspects you think should be covered from "network management" pov. Managing the IP mobility itself, e.g. the IP address etc., is not network management per se. =20 Constrained networks are more difficult to define, as there are several aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I think that we need more discussion (but maybe after a BOF has been initiated?) =20 [ME]: We can start such a discussion already today. However, I assume it is mostly following the capabilities and limitations of the wireless technology. What would be your proposal for a classification of constrained networks? =20 - Section 1.5: (Network Topology Options): I think there is a mix between the topology (i.e., the graph that represents routers and communication links), traffic flows (which devices communicate with which other devices), and application layer (proxies and NMS). - Section 1.6: I like that. =20 - Section 1.7: There is mixture of constrained networks (first bullet); I thought that constrained devices only means that they have little CPU power and memory. Can't that device still use cable connectivity (i.e. unconstrained network)? Or is it necessarily linked? I am unclear about the purpose of this whole section. What does it serve for? =20 [ME]: Section 1.7 in general tries to list and discuss the issues a constrained device might have and how these issues influence the management of such a device. As described in section 1.4 and 2. we include non-constrained networks with constrained devices. =20 - Section 2: I think that the problem statement is not quite clear yet. It is hard to identify what the problems are; there are so many useful requirements in section 4, so maybe it could be better matched to these requirements. It would be nice to read section 4, and then say "ah, requirement x indeed logically follows from the problem y that has been described in section 2". =20 [ME]: I agree the problem statement in section 2 (which I didn't have time to update yet) could benefit from a revision aligning it with the new sections 1.7 and section 4. =20 - Section 3: I like the diverse use cases. That can be very useful to identify different requirements and problems. =20 - Section 4: I very much appreciate the enormous effort for gathering the requirements. There will be detailed discussions about them (hopefully), but this is a very good list to start from.=20 We have to define if the security related requirements also fit in this discussion, or better some place else (SOLACE?).=20 =20 [ME]: We see authentication and access control (to the extend it matters) as part of network management. This is probably the part where Coman and Solace can profit from and complement each other. =20 Again, I appreciate the effort of the authors, and hope that we can continue the discussions in Atlanta. I apologize that I only provided this high-level review, but the last weeks were very busy for me. If you need help authoring the documents once they are split up, I could help out. =20 Is there a meeting already planned?=20 =20 [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it once the room is known. Stay tuned. =20 Best regards Ulrich=20 =20 On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: Hi All, we submitted an update for the constrained-mgmt draft on the "Management of Networks with Constrained Devices: Use Cases and Requirements". The draft hopefully addresses most of the issues we discussed in the last meeting. I think it is already time to split the draft into three; e.g. problem statement, use cases and requirements. But this can be done after getting your feedback before and during IETF 85. I would highly appreciate your comments and any kind of discussion on the draft content especially on the requirements section. Thank you. Cheers, Mehmet -----Original Message----- From: ext internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 15, 2012 9:59 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: dromasca@avaya.com; j.schoenwaelder@jacobs-university.de Subject: New Version Notification for draft-ersue-constrained-mgmt-02.txt A new version of I-D, draft-ersue-constrained-mgmt-02.txt has been successfully submitted by Mehmet Ersue and posted to the IETF repository. Filename: draft-ersue-constrained-mgmt Revision: 02 Title: Management of Networks with Constrained Devices: Use Cases and Requirements Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 78 URL: http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt Status: http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt Htmlized: http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrained-mgmt-02 Abstract: This document raises the questions on and discusses the use cases and requirements for the management of networks with constrained devices. The IETF Secretariat _______________________________________________ coman mailing list coman@ietf.org https://www.ietf.org/mailman/listinfo/coman =20 ------_=_NextPart_001_01CDB060.36187F76 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= > [ME]: There is no intention to exclude non-mobile = devices.=

=  

= s/= non-mobile= /= mobile= /

=  

= Cheers,=
= Mehmet=

=  

From:= = opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of = Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, October 22, = 2012 12:55 PM
To: ext Ulrich Herberg; Carsten = Bormann
Cc: coman@ietf.org; opsawg@ietf.org
Subject: = Re: [OPSAWG] [coman] FW: New Version Notification = fordraft-ersue-constrained-mgmt-02.txt

<= p class=3DMsoNormal> 

= Hi Ulrich,

=  

= see my comments below.

=  

= Cheers,=
= Mehmet=

=  

From:= = ext Ulrich Herberg [mailto:ulrich@herberg.name] =
Sent: Saturday, October 20, 2012 1:46 AM
To: Ersue, = Mehmet (NSN - DE/Munich)
Cc: coman@ietf.org; opsawg@ietf.org
Subject: = Re: [coman] FW: New Version Notification for = draft-ersue-constrained-mgmt-02.txt

 

Hi = Mehmet,

 

thank you for updating the draft. There is a huge = amount of great work in it, and I think this will provide a great basis = for further discussions. Indeed, splitting up the document would be = required at some point.

 

Some high-level comments:

  - Section 1.2 (Terminology): The definition of = MANET and Intermediate entity (in COAP) come a bit surprising, since = there has been no discussion before. Also, it seems inconsistent to = define MANET, but not all the other use cases, such as = AMI.

 

= [ME]: The terminology section is incomplete and should be extended e.g. = with AMI.

=  

  - = Section 1.3 (Constrained Device Classes): I know that this definition is = taken from Lwig, but I doubt that it is of much use. The absolute values = will change. While now there are still many C0 devices out, in five = years, they will not exist (or rather, the number 10KB would need to be = replaced by a larger number). I think I would prefer a classification = based on the capabilities (e.g. can support full IP stack, or = not)

 

= [ME]: The definition was actually first introduced by Carsten in the = Smart Object workshop before IETF 80 in Prague. This is an important = point. See my other mail.

=  

  - = Section 1.4 (constrained networks): I don't think this is a very = consistent classification of networks. First, CN0 seems to be the least = constrained network, whereas C0 devices are the most constrained. I = would suggest the remain the same ordering (0 the most constrained up to = a positive number).

=  

= [ME]: The “0” in CN0 and C0 don’t relate to each = other. The constrainedness of a network is mostly dependent on the = wireless technology used. I found it more useful to differentiate the = type of the network, where the wireless technology can be = manifold.

=  

More = importantly, there is a mixture with constrained devices in this = definition. Since we talk about the network only, we should only talk = about topology, lossy links, multi-hop, mobility etc. but not = constrained devices. 

=  

= [ME]: I agree, we should talk here on devices = only.

=  

I don't = understand why MANETs are not supported. Several of the use cases, such = as the military use case, community networks and AMI are multi-hop = networks with dynamic topology and lossy links. That is what I call a = MANET.

=  

= [ME]: The agreement in our last f2f meeting was that we want to include = the MANET use case to highlight what it is but exclude from the = requirements discussion. The reason is that MANETs can be based on very = distinct scenarios and have specifics which are unique compared to other = networks. The essential point is that MANETs are infrastructureless = (i.e. without any hierarchy), which seems to be not the case in other = network types the draft describes and makes network management = essentially different.

=  

Even the definition of = CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are = nothing else than MANETs (only difference is that routers are usually = non-mobile; nevertheless, the topology is still dynamic because of = fluctuating links.).

=  

= [ME]: There might be similarities between a MANET and a Mesh network, = however they are not the same thing. I have to admit we don’t = conceive sufficiently the special MANET use cases for frequent movement = of routing devices without infrastructure. If we agree that a Mesh = network covers the essential part of a MANET then I would suggest to = focus on a Mesh network instead of trying to cover = everything.

=  

Is the intention to = focus on non-mobile devices?

=  

= [ME]: There is no intention to exclude non-mobile devices. The draft = currently assumes that, from the “network management” pov., = both mobile and non-mobile devices have similar characteristics (I think = we should describe this somewhere). The draft further assumes that the = managing entity is not moving.

=  

= I might be wrong in this. Please describe which mobility aspects you = think should be covered from “network management” pov. = Managing the IP mobility itself, e.g. the IP address etc., is not = network management per se.

=  

Constrained = networks are more difficult to define, as there are several aspects: = bandwidth, loss rates of the channel, MTU, topology, etc. I think that = we need more discussion (but maybe after a BOF has been = initiated?)

=  

= [ME]: We can start such a discussion already today. However, I assume it = is mostly following the capabilities and limitations of the wireless = technology. What would be your proposal for a classification of = constrained networks?

 

- = Section 1.5: (Network Topology Options): I think there is a mix between = the topology (i.e., the graph that represents routers and communication = links), traffic flows (which devices communicate with which other = devices), and application layer (proxies and = NMS).

- Section 1.6: I = like that.

 

- = Section 1.7: There is mixture of constrained networks (first bullet); I = thought that constrained devices only means that they have little CPU = power and memory. Can't that device still use cable connectivity (i.e. = unconstrained network)? Or is it necessarily = linked?

I am unclear about = the purpose of this whole section. What does it serve = for?

 

= [ME]: Section 1.7 in general tries to list and discuss the issues a = constrained device might have and how these issues influence the = management of such a device. As described in section 1.4 and 2. we = include non-constrained networks with constrained = devices.

=  

- Section 2: = I think that the problem statement is not quite clear yet. It is hard to = identify what the problems are; there are so many useful requirements in = section 4, so maybe it could be better matched to these requirements. It = would be nice to read section 4, and then say "ah, requirement x = indeed logically follows from the problem y that has been described in = section 2".

=  

= [ME]: I agree the problem statement in section 2 (which I didn’t = have time to update yet) could benefit from a revision aligning it with = the new sections 1.7 and section 4.

 

- = Section 3: I like the diverse use cases. That can be very useful to = identify different requirements and = problems.

 

- = Section 4: I very much appreciate the enormous effort for gathering the = requirements. There will be detailed discussions about them (hopefully), = but this is a very good list to start = from. 

We have to = define if the security related requirements also fit in this discussion, = or better some place else (SOLACE?). 

=  

= [ME]: We see authentication and access control (to the extend it = matters) as part of network management. This is probably the part where = Coman and Solace can profit from and complement each = other.

 

Again, I appreciate the effort of the authors, and = hope that we can continue the discussions in Atlanta. I apologize that I = only provided this high-level review, but the last weeks were very busy = for me. If you need help authoring the documents once they are split up, = I could help out.

 

Is there a meeting already = planned? 

 

= [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it = once the room is known. Stay tuned.

=  

Best = regards

Ulrich 

 

On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - = DE/Munich) <mehmet.ersue@nsn.com> wrote:

Hi All,

we submitted an update for the = constrained-mgmt draft on the "Management
of Networks with = Constrained Devices: Use Cases and Requirements". The
draft = hopefully addresses most of the issues we discussed in the = last
meeting.

I think it is already time to split the draft = into three; e.g. problem
statement, use cases and requirements. But = this can be done after
getting your feedback before and during IETF = 85.

I would highly appreciate your comments and any kind of = discussion on
the draft content especially on the requirements = section. Thank you.

Cheers,
Mehmet


-----Original = Message-----
From: ext internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - = DE/Munich)
Cc: dromasca@avaya.com; j.schoenwaelder@jaco= bs-university.de
Subject: New Version Notification = for
draft-ersue-constrained-mgmt-02.txt


A new version of = I-D, draft-ersue-constrained-mgmt-02.txt
has been successfully = submitted by Mehmet Ersue and posted to the
IETF = repository.

Filename:       =  draft-ersue-constrained-mgmt
Revision:       =  02
Title:           Management of = Networks with Constrained Devices: Use
Cases and = Requirements
Creation date:   2012-10-15
WG ID:     =       Individual Submission
Number of pages: = 78
URL:
http://www.ietf.org/internet-drafts/draft-ersue-constra= ined-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained= -mgmt
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt= -02
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ersue-constrai= ned-mgmt-02

Abstract:
   This document raises = the questions on and discusses the use cases and
  =  requirements for the management of networks with constrained = devices.





The IETF = Secretariat


_______________________________________________coman mailing list
coman@ietf.org
https://www.ietf.org/mailman/listinfo/coman

 

------_=_NextPart_001_01CDB060.36187F76-- From denghui02@gmail.com Mon Oct 22 08:03:43 2012 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 EE27921F8C33 for ; Mon, 22 Oct 2012 08:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYrrBufpS8Qm for ; Mon, 22 Oct 2012 08:03:41 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC31321F8C31 for ; Mon, 22 Oct 2012 08:03:40 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so1852847qcg.31 for ; Mon, 22 Oct 2012 08:03: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 :content-type; bh=CQ6U13No9Jfrv1KccAOiM0at6ou4LCwOL9qu5/FGUsA=; b=gqyO6p6LLqk/oCemL8ju5SSKM9bUkuDoM1QDfIuw56ShPYsShXnRXCZnGgyPatz4ko GiUTZURUphvU4u+FJZRhjMmJconhJngKvMNmn+Gk/YHi6Cd4UTl3zut12FNQzE7+RaB9 BrIrFPPpVFI8mjWhxV5anG6txUFw9xl8Zj4HOGD90cYa/aNYH4pDLNmDKEOnHc3NVYyW wweRhDRXFx2qInOl7pOrFSHjRkSNyXYzeiH0IIUIJyO7Zwdp7VGaMuGsKSbaeapgBX4U tXVN75S2p2pDhWx1hvVTSW9I9pjBdY1K1xLlogz9UKhF/QwYOQhPvaNLbJhRQpk41i68 ElBg== MIME-Version: 1.0 Received: by 10.49.103.162 with SMTP id fx2mr5175605qeb.1.1350918218053; Mon, 22 Oct 2012 08:03:38 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Mon, 22 Oct 2012 08:03:38 -0700 (PDT) In-Reply-To: <20121022145753.18443.96364.idtracker@ietfa.amsl.com> References: <20121022145753.18443.96364.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 23:03:38 +0800 Message-ID: From: Hui Deng To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=047d7b2e79c881f89504cca72885 Subject: [OPSAWG] Fwd: I-D Action: draft-shao-capwap-plus-ps-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: Mon, 22 Oct 2012 15:03:43 -0000 --047d7b2e79c881f89504cca72885 Content-Type: text/plain; charset=ISO-8859-1 Hello all We have updated the draft based on the comments in the list, thanks Satoru. and offline discussion. Thanks Farooq's kind help, revision of the draft. The major update would be 1) We re-write the section 4 about the issue of today definition of Split and Local Mac mode. 2) Lots of editoring revision, and add Farooq from AT&T as the coauthor 3) Add Satoru from softbank as the contributor. thank you all for your kind help Best regards, -Hui ---------- Forwarded message ---------- From: Date: 2012/10/22 Subject: I-D Action: draft-shao-capwap-plus-ps-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhancement of CAPWAP Problem Statement Author(s) : Chunju Shao Hui Deng Rong Zhang Farooq Bari Filename : draft-shao-capwap-plus-ps-01.txt Pages : 8 Date : 2012-10-22 Abstract: In recent widescale deployments of large public Wi-Fi networks, and in their integration with cellular networks EAP based authentication has been considered as a good candidate to making Wi-Fi user experience seamless similar to what it has been for cellular users. A few new functions which could enhance CAPWAP protocol have been identified in such deployments that can help improve the large scale carrier grade Wi-Fi networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-shao-capwap-plus-ps There's also a htmlized version available at: http://tools.ietf.org/html/draft-shao-capwap-plus-ps-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-shao-capwap-plus-ps-01 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-Draftdirectories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --047d7b2e79c881f89504cca72885 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
We have updated the draft based on t= he comments in the list, thanks Satoru.
and offline discussion.= =A0 Thanks Farooq's kind help, revision of=A0the draft.
=A0
The major=A0update would be
1) We re-write the section 4 about t= he issue of today definition of Split and Local Mac mode.
2) Lots= of editoring revision, and add Farooq from AT&T as the coauthor
3) Add Satoru from softbank as the contributor.
=A0
thank you all for your kind help
Best regards,
=A0
-Hui

---------- Forwarded m= essage ----------
From: <internet-drafts@ietf.org>
= Date: 2012/10/22
Subject: I-D Action: draft-shao-capwap-plus-ps-01.txt To: i-d-announce@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Enhancement of CAPWAP Problem S= tatement
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Chunju Shao
=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 Rong Zhang
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Farooq Bari
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-shao-capwap-plus-ps-01.txt<= br> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-22

Abstract:
=A0 =A0In recent widescale deployments of large public Wi-Fi networks, and<= br> =A0 =A0in their integration with cellular networks EAP based authentication=
=A0 =A0has been considered as a good candidate to making Wi-Fi user
=A0 =A0experience seamless similar to what it has been for cellular users.<= br> =A0 =A0A few new functions which could enhance CAPWAP protocol have been =A0 =A0identified in such deployments that can help improve the large scale=
=A0 =A0carrier grade Wi-Fi networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-shao-capwap-plus-ps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-shao-capwap-plus-ps-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-shao-capwap-plu= s-ps-01


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

--047d7b2e79c881f89504cca72885-- From denghui02@gmail.com Tue Oct 23 00:32:56 2012 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 4DCB121F84F6 for ; Tue, 23 Oct 2012 00:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.987 X-Spam-Level: X-Spam-Status: No, score=-98.987 tagged_above=-999 required=5 tests=[AWL=-3.284, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1YZezsO4Duy for ; Tue, 23 Oct 2012 00:32:54 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C16F021F8504 for ; Tue, 23 Oct 2012 00:32:53 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2372163qcg.31 for ; Tue, 23 Oct 2012 00:32:53 -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=G7IhKalEz9ebORV9ajLM+g2ZbcxOyRWo6nw4d9V/oaA=; b=y9kbZoWL46XdGJs+Vn/PnrsaWAzRNCFM6lzWrsySGegrw3m3JQkDpB3EXJzyBGyRir AhWz4UaKAITjK7Xt3nSSJGuVVG2VajuQn5fZxXEG1/pTS8ACaYY8oHNXO3fxGBxGXvoX DaemMWOIxdeJubBmVR68/nzlIn/1XX1SxsEzM9eIPxwARv374CduxM0QFGzL0s5/Lk94 hxahLmrUH4tAKow/10fSgN6BGcmC65hg39JmKqc3WvbAavTpstKur6Gz/fts8QHONxjp 7vr7OmAi4K1AD+pzF4DtcyDzmRntJUVZl8my8pBUadxyJZYapmclrNtzj4nDNwqqG6Yk gKtw== MIME-Version: 1.0 Received: by 10.224.9.138 with SMTP id l10mr5367644qal.58.1350977573319; Tue, 23 Oct 2012 00:32:53 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Tue, 23 Oct 2012 00:32:53 -0700 (PDT) In-Reply-To: <006701cdb0d9$1550a190$3ff1e4b0$@com> References: <20121022145753.18443.96364.idtracker@ietfa.amsl.com> <006701cdb0d9$1550a190$3ff1e4b0$@com> Date: Tue, 23 Oct 2012 15:32:53 +0800 Message-ID: From: Hui Deng To: wanghao Content-Type: multipart/alternative; boundary=bcaec517ab7a5b747a04ccb4fac9 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] =?gb2312?b?tPC4tDogIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtc2hh?= =?gb2312?b?by1jYXB3YXAtcGx1cy1wcy0wMS50eHQ=?= 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, 23 Oct 2012 07:32:56 -0000 --bcaec517ab7a5b747a04ccb4fac9 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Wanghao, Thanks for your review and comments here, inline with "=3D=3D>" please, 2012/10/23 wanghao > Hi Denghui:**** > > ** ** > > I think you are discussing about an =A1=B0central authentication and l= ocal forwarding=A1=B1 scenario. **** > > ** ** > > In my point of view, this mode will become more and more popular with = the increasing bandwidth of Wifi. **** > > ** ** > > This is a very useful topic and the current CAPWAP standard does not cove= r this issue. > > =3D=3D> thanks , > > ** ** > > However, I suggest we can discuss this topic in 2 steps.**** > > ** ** > > **1. **Separate Data-tunnel and Ctrl-tunnel as you mentioned in the draft= . The CAPWAP-Ctrl tunnel is terminated on AC and the CAPWAP-Data tunnel is = terminated on AP.**** > > This is not a simple issue, because some data(like flow table) needed to = be synchronized between AC and AR. > > =3D=3D> I guess here you mean CAPWAP-Data Tunnel terminate at BRAS(AR) ot= her than AP? can you help to elabroate what do you mean flow table here? > > ** ** > > 2=A3=AEHow do we encapsulate the EAP packets=A3=BF**** > > **=3D=3D> for deployment, people can support them step by step, for stand= ard, we can do it now, it takes time to finish them, especially in IETF. :) > > > > > Other topics are OK. 11n, Channel auto, Power Auto these features need= ed to be added into standard.**** > > **=3D=3D> thanks for your support > > > > Best regards, -Hui > ** > > Best regards**** > > Wanghao**** > > ** ** > > ** ** > > ** ** > > *=B7=A2=BC=FE=C8=CB:* opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf= .org] *=B4=FA=B1=ED *Hui > Deng > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2012=C4=EA10=D4=C222=C8=D5 23:04 > *=CA=D5=BC=FE=C8=CB:* opsawg@ietf.org > *=D6=F7=CC=E2:* [OPSAWG] Fwd: I-D Action: draft-shao-capwap-plus-ps-01.tx= t**** > > ** ** > > Hello all**** > > **** > > We have updated the draft based on the comments in the list, thanks Sator= u. > **** > > and offline discussion. Thanks Farooq's kind help, revision of the draft= . > **** > > **** > > The major update would be **** > > 1) We re-write the section 4 about the issue of today definition of Split > and Local Mac mode.**** > > 2) Lots of editoring revision, and add Farooq from AT&T as the coauthor**= * > * > > 3) Add Satoru from softbank as the contributor.**** > > **** > > thank you all for your kind help**** > > Best regards,**** > > **** > > -Hui**** > > ---------- Forwarded message ---------- > From: > Date: 2012/10/22 > Subject: I-D Action: draft-shao-capwap-plus-ps-01.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Enhancement of CAPWAP Problem Statement > Author(s) : Chunju Shao > Hui Deng > Rong Zhang > Farooq Bari > Filename : draft-shao-capwap-plus-ps-01.txt > Pages : 8 > Date : 2012-10-22 > > Abstract: > In recent widescale deployments of large public Wi-Fi networks, and > in their integration with cellular networks EAP based authentication > has been considered as a good candidate to making Wi-Fi user > experience seamless similar to what it has been for cellular users. > A few new functions which could enhance CAPWAP protocol have been > identified in such deployments that can help improve the large scale > carrier grade Wi-Fi networks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-shao-capwap-plus-ps > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-shao-capwap-plus-ps-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-shao-capwap-plus-ps-01 > > > 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**** > > ** ** > --bcaec517ab7a5b747a04ccb4fac9 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Wanghao,
 
Thanks for your review and comm= ents here, inline with "=3D=3D>" please,

2012/10/23 wanghao <hwang@h3c.com>
<= pre>Hi Denghui:
 
&n=
bsp;  I think you are discussing about an “central authentication and local forwarding” scenario. 
 
   In my point of view, this mode will become more and=
 more popular with the increasing bandwidth of Wifi. <=
/pre>
 


This is a very useful =
topic and the current CAPWAP standard does not cover this issue.
=3D=3D> thanks , =



 
   However, I suggest we can discuss this topic in 2 s=
teps.
 <=
/u>
1. Separate Data-tunnel and Ctrl-tunnel =
as you mentioned in the draft. The CAPWAP-Ctrl tunnel is terminated on AC a=
nd the CAPWAP-Data tunnel is terminated on AP.


This is not a simple i=
ssue, because some data(like flow table) needed to be synchronized between =
AC and AR.
=3D=3D> I guess here you mean CAPWAP-Data Tunnel terminate at BRAS(AR) =
other than AP? can you help to elabroate what do you mean flow table here?<=
/span>


 
   2=A3=AEHow do we encaps=
ulate the EAP packets=A3=BF
=3D=3D> for deployment, people c=
an support them step by step, for standard, we can do it now, it takes time=
 to finish them, especially in IETF. :) 


 
 
<= pre>   Other topics are OK. 11n, Channel aut= o, Power Auto these features needed to be added into standard.
=3D=3D> thanks for your support
= 
 
Best regards,
 
-Hui 
 
<= pre> 
Best regards
Wanghao<=
u>

=  

 

=  

=B7=A2=BC=FE=C8=CB: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ie= tf.org] =B4= =FA=B1=ED Hui Deng
=B7=A2=CB=CD=CA= =B1=BC=E4: 2012=C4=EA10=D4=C222=C8=D5 23:04
=CA=D5=BC=FE=C8=CB: opsawg@ietf.or= g
=D6=F7=CC=E2: [OPSAWG] Fwd: I-D Action: draft-shao-capwap-plus-ps-01.txt

 

Hello all

 

We have updated the = draft based on the comments in the list, thanks Satoru.

and offline dis= cussion.  Thanks Farooq's kind help, revision of the draft.

 =

The major=  update would be

1) We re-write the section 4 about the issue of = today definition of Split and Local Mac mode.

2) Lots of editoring= revision, and add Farooq from AT&T as the coauthor

3) Add Satoru f= rom softbank as the contributor.

 =

thank you= all for your kind help

Best regards,

 =

<= span lang=3D"EN-US">-Hui

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: 2012/10/22
Subject: I-D Action: d= raft-shao-capwap-plus-ps-01.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Dra= fts directories.


        Title    =       : Enhancement of CAPWAP Problem Statement
  &= nbsp;     Author(s)       : Chunju Shao
  =                      = ;   Hui Deng
                     = ;     Rong Zhang
            &nb= sp;             Farooq Bari
    =     Filename        : draft-shao-capwap-plus-= ps-01.txt
        Pages         =   : 8
        Date         =    : 2012-10-22

Abstract:
   In recent widescale deployments of large public Wi-Fi networks= , and
   in their integration with cellular networks EAP based= authentication
   has been considered as a good candidate to = making Wi-Fi user
   experience seamless similar to what it ha= s been for cellular users.
   A few new functions which could enhance CAPWAP protocol have b= een
   identified in such deployments that can help improve th= e large scale
   carrier grade Wi-Fi networks.


The = IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-shao-capwap-plus-ps

There's also a htmlized version available at:
ht= tp://tools.ietf.org/html/draft-shao-capwap-plus-ps-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-shao-capwap-plus-ps-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/intern= et-drafts/

_______________________________________________
I-= D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-= announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.or= g/ietf/1shadow-sites.txt

 


--bcaec517ab7a5b747a04ccb4fac9-- From cb.list6@gmail.com Tue Oct 23 13:07:48 2012 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 A7BA321F8633 for ; Tue, 23 Oct 2012 13:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V6+X2qPNYsy for ; Tue, 23 Oct 2012 13:07:48 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62E6021F855E for ; Tue, 23 Oct 2012 13:07:47 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2967241lam.31 for ; Tue, 23 Oct 2012 13:07:44 -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 :content-transfer-encoding; bh=M7rd/hpRgr3XkXflfU5uOYf/vyD2dY5B5D+caFmsH8k=; b=bbjkpAd7K+M/RfK2a9QAQpyHMRMBqgKhuH2zlVBa6ESgfuQr1laUxQui9tZu7cfgc0 uO4NOiUZxacFCQlEORO2wVSTsTFnV0+Am8GHM39d3yNeSRmOk3a66gHI10+K5kGHU35l dc4O1PjEpBbFgZGndwUQVxn5n6MmAYBaVoA1viQyXnKyoSlHWA6IPYc0ev6fOSQ5EkE5 lRhk7dhkaNoVvnXLYwcn55wfKNIEzcCrKTCi2f4tBT1TtZQtSlmQJho6SFqcA231pgNZ C6zHLpBPSbF0o/PRGKpjgJfWhxGC24j+BgGEbYwBCbvc6RR5gjrjhbeRr3ZKsx6InAEf l4ag== MIME-Version: 1.0 Received: by 10.152.104.107 with SMTP id gd11mr12225568lab.25.1351022864754; Tue, 23 Oct 2012 13:07:44 -0700 (PDT) Received: by 10.112.81.167 with HTTP; Tue, 23 Oct 2012 13:07:44 -0700 (PDT) Date: Tue, 23 Oct 2012 13:07:44 -0700 Message-ID: From: Cameron Byrne To: opsawg@ietf.org, draft-ietf-opsawg-firewalls@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [OPSAWG] comments on draft-ietf-opsawg-firewalls-01 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, 23 Oct 2012 20:07:48 -0000 Fred and Paul, Thanks for writing this draft, a few comments below. Unfortunately, my comments are largely the result of me doing a mental diff of your I-D and my vapor I-D titled "Stateful Packet Inspection Advisory" 1. The introduction states a worthy goal. 2. The treatment of E2E and information theory is not required. It does not add value to the document. The audience is looking for an ops BCP, not nuanced discussion of abstract principles. 3. The overly simplistic definition of a firewall causes confusion. It may be best to just discuss packet filtering =96 stateful and stateless (and flow, or capacity [think qos policers]). Firewall is too much of a loaded term and maybe should be abandoned in this document. 4. Problems with stateful packet inspection (SPI) firewalls a. Require symmetric routing, this frequently creates a single point of failure as network admins look to create a single point of entry and policy enforcement. This also frequently creates routing complexities. b. Require fragment re-assembly, frag cache is another way to attack an SPI firewall or degrade its performance. c. Flow state can degrade capacity and cause outages, this is a huge issue. This SPI FW can do 1M sessions....and it starts to break at 800k sessions, and really tips over a 1.1M sessions. Sessions rate limiters can help in some cases, but not all. d. ALGs are required when filtering many protocols dynamically base on state. ALGs are fragile and frequently break, it is hard to code all the cases of how SIP will behave and what ports need to be opened as result of an SIP/SDP message (what RTP pin holes to dynamically open). e. ALG are also frequently a control plane function, and control plane functions scale much less well than hardware forwarding. This is yet another attack vector on the SPI firewall itself. f. Examples of how to properly use a SPI firewall would help. For example, a DNS server should never be behind a network based SPI firewall. ( the information is public, the ports are open either way, UDP is stateless, many small sessions open and close quickly.... ) g. State that an organization=92s =93network=94 is seldom a good a perimeter for an SPI firewall, a LAN may be a perimeter, or a functional zone within a data center (=93bid data=94 LAN) may be a perimeter. Some examples would help. I would promote the ideas of zones or enclaves that have specific security policies and controls in place that match and mitigate specific the risks that are well suited for an SPI firewall. 5. Most hosts have firewalls today, and most consumer hosts have firewalls on by default with a policy to deny all incoming connections. The trend should be away from SPI firewalls since this function is nearly universally deployed in hosts. 6. Hosts that do not =93listen=94 on ports / sockets have nothing to block with the exception of ICMP, they typically do not need a network based firewall. A network firewall is only helpful in the case that requires redundant enforcement of policy. For example, if the policy is that hosts on a LAN may not have incoming connections allowed, controlling the hosts to no allow incoming connections is sufficient to conform to the policy. This may be achieved by not running any =93services=94 to listen. This may be further enforced by local packet filtering policy on the host. If the host cannot be trusted, then the network must enforce the policy within the network. 7. Another case is the preservation of LAN bandwidth. We only allow inbound traffic that was first initiated from the LAN towards the WAN. How common / real is a LAN BW starvation threat? 8. The days of Nimda, code red, sql slammer, and so on are gone because of host based firewalls as well as greater care when coding network stacks and applications. The document should go to some length to emphasize this point and discuss how the industry has =93over corrected=94 for sins of the past and now some rationalization must take place. 9. An SPI Firewall is most fit for acting as a low volume logging control point. They should only be used when adherence to policy is of extreme important that multiple discrete devices must enforce and log conformance to policy 10. Firewall policies scale best when they are stateless. Need to define and advise when, how, and where stateless verses stateful can be employed. Focus stateless filtering on course grain at the AS edge, focus on fine stateless grain filtering at the application edge, and in the rare case on stateful at the application edge. Hosts are fit to do both stateful and stateless filtering. 11. Remote trigger blackhole [RFC5635] is another effective form of stateless filtering that should be mentioned as an effective tool From melinda.shore@gmail.com Wed Oct 24 11:41:24 2012 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 ECF4A21F8858 for ; Wed, 24 Oct 2012 11:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faKhFuUlUzMB for ; Wed, 24 Oct 2012 11:41:23 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7F21F843D for ; Wed, 24 Oct 2012 11:41:23 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1409375pbb.31 for ; Wed, 24 Oct 2012 11:41:23 -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=YRZZ6razHAvTpHhwFqVAPdnyOG4cptcnrBBSPbdBQJE=; b=zFiBNKMjOocJLUpSWkwUL6p73xoGAqOT0K9BQf0nO9lc9Uk0nx9t1d9tdYCCkRw0hW +kmuSzd1sxvWUojOjzj2Zq7ezMFJEcJOE1XrdxArQYyH7y7AIWbjqRfKPn8Ji7jvtuK2 PMVkyCBW0KM+HKtzkpdJsmnTfqoMspHfwoPJc15A/aOd00RBcGWBxDD4MvjUGgAqhpNs LqkFjKr918p5iJpw6mKd3wLic26M7mHOA/tId/hMlzH7+gymycPQY31PaCIvTflykr63 AUyBB1khrAfbSNbJVafR/ificZU+ppuh7kxuMEUqex6pQ1xl0MEPSDLDQGZlGSE1L6WG iCQQ== Received: by 10.68.132.165 with SMTP id ov5mr51656935pbb.105.1351104083140; Wed, 24 Oct 2012 11:41:23 -0700 (PDT) Received: from spandex.local (216-67-49-109-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.49.109]) by mx.google.com with ESMTPS id ko10sm8999210pbc.1.2012.10.24.11.41.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 11:41:22 -0700 (PDT) Message-ID: <50883650.4060706@gmail.com> Date: Wed, 24 Oct 2012 10:41:20 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] IETF 85 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: Wed, 24 Oct 2012 18:41:24 -0000 A first crack at an agenda for our session at IETF 85 has been posted to https://datatracker.ietf.org/meeting/85/agenda/opsawg/. Let me know if there are omissions, or if you are on the agenda and don't think you should be. Note that we will be meeting jointly with opsarea, as we have the past few IETFs. Melinda From liljenstolpe@gmail.com Wed Oct 24 12:00:33 2012 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 812B421F88F4 for ; Wed, 24 Oct 2012 12:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+CDOkfPgkpR for ; Wed, 24 Oct 2012 12:00:31 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB94421F8939 for ; Wed, 24 Oct 2012 12:00:23 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so575491pad.31 for ; Wed, 24 Oct 2012 12:00:23 -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=v9flRjpckZ0P/OQOElwGibxXbqYlGZ2RCGXwQhU+hdI=; b=dwLOmgAfgMAraR+/tHaC2OsZygxG1r+YUErWObWWw2cpunGdg8t1TCoMoJ7BqxBzFX IyfQ9nVlB7Oq3Hko23EkvlBlVPPoqXBr4k/diYBJcmmUPERzp8PceQL7u5oGFjHzPaa0 sm50ktlg6sGoPYyIX4pvpt9vhB4WUIkfqbSxL/y8e8dvAEfwXqzaYGhJVq1HLo0WhhH7 CxLSDGAEwIJwbNXC+JnWj041FpcATgbey8TsOkKxMOOa0+OJ5NTruOaB3ZOHC29RiBDS vegSuPF8t3stSHkoEQ5HYOP0oW5DXlsxzboiDkIA7HvmbehxLyCRS5bZ3kjzToAvlZ/k miPA== Received: by 10.68.228.130 with SMTP id si2mr33714984pbc.126.1351105223455; Wed, 24 Oct 2012 12:00:23 -0700 (PDT) Received: from [192.168.254.18] (74-93-4-132-SFBA.hfc.comcastbusiness.net. [74.93.4.132]) by mx.google.com with ESMTPS id vc2sm9836589pbc.64.2012.10.24.12.00.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 12:00:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Christopher LILJENSTOLPE In-Reply-To: <50883650.4060706@gmail.com> Date: Wed, 24 Oct 2012 12:00:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <426048F3-E664-4948-9579-6EBCC4D0ADDF@gmail.com> References: <50883650.4060706@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1499) Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] IETF 85 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: Wed, 24 Oct 2012 19:00:34 -0000 Greetings, Also, if anyone now wants to volunteer for scribe and minutes, = that would be appreciated. Chris On 24Oct2012, at 11.41, Melinda Shore wrote: > A first crack at an agenda for our session at IETF 85 has been > posted to https://datatracker.ietf.org/meeting/85/agenda/opsawg/. > Let me know if there are omissions, or if you are on the agenda > and don't think you should be. Note that we will be meeting > jointly with opsarea, as we have the past few IETFs. >=20 > Melinda > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg