From linda.dunbar@huawei.com Fri Apr 5 13:53:58 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E221F9895 for ; Fri, 5 Apr 2013 13:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmKbX3vhYMAD for ; Fri, 5 Apr 2013 13:53:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 10BAA21F8F12 for ; Fri, 5 Apr 2013 13:53:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARL31025; Fri, 05 Apr 2013 20:53:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Apr 2013 21:53:30 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Apr 2013 21:53:49 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.122]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Fri, 5 Apr 2013 13:53:38 -0700 From: Linda Dunbar To: Sheng Jiang Thread-Topic: Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00 Thread-Index: AQHOMj+lLpV2o2UKbUiE6Jh/BYoy3g== Date: Fri, 5 Apr 2013 20:53:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645AF9B86@dfweml509-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AA09E53@nkgeml512-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645AF4AB9@dfweml509-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AA0AEE6@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AA0AEE6@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.167] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "int-area@ietf.org" Subject: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 20:53:58 -0000 U2hlbmcsIEJyaWFuLCBlbCBhdDogDQoNCkkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1pbnRhcmVhLWZs b3ctbGFiZWwtYmFsYW5jaW5nLTAwDQoNCkhlcmUgYXJlIG15IGNvbW1lbnRzOg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNClRoZSBkcmFmdCBpcyB0byBzdWdnZXN0 IHVzaW5nIElQdjYgaGVhZGVyJ3MgZmxvdyBsYWJlbCBmaWVsZCB0byBpZGVudGlmeSBkaWZmZXJl bnQgZmxvd3MgZnJvbSBJUHY2IGhvc3RzLiBUaGUgZHJhZnQgdHJpZXMgdG8gZW1waGFzaXplIHRo YXQgdGhlIGZsb3cgbGFiZWwgY2FuIGhlbHAgZGV2aWNlcyBhbG9uZyB0aGUgd2F5IGJldHdlZW4g U291cmNlICYgZGVzdGluYXRpb24gdG8gYWNoaWV2ZSBiZXR0ZXIgZmxvdyBzZXBhcmF0aW9uIG9y IGZpbmVyIHR1bmVkIHRyYWZmaWMgYmFsYW5jaW5nIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBwYXRo cy4gDQoNCkhvd2V2ZXIsIHRoZSBTZWN0aW9uIDMgZGV2b3RlcyBzbyBtdWNoIHRvIHZhcmlvdXMg TEIgc2NoZW1lcy4gQnV0IG1hbnkgYXJlIGlycmVsZXZhbnQuIFRoZXJlIGFyZSBtYW55IGRpZmZl cmVudCB0eXBlcyBvZiBMb2FkIEJhbGFuY2UsIHRoZSBETlMgYmFzZWQgbG9hZCBiYWxhbmNpbmcs IHdoaWNoIGlzIG9mdGVuIGNhbGxlZCBnbG9iYWwgTEIsICBoYXMgbm90aGluZyB0byBkbyB3aXRo IExCIGluIGZyb250IG9mIGEgY2x1c3RlciBvZiBzZXJ2ZXJzLiANCg0KU29tZSBkZXNjcmlwdGlv biBhYm91dCBMQiBpbiBTZWN0aW9uIDMgaXMgbm90IHF1aXRlIHRvIHRoZSBwb2ludC4gRm9yIGV4 YW1wbGUsIHRoZSBzZWNvbmQgYnVsbGV0IHlvdSBzdGF0ZWQ6ICJBbm90aGVyIG1ldGhvZCwgZm9y IEhUVFAgc2VydmVycywgaXMgdG8gb3BlcmF0ZSBhIGxheWVyIDcgcmV2ZXJzZSBwcm94eSBpbiBm cm9udCBvZiB0aGUgc2VydmVyIGZhcm0uIiBUaGUgTEIgaW4gZnJvbnQgb2YgYSBjbHVzdGVyIG9m IHNlcnZlcnMgaXMgb3J0aG9nb25hbCB0byBETlMgYmFzZWQgZ2xvYmFsIExCLiANCg0KWW91ciBk cmFmdCBkaWRuJ3QgZXZlbiBtZW50aW9uICJEaXJlY3QgU2VydmVyIFJldHVybiAoRFNSKSIgTEIg c2NoZW1lIHdoaWNoIGlzIHVzZWQgaGVhdmlseSBpbiBEQyB0byBiYWxhbmNlIGxvYWQgYW1vbmcg YSBjbHVzdGVyIG9mIHNlcnZlcnMuIEluIHRoaXMgc2NoZW1lLCBhbGwgdGhlIHNlcnZlcnMgaW4g YSBjbHVzdGVyIHNoYXJlIGEgY29tbW9uIElQIGFkZHJlc3Mgd2hpY2ggaXMgc2FtZSBhcyB0aGUg TEIsIG9yIHVzZSBmbG9hdGluZyBJUCBhZGRyZXNzIGZvciBob3N0cy4gDQoNClRoZSBmaWd1cmUg aW4gUGFnZSA3IGlzIGhhcyBzb21lIGVycm9ycyB0b28uIFRoZSBETlMgYmFzZWQgTG9hZCBCYWxh bmNpbmcgaXMgdXN1YWxseSBpbiB0aGUgQWNjZXNzIG5ldHdvcmsuIChJIHJlYWxseSB0aGluayB0 aGlzIGZpZ3VyZSBpcyBub3QgbmVjZXNzYXJ5IGJlY2F1c2UgaXQgZG9lc24ndCBoZWxwIHRoZSBk cmFmdCBhdCBhbGwpLiANCg0KVGhlIExCIGZvciBTZXJ2ZXIgQ2x1c3RlciBpcyBtb3JlIGxpa2Vs eSBsb2NhdGVkIGluIGEgRGF0YSBDZW50ZXIuIA0KDQpUaGVyZWZvcmUsIEkgc3VnZ2VzdCB0aGF0 IHlvdSByZXBsYWNlIFNlY3Rpb24gMyB3aXRoIGZvbGxvd2luZzoNCg0KMy4gU3VtbWFyeSBvZiBM b2FkIEJhbGFuY2luZyBUZWNobmlxdWVzOg0KDQpUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgdHlw ZXMgb2YgTG9hZCBCYWxhbmNpbmcgaW4gbmV0d29ya3MuIFRoZXJlIGlzIEROUyBiYXNlZCBnbG9i YWwgTEIsIHR5cGljYWxseSBwbGFjZWQgY2xvc2VyIHRvIGNsaWVudHMsIHRoZXJlIGFyZSBhbHNv IExCIGZvciBhIGNsdXN0ZXIgb2Ygc2VydmVycyB3aG8gc2hhcmUgc2FtZSBJUCBhZGRyZXNzIGFz IHRoZSBMQiwgdGhlcmUgYXJlIG90aGVyIExCLiANCg0KDQpUaGlzIGRyYWZ0IGlzIHRvIGRlc2Ny aWJlIGhvdyBmbG93IGxhYmVsIGNhbiBmdXJ0aGVyIG9wdGltaXplIGxvYWQgYmFsYW5jZXIgaW4g ZnJvbnQgb2YgYSBjbHVzdGVyIG9mIHNlcnZlcnMuIA0KDQpIaWdobGlnaHQgb2YgTG9hZCBCYWxh bmNpbmcgQWxnb3JpdGhtczoNCg0KVHlwaWNhbCBpbmR1c3RyeSBzdGFuZGFyZCBsb2FkIGJhbGFu Y2luZyBhbGdvcml0aG1zIGF2YWlsYWJsZSB0b2RheSBpbmNsdWRlOg0KDQpSb3VuZCBSb2JpbiAN CkxlYXN0IENvbm5lY3Rpb25zIA0KRmFzdGVzdCBSZXNwb25zZSBUaW1lIA0KV2VpZ2h0ZWQgUm91 bmQgUm9iaW4gDQpXZWlnaHRlZCBMZWFzdCBDb25uZWN0aW9ucyANCkN1c3RvbSB2YWx1ZXMgYXNz aWduZWQgdG8gaW5kaXZpZHVhbCBzZXJ2ZXJzIGluIGEgcG9vbCBiYXNlZCBvbiBTTk1QIG9yIG90 aGVyIGNvbW11bmljYXRpb24gbWVjaGFuaXNtDQoNCjQuIEFuIGltcHJvdmVkIExvYWQgQmFsYW5j aW5nIEFsZ29yaXRobXMgdXNpbmcgRmxvdyBMYWJlbA0KKHlvdSBjYW4gZGVzY3JpYmUgaG93IEZs b3cgTGFiZWwgaW1wcm92ZSB0aGUgTEIgYWxnb3JpdGhtcyBjdXJyZW50bHkgYmVpbmcgZGVwbG95 ZWQiKS4gDQoNCkxpbmRhICAgDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBTaGVuZyBKaWFuZw0KPiBTZW50OiBNb25kYXksIEFwcmlsIDAxLCAyMDEzIDk6MDQgUE0N Cj4gVG86IExpbmRhIER1bmJhcg0KPiBTdWJqZWN0OiBSRTogUmV2aWV3aW5nIG9mIGZsb3cgbGFi ZWwgYmFsYW5jaW5nDQo+IA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWludGFyZWEtZmxvdy1sYWJlbC1iYWxhbmNpbmctMDANCj4gDQo+IE1hbnkgdGhhbmssDQo+IA0K PiBTaGVuZw0KPiANCj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID5Gcm9tOiBMaW5k YSBEdW5iYXINCj4gPlNlbnQ6IE1vbmRheSwgQXByaWwgMDEsIDIwMTMgMTA6MTQgUE0NCj4gPlRv OiBTaGVuZyBKaWFuZw0KPiA+U3ViamVjdDogUkU6IFJldmlld2luZyBvZiBmbG93IGxhYmVsIGJh bGFuY2luZw0KPiA+DQo+ID5TaGVuZywNCj4gPg0KPiA+U29ycnkgZm9yIHNsaXBwaW5nIHRocm91 Z2ggbXkgbWluZC4NCj4gPkNhbiB5b3Ugc2VuZCBtZSB0aGUgbGluaz8NCj4gPg0KPiA+TGluZGEN Cj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBTaGVuZyBK aWFuZw0KPiA+PiBTZW50OiBNb25kYXksIEFwcmlsIDAxLCAyMDEzIDI6MDIgQU0NCj4gPj4gVG86 IExpbmRhIER1bmJhcg0KPiA+PiBDYzogQnJpYW4gRSBDYXJwZW50ZXI7IFN1cmVzaCBLcmlzaG5h bg0KPiA+PiBTdWJqZWN0OiBSZXZpZXdpbmcgb2YgZmxvdyBsYWJlbCBiYWxhbmNpbmcNCj4gPj4N Cj4gPj4gSGksIExpbmRhLA0KPiA+Pg0KPiA+PiBZb3Ugdm9sdW50ZWVyZWQgdG8gcmV2aWV3IG91 ciBmbG93IGxhYmVsIGJhbGFuY2luZyBkb2N1bWVudCBkdXJpbmcNCj4gdGhlDQo+ID4+IEludEFy ZWEgbWVldGluZyBpbiBPcmxhbmRvLiBDb3VsZCB5b3UgcGxlYXNlIGNvbmZpcm0gd2hlbiB3ZSBj YW4gZ2V0DQo+ID4+IHlvdXIgZmVlZGJhY2s/DQo+ID4+DQo+ID4+IE1hbnkgdGhhbmtzIGFuZCBi ZXN0IHJlZ2FyZHMsDQo+ID4+DQo+ID4+IFNoZW5nDQo= From brian.e.carpenter@gmail.com Sat Apr 6 00:13:37 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D776621F93F7 for ; Sat, 6 Apr 2013 00:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.921 X-Spam-Level: X-Spam-Status: No, score=-98.921 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THKXwI+TRFp5 for ; Sat, 6 Apr 2013 00:13:37 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id B247921F8EED for ; Sat, 6 Apr 2013 00:13:36 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so1201248wib.9 for ; Sat, 06 Apr 2013 00:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nPwimOrom5EIyZXAgPQjrhKwbEhlk+hFIk0EbxPj5/A=; b=LxoeZCXqrHPFtLDOPO0ydfI3OEkgl2tzPPQXcLVAm1LYz1DB3jVE2TfWXlo03QD9Do lyWpRuOifY3tmFOzuIM0tuKOzk2INhQUDzfKnrJtSMHnX9tB86r6ARt6gcVDUOAFIaZ6 K7Du4mZg+0ZL3E27pEoNRRfmqFCL4TevBKx7q7raTQsrK+M57k82xVxTkud6QQ16Gxpl zEKcDzvFQFFFL0gaBGbMT+Mile/veRoYhgbv82N7HkuLTQpoe5H+u8+W+PaguDR+5Pkb 7ZaC4TsEVUeBukp6F47SbavWfcXdOUk5DawLIsAo6UrM9xLwateWkgOz3UnbhtVoZU3a Asiw== X-Received: by 10.194.235.196 with SMTP id uo4mr20950361wjc.30.1365232415702; Sat, 06 Apr 2013 00:13:35 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-39.as13285.net. [2.101.189.39]) by mx.google.com with ESMTPS id g4sm8522706wib.11.2013.04.06.00.13.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Apr 2013 00:13:34 -0700 (PDT) Message-ID: <515FCB2B.5090001@gmail.com> Date: Sat, 06 Apr 2013 08:13:47 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Linda Dunbar References: <5D36713D8A4E7348A7E10DF7437A4B923AA09E53@nkgeml512-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645AF4AB9@dfweml509-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AA0AEE6@nkgeml512-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645AF9B86@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645AF9B86@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Willy Tarreau , "int-area@ietf.org" , Sheng Jiang Subject: Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 07:13:38 -0000 Linda, Thanks for the review. Some comments in line. I have added our co-author in cc because I'm not sure whether he's on the list. On 05/04/2013 21:53, Linda Dunbar wrote: > Sheng, Brian, el at: > > I reviewed draft-ietf-intarea-flow-label-balancing-00 > > Here are my comments: ------------------------------------- > > > The draft is to suggest using IPv6 header's flow label field > to identify different flows from IPv6 hosts. The draft tries > to emphasize that the flow label can help devices along the > way between Source & destination to achieve better flow > separation or finer tuned traffic balancing if there are > multiple paths. > > However, the Section 3 devotes so much to various LB schemes. > But many are irrelevant. There are many different types of > Load Balance, True, but as far as I can tell this topic is quite badly known in the IETF and it's useful to give an overview for people. > the DNS based load balancing, which is often > called global LB, has nothing to do with LB in front of a > cluster of servers. It can be used to select members of a single cluster, in fact I remember that technique being used in the very early days of cluster computing. I agree that today it's normally used for wide area LB, so we can clarify that in the text. > > Some description about LB in Section 3 is not quite to the > point. For example, the second bullet you stated: "Another > method, for HTTP servers, is to operate a layer 7 reverse > proxy in front of the server farm." The LB in front of a > cluster of servers is orthogonal to DNS based global LB. Yes, maybe the text needs to be broken up into separate paragraphs. > Your draft didn't even mention "Direct Server Return (DSR)" > LB scheme which is used heavily in DC to balance load among a > cluster of servers. In this scheme, all the servers in a > cluster share a common IP address which is same as the LB, or > use floating IP address for hosts. We didn't think this was relevant because it is part of the magic *behind* the load balancing point (i.e. the flow label has already been analysed before sending the packet on to the individual server). We can certainly explain that point. Similarly we didn't think that the actual LB algorithm (round robin etc.) was relevant. > > The figure in Page 7 is has some errors too. The DNS based > Load Balancing is usually in the Access network. See above - we are not talking about DNS for wide-area LB, but for flipping the address within one site. > (I really > think this figure is not necessary because it doesn't help > the draft at all). See above - we think it helps people who are new to the topic. > > The LB for Server Cluster is more likely located in a Data > Center. More likely than what? We don't say anything about where the server cluster lives. Regards Brian > > Therefore, I suggest that you replace Section 3 with > following: > > 3. Summary of Load Balancing Techniques: > > There are many different types of Load Balancing in networks. > There is DNS based global LB, typically placed closer to > clients, there are also LB for a cluster of servers who share > same IP address as the LB, there are other LB. > > > This draft is to describe how flow label can further optimize > load balancer in front of a cluster of servers. > > Highlight of Load Balancing Algorithms: > > Typical industry standard load balancing algorithms available > today include: > > Round Robin Least Connections Fastest Response Time Weighted > Round Robin Weighted Least Connections Custom values assigned > to individual servers in a pool based on SNMP or other > communication mechanism > > 4. An improved Load Balancing Algorithms using Flow Label > (you can describe how Flow Label improve the LB algorithms > currently being deployed"). > > Linda > > >> -----Original Message----- From: Sheng Jiang Sent: Monday, >> April 01, 2013 9:04 PM To: Linda Dunbar Subject: RE: >> Reviewing of flow label balancing >> >> http://tools.ietf.org/html/draft-ietf-intarea-flow-label-balancing-00 >> >> >> Many thank, >> >> Sheng >> >>> -----Original Message----- From: Linda Dunbar Sent: >>> Monday, April 01, 2013 10:14 PM To: Sheng Jiang Subject: >>> RE: Reviewing of flow label balancing >>> >>> Sheng, >>> >>> Sorry for slipping through my mind. Can you send me the >>> link? >>> >>> Linda >>> >>>> -----Original Message----- From: Sheng Jiang Sent: >>>> Monday, April 01, 2013 2:02 AM To: Linda Dunbar Cc: >>>> Brian E Carpenter; Suresh Krishnan Subject: Reviewing >>>> of flow label balancing >>>> >>>> Hi, Linda, >>>> >>>> You volunteered to review our flow label balancing >>>> document during >> the >>>> IntArea meeting in Orlando. Could you please confirm >>>> when we can get your feedback? >>>> >>>> Many thanks and best regards, >>>> >>>> Sheng From internet-drafts@ietf.org Wed Apr 10 01:58:07 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0DF21F9003; Wed, 10 Apr 2013 01:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIqCQTeQUf7T; Wed, 10 Apr 2013 01:58:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB2321F8FA5; Wed, 10 Apr 2013 01:58:06 -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.43.p4 Message-ID: <20130410085806.23409.86357.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 01:58:06 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 08:58:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group= of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identif= ier (HOST_ID) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-07.txt Pages : 22 Date : 2013-04-10 Abstract: This document is a collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Wed Apr 10 04:20:17 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D8421F93AB for ; Wed, 10 Apr 2013 04:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc6w8USjoE8F for ; Wed, 10 Apr 2013 04:20:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9891A21F93AA for ; Wed, 10 Apr 2013 04:20:13 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 8A78B3B487C for ; Wed, 10 Apr 2013 13:20:12 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6DD734C015 for ; Wed, 10 Apr 2013 13:20:12 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 10 Apr 2013 13:20:12 +0200 From: To: "int-area@ietf.org" Date: Wed, 10 Apr 2013 13:20:11 +0200 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-07.txt Thread-Index: Ac41yYiY51GJVHIuQvuc36A9TDzA8gAEsa4Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EC1AE7AD1@PUEXCB1B.nanterre.francetelecom.fr> References: <20130410085806.23409.86357.idtracker@ietfa.amsl.com> In-Reply-To: <20130410085806.23409.86357.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.10.94528 Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:20:17 -0000 Dear all, This version integrates the first set of comments received during the IESG = review. The main changes are: * Add a sentence to clarify why no recommendation is included * Add a sentence to clarify a host can be any computer located behind a CPE= or directly connected to an address-sharing function * Remove Section 1.1 and dispatch the bullets in the core text of Section 3 * Add a sentence to the privacy section to say an address-sharing function = can be configured with different end-users policies * Clarify what is meant by "encrypted traffic" in Table 1 * Add a sentence to the privacy section to request specification document t= o check whether location information may/may not be exposed using HOST_ID s= olutions * Add a new items for the TCP option to mention it may interfere with the u= se of Fast Open extension * Add some pointers to behave documents. * Other minor edits. Cheers, Med >-----Message d'origine----- >De=A0: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] De la >part de internet-drafts@ietf.org >Envoy=E9=A0: mercredi 10 avril 2013 10:58 >=C0=A0: i-d-announce@ietf.org >Cc=A0: int-area@ietf.org >Objet=A0: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis- >07.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Internet Area Working Group Working Grou= p >of the IETF. > > Title : Analysis of Solution Candidates to Reveal a Host >Identifier (HOST_ID) in Shared Address Deployments > Author(s) : Mohamed Boucadair > Joe Touch > Pierre Levis > Reinaldo Penno > Filename : draft-ietf-intarea-nat-reveal-analysis-07.txt > Pages : 22 > Date : 2013-04-10 > >Abstract: > This document is a collection of solutions to reveal a host > identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or > application proxies are involved in the path. This host identifier > could be used by a remote server to sort out the packets by sending > host. The host identifier must be unique to each host under the same > shared IP address. > > This document analyzes a set of solution candidates to reveal a host > identifier; no recommendation is sketched in the document. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-= 07 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From mohamed.boucadair@orange.com Thu Apr 11 01:05:59 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE3A21F8EE8 for ; Thu, 11 Apr 2013 01:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltjUiflxYNBW for ; Thu, 11 Apr 2013 01:05:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 882B921F8EB3 for ; Thu, 11 Apr 2013 01:05:58 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4E2DF3B48A4 for ; Thu, 11 Apr 2013 10:05:57 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 319B423809E for ; Thu, 11 Apr 2013 10:05:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 11 Apr 2013 10:05:53 +0200 From: To: Internet Area Date: Thu, 11 Apr 2013 10:05:46 +0200 Thread-Topic: [Int-area] IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile) Thread-Index: Ac42i15oPQuMEMooTFCk83TaffhfiQ== Message-ID: <94C682931C08B048B7A8645303FDC9F36EC1AE7E30@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.11.61520 Subject: Re: [Int-area] IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 08:05:59 -0000 Dear all, We edited an I-D which proposes a global framework making use of the Connec= tivity Provisioning Profile. The document is available here: http://tools.ietf.org/html/draft-sin-sdnrg-sdn-approach-02=20 I'm sharing this information as it may be of interest of this working group= . Comments are more than welcome on both I-Ds. Cheers, Med > >On 10/12/2012 05:20 AM, mohamed.boucadair@orange.com wrote: >> Dear all, >>=20 >> We submitted this new I-D which may be of interest of this WG.=20 >>=20 >> This is an effort trying to capture and expose the IP=20 >connectivity service provided by the network layer to upper=20 >services, to adjacent networks, offered/delivered to=20 >customers, etc. The document focuses on the definition of the=20 >CPP itself and does not discuss for instance how this is=20 >translated into configuration data/policies to be enforced in=20 >underlying nodes. >>=20 >> Abstract: >> This document describes the Connectivity Provisioning=20 >Profile (CPP) >> and proposes a CPP Template to capture IP connectivity=20 >requirements >> to be met in the context of delivery of services (e.g. =20 >Voice over IP >> or IP TV) which are to be plugged upon an IP/MPLS infrastructure. >> The CPP defines the set of IP transfer parameters to be=20 >supported by >> the underlying IP/MPLS transport network together with a=20 >reachability >> scope and bandwidth/capacity needs. Appropriate=20 >performance metrics >> such as one-way delay, one-way delay variation are used to >> characterize an IP transfer service. Both global and restricted >> reachability scopes can be captured in the CPP. >>=20 >> Having the generic CPP template allows for (1) automating=20 >the process >> of service negotiation and activation, thus accelerating service >> provisioning, (2) setting the (traffic) objectives of Traffic >> Engineering functions and service management functions and (3) >> enriching service and network management systems with 'decision- >> making' capabilities based on negotiated/offered CPPs. >>=20 >>=20 >https://datatracker.ietf.org/doc/draft-boucadair-connectivity-p >rovisioning-profile >>=20 >http://tools.ietf.org/html/draft-boucadair-connectivity-provisi >oning-profile-02 >>=20 >>=20 >> Comments are welcome. >>=20 >> Cheers, >> Med From internet-drafts@ietf.org Thu Apr 11 07:11:04 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D3221F8D14; Thu, 11 Apr 2013 07:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r950wgv7c9zO; Thu, 11 Apr 2013 07:11:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BBC21F8D31; Thu, 11 Apr 2013 07:11:02 -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.43.p4 Message-ID: <20130411141102.30774.61002.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2013 07:11:02 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-08.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:11:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group= of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identif= ier (HOST_IDENT) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-08.txt Pages : 23 Date : 2013-04-11 Abstract: This document is a collection of solutions to reveal a host identifier (denoted as HOST_IDENT) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Thu Apr 11 07:30:24 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7978421F87B7 for ; Thu, 11 Apr 2013 07:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdCw9m6kc7uw for ; Thu, 11 Apr 2013 07:30:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55321F8BE2 for ; Thu, 11 Apr 2013 07:30:22 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 802CD2DC2F0 for ; Thu, 11 Apr 2013 16:30:20 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 360C135C048 for ; Thu, 11 Apr 2013 16:30:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 11 Apr 2013 16:30:20 +0200 From: To: "int-area@ietf.org" Date: Thu, 11 Apr 2013 16:30:18 +0200 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-08.txt Thread-Index: Ac42vm4xKDWAAvzLSz+XKBFJOqa3dwAAWgjw Message-ID: <94C682931C08B048B7A8645303FDC9F36EC1AE80F4@PUEXCB1B.nanterre.francetelecom.fr> References: <20130411141102.30774.61002.idtracker@ietfa.amsl.com> In-Reply-To: <20130411141102.30774.61002.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-08.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:30:24 -0000 Dear all, This version integrates a second set of comments received during the IESG r= eview. The main changes are as follows: * Clarify the use of HOST_ID common to all interfaces is out of scope * Provide more explanation for the Proxy case * Record two additional limitations for the IP Option case * Add a new bullet to record the encountered issue when the tcp options spa= ce is exhausted * Rename HOST_ID to HOST_IDENT as HOST-ID is confusing for OPS (it is used = to bind a license). Cheers, Med >-----Message d'origine----- >De=A0: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] De la >part de internet-drafts@ietf.org >Envoy=E9=A0: jeudi 11 avril 2013 16:11 >=C0=A0: i-d-announce@ietf.org >Cc=A0: int-area@ietf.org >Objet=A0: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis- >08.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Internet Area Working Group Working Grou= p >of the IETF. > > Title : Analysis of Solution Candidates to Reveal a Host >Identifier (HOST_IDENT) in Shared Address Deployments > Author(s) : Mohamed Boucadair > Joe Touch > Pierre Levis > Reinaldo Penno > Filename : draft-ietf-intarea-nat-reveal-analysis-08.txt > Pages : 23 > Date : 2013-04-11 > >Abstract: > This document is a collection of solutions to reveal a host > identifier (denoted as HOST_IDENT) when a Carrier Grade NAT (CGN) or > application proxies are involved in the path. This host identifier > could be used by a remote server to sort out the packets by sending > host. The host identifier must be unique to each host under the same > shared IP address. > > This document analyzes a set of solution candidates to reveal a host > identifier; no recommendation is sketched in the document. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-= 08 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From internet-drafts@ietf.org Mon Apr 15 22:43:03 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB0D21F9027; Mon, 15 Apr 2013 22:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l3qW-A7kTz4; Mon, 15 Apr 2013 22:43:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE1121F93E2; Mon, 15 Apr 2013 22:42:57 -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.43.p4 Message-ID: <20130416054256.22902.78357.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 22:42:56 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-09.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 05:43:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group= of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identif= ier (HOST_ID) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-09.txt Pages : 23 Date : 2013-04-15 Abstract: This document is a collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d3e3e3@gmail.com Tue Apr 16 23:08:55 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB88B21F97CD for ; Tue, 16 Apr 2013 23:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEhyRjunoQVk for ; Tue, 16 Apr 2013 23:08:55 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 31ACA21F97C5 for ; Tue, 16 Apr 2013 23:08:55 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id va7so1140176obc.34 for ; Tue, 16 Apr 2013 23:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=j8JjqL8zQLNpg+AOlFclmJTu0D+b0Fx6IhGJlLVpKFM=; b=OtlufmNOvhGB1MjLmtTVs31DTh71CgTgLqD5+qdYtq5Si2hjM81ad6d6Z5C4N7tpns /0vW8Nt3VMakdsdaWE2jxx2j9t1MIrjKc4seN3Qn+/PSMzgUnsppTi8eDoiWuHrS0YAJ Bz8cjFCeORM3l+SkFjYDoA3Zjo11E4GZYrliPuwLCvBM+ztRtilYfpq6iL45PHkWVc+7 QFjBP14BHF1pXDxVqtbsWzLoc06iOGFkXmbvD1Uhnf32fjnNO2Tvh724vMOp/2i1W1jA e2LfI3MxQ8YesBLmoq6HdhZk8Cjb8kC00SlafmpyTowa0QJTGpkE/bdPiDlgsSU3spla dp8A== X-Received: by 10.182.106.16 with SMTP id gq16mr1957032obb.27.1366178934692; Tue, 16 Apr 2013 23:08:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.10.8 with HTTP; Tue, 16 Apr 2013 23:08:34 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AA19E2E@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AA19E2E@nkgeml512-mbx.china.huawei.com> From: Donald Eastlake Date: Wed, 17 Apr 2013 02:08:34 -0400 Message-ID: To: Sheng Jiang Content-Type: text/plain; charset=ISO-8859-1 Cc: Internet Area Subject: Re: [Int-area] Reviewing of flow label balancing X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 06:08:56 -0000 Hi, I think the draft is a good documentation of the issues and the benefits of using the IPv6 flow ID with load balancing. It would be more consistent with the completeness of the rest of the document to have a more complete list of typical load balancer server selection algorithms in the last paragraph of Section 5. There are people who believe that Informational documents can't have normative references. I am generally inclined that way myself. Various descriptions in the draft, like "statistically rare" could be made a bit more quantitative. I'm not saying a detailed numeric analysis is needed but a rough number based on reasonable simplifying assumptions might help to make things a little less fuzzy. Those are all my comments. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Apr 16, 2013 at 2:57 AM, Sheng Jiang wrote: > Hi, dear Donald, > > You agreed to review our flow label balancing document during the IntArea meeting in Orlando. The blow is the link for our document. Could you please review it and give your comments? > > http://tools.ietf.org/html/draft-ietf-intarea-flow-label-balancing-00 > > Many thanks and best regards, > > Sheng From brian.e.carpenter@gmail.com Tue Apr 16 23:37:15 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CEE21F9777 for ; Tue, 16 Apr 2013 23:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2b5TfQk60Qh for ; Tue, 16 Apr 2013 23:37:15 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id E44D021F9743 for ; Tue, 16 Apr 2013 23:37:14 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hq17so1193917wib.17 for ; Tue, 16 Apr 2013 23:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mqokimQ5JdgMyjD+BEuNZKfGb6Uy3HhyXXcnZGq7B+o=; b=jiA8EshvVTVDvmfTFyAEGxSdcmlXBwiCjefY2tPmWBrw1UfQMYYshRL6J+V//Y3BFm 7dFO1+PBR0lX3cJF6OwsGESIU5+TD8jwz6dYIQnO3AzJa6DUzO4CixKsRDAwaDRIw6G8 B0G7ABYafiysOdGNMv4s1A/Pq/rxr98AVG++7n4T6L9qJqv5BX6R91fCATxYy4hXqVkF 7caxvDr4b91cFDJ9byZRJGCwXUW3KMnslQ7SAUxqcUgifxXf0sTXu8nHL1u2LfIpdeya mj/qtVmdoK8EKjc7tP/DQq1eOovzLXyRttvw9yuv/Oi3rG4FNnQtr3jevIWbg1zDOEIG 6Rug== X-Received: by 10.194.158.42 with SMTP id wr10mr8743801wjb.23.1366180634127; Tue, 16 Apr 2013 23:37:14 -0700 (PDT) Received: from [10.3.2.18] (a2.norwich.yourspac.nsdsl.net. [94.229.131.97]) by mx.google.com with ESMTPS id j4sm23433523wiz.10.2013.04.16.23.37.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 23:37:12 -0700 (PDT) Message-ID: <516E431C.1040303@gmail.com> Date: Wed, 17 Apr 2013 07:37:16 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Donald Eastlake References: <5D36713D8A4E7348A7E10DF7437A4B923AA19E2E@nkgeml512-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Internet Area , Sheng Jiang Subject: Re: [Int-area] Reviewing of flow label balancing X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 06:37:15 -0000 Hi Donald, Thanks for the review. A few comments below... On 17/04/2013 07:08, Donald Eastlake wrote: > Hi, > > I think the draft is a good documentation of the issues and the > benefits of using the IPv6 flow ID with load balancing. > > It would be more consistent with the completeness of the rest of the > document to have a more complete list of typical load balancer server > selection algorithms in the last paragraph of Section 5. That is not really "on the wire" stuff though - isn't it sufficient to indicate that there are multiple methods? > There are people who believe that Informational documents can't have > normative references. I am generally inclined that way myself. There doesn't seem to be a rule about that. Coincidentally, I'm in the middle of an argument about that over on apps-discuss, where we've been asked to promote some Informational documents to normative references in an Informational RFC. I think that's silly. I'd be happy to drop the distinction here. > Various descriptions in the draft, like "statistically rare" could be > made a bit more quantitative. I'm not saying a detailed numeric > analysis is needed but a rough number based on reasonable simplifying > assumptions might help to make things a little less fuzzy. Yes, that is worth some thought. At least for flow label collisions, it's discussed in the flow label spec (hence our conversation some time ago about hash algorithms and FNV). We may be able to cover this by reference. Regards, Brian > > Those are all my comments. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Tue, Apr 16, 2013 at 2:57 AM, Sheng Jiang wrote: >> Hi, dear Donald, >> >> You agreed to review our flow label balancing document during the IntArea meeting in Orlando. The blow is the link for our document. Could you please review it and give your comments? >> >> http://tools.ietf.org/html/draft-ietf-intarea-flow-label-balancing-00 >> >> Many thanks and best regards, >> >> Sheng > From olivier.bonaventure@uclouvain.be Wed Apr 17 04:27:53 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27D021F8700 for ; Wed, 17 Apr 2013 04:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwOG+eGSkvFq for ; Wed, 17 Apr 2013 04:27:53 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id F159621F86F4 for ; Wed, 17 Apr 2013 04:27:52 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 938E311FA04 for ; Wed, 17 Apr 2013 13:27:45 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 938E311FA04 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1366198065; bh=7IUoCL/xKxXylHREh8J5n5Iu5TmbNQpAGWhcwMhbIdU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; b=gD1CPD/M46XJU7BhD3nR4fmvm4mk/e/Uguy+VvzRqcziTa7pb7QY23ppNPbKHEKIw p9/EqQ2AOnD05tQOxpvzlofKmS2AGNfpSE8w4wOI22xNGvt7gbHTQg7bycsC8rt6Ol Lve62QMI35p1iiQIqHZTuqnikoZkfoqCMOTixlgI= Message-ID: <516E874B.3060303@uclouvain.be> Date: Wed, 17 Apr 2013 13:28:11 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Internet Area Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 938E311FA04.A2BD4 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:27:53 -0000 Hello, Here are some additional comments on the above draft. Section 4 suggests the utilisation of a hash to perform the load balancing based on the source-address/flow label pair. Hash functions are often used in load balancing applications. I think that it could be useful to point the advantages and the drawbacks of using hash functions for load balancing purposes. The main advantage of hash functions is that they usually exhibit the avalanche effect, i.e. a small change in the input causes a large change in the output of the function. Simulations show that this effect is important to correctly balance real traffic. However, with hash functions, this advantage comes with a drawback. It is difficult to predict the set of inputs that would provide a specific output. Being able to predict which decision will be taken by a load balancer is important for monitoring applications for example. If a network operator wants to verify the round-trip-time between two hosts when there is a load balancer in between, he/she should take into account this load balancing when defining his/her probes. A similar situation happens when a network operator wants to use traceroute to detect block holes on a load-balanced path. It should be noted that there exist functions that exhibit the avalanche effect without being one-way functions like the classical hash functions. If used in load-balancers, these functions would provide both good load balancing and predictibility which is desired for many monitoring applications. A recent paper shows how such load-balancing can be performed efficiently by using block ciphers instead of hash functions. The solution proposed in this paper could be adapted to utilise the IPv6 flow label : http://inl.info.ucl.ac.be/publications/revisiting-flow-based-load-balancing-stateless-path-selection-data-center-networks Best regards, Olivier Bonaventure -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From brian.e.carpenter@gmail.com Wed Apr 17 06:43:55 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91EC21F86D2 for ; Wed, 17 Apr 2013 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81pM9tNt5flm for ; Wed, 17 Apr 2013 06:43:55 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id D891521F86CB for ; Wed, 17 Apr 2013 06:43:53 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so1586629wgh.34 for ; Wed, 17 Apr 2013 06:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iyKrVQzFgQlFbO7ubbEICbifZxWMP3cWIL806CacD5M=; b=bJHtXEl/pVvax+7aUqsgjarXtbJV/q6JHEet0ry8utZKNqObkCox92ftp/YChDFPFv q404XHaPkkTVXJ47a0m8uPSVB2wmRNZXIwFaWciMNaT0hA2usegJ8rCAOOtarfp5Q3dw NY0buCTIbTnoS3GhguGdt0N+EZsAKIPeeKHjk0jf660irVMFdr+l/XDUNTf3fPFTTCXE Z3wCP0Pdz4Ges5TOGw8Bc+YKVE29W8TlbAAFvT1RF+GAQBsdJgfvdgYJdAZZZSsYrJWe r1HridFSuhkQxK8ywLSIjDnI/5eQkLRewlFdKvPJdNEGod3d1EtrLE2PvaXV2ZLS7ZQl PX/w== X-Received: by 10.180.39.207 with SMTP id r15mr11210226wik.16.1366206232347; Wed, 17 Apr 2013 06:43:52 -0700 (PDT) Received: from [10.3.2.18] (a2.norwich.yourspac.nsdsl.net. [94.229.131.97]) by mx.google.com with ESMTPS id j4sm25605922wiz.10.2013.04.17.06.43.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 06:43:51 -0700 (PDT) Message-ID: <516EA71A.8060301@gmail.com> Date: Wed, 17 Apr 2013 14:43:54 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be References: <516E874B.3060303@uclouvain.be> In-Reply-To: <516E874B.3060303@uclouvain.be> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Internet Area Subject: Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:43:56 -0000 Hello Olivier, On 17/04/2013 12:28, Olivier Bonaventure wrote: > Hello, > > Here are some additional comments on the above draft. Section 4 suggests > the utilisation of a hash to perform the load balancing based on the > source-address/flow label pair. Hash functions are often used in load > balancing applications. I think that it could be useful to point the > advantages and the drawbacks of using hash functions for load balancing > purposes. > > The main advantage of hash functions is that they usually exhibit the > avalanche effect, i.e. a small change in the input causes a large change > in the output of the function. Simulations show that this effect is > important to correctly balance real traffic. > > However, with hash functions, this advantage comes with a drawback. It > is difficult to predict the set of inputs that would provide a specific > output. That is an advantage from the security point of view, since it prevents an attacker from biasing the load balancing in order to focus a DOS attack on a single server. I believe that's discussed in the flow label spec. > Being able to predict which decision will be taken by a load > balancer is important for monitoring applications for example. If a > network operator wants to verify the round-trip-time between two hosts > when there is a load balancer in between, he/she should take into > account this load balancing when defining his/her probes. A similar > situation happens when a network operator wants to use traceroute to > detect block holes on a load-balanced path. True, but there's likely to be little sympathy from the load balancer's operator, for the reason just given. > It should be noted that there exist functions that exhibit the avalanche > effect without being one-way functions like the classical hash > functions. If used in load-balancers, these functions would provide both > good load balancing and predictibility which is desired for many > monitoring applications. A recent paper shows how such load-balancing > can be performed efficiently by using block ciphers instead of hash > functions. The solution proposed in this paper could be adapted to > utilise the IPv6 flow label : > > http://inl.info.ucl.ac.be/publications/revisiting-flow-based-load-balancing-stateless-path-selection-data-center-networks We'll have a look, thanks for the reference. I believe, from the research I had to do personally when working on this draft, that there is scope for an RFC giving a general overview of load balancing. That would certainly have been a precious reference for the current draft. Regards Brian > > Best regards, > > > Olivier Bonaventure > From olivier.bonaventure@uclouvain.be Wed Apr 17 10:44:52 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405FD21F86FA for ; Wed, 17 Apr 2013 10:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRkZPLXL3FGu for ; Wed, 17 Apr 2013 10:44:51 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 367E021F860B for ; Wed, 17 Apr 2013 10:44:51 -0700 (PDT) Received: from mbpobo.local (unknown [78.129.84.108]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 269801C6BEF; Wed, 17 Apr 2013 19:44:44 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 269801C6BEF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1366220684; bh=FiE2LSKSU+kJE6BKmDWa6NA8osZQ9TrMvmLaCrnVF7k=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XKlGKAQtV9draCMBUdbpk6PJuyqP/ECd9j16VU7FbOZedomIaE6w3z9UxTtPlcd78 IUILn8/M6gVzJobYNFSzzdkpOeouw/+w+IIWhNjdqf0ttS4DNDKRhthiQyjRhu1vU8 FrzT4/SyKHRRVnSDUUaAfgSXNWloIIVlAkl6l7IM= Message-ID: <516EDFA6.2000005@uclouvain.be> Date: Wed, 17 Apr 2013 19:45:10 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brian E Carpenter References: <516E874B.3060303@uclouvain.be> <516EA71A.8060301@gmail.com> In-Reply-To: <516EA71A.8060301@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 269801C6BEF.A142C X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: Internet Area Subject: Re: [Int-area] Comments and suggestiosn to draft-ietf-intarea-flow-label-balancing-00 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 17:44:52 -0000 Brian, >> >> Here are some additional comments on the above draft. Section 4 suggests >> the utilisation of a hash to perform the load balancing based on the >> source-address/flow label pair. Hash functions are often used in load >> balancing applications. I think that it could be useful to point the >> advantages and the drawbacks of using hash functions for load balancing >> purposes. >> >> The main advantage of hash functions is that they usually exhibit the >> avalanche effect, i.e. a small change in the input causes a large change >> in the output of the function. Simulations show that this effect is >> important to correctly balance real traffic. >> >> However, with hash functions, this advantage comes with a drawback. It >> is difficult to predict the set of inputs that would provide a specific >> output. > > That is an advantage from the security point of view, since it > prevents an attacker from biasing the load balancing in order to > focus a DOS attack on a single server. I believe that's discussed > in the flow label spec. Well, partially. Since by design all packets with the same pair will always reach the same server, once you have found a victim server, you can send lots of packets to it. I agree that a DDoS from multiple sources could be a bit more difficult since the attacker would need to find the flow label for each source address to reach a given server. >> Being able to predict which decision will be taken by a load >> balancer is important for monitoring applications for example. If a >> network operator wants to verify the round-trip-time between two hosts >> when there is a load balancer in between, he/she should take into >> account this load balancing when defining his/her probes. A similar >> situation happens when a network operator wants to use traceroute to >> detect block holes on a load-balanced path. > > True, but there's likely to be little sympathy from the load balancer's > operator, for the reason just given. The block cipher algorithm that is described below uses a key. This key can be fixed by the operator. If the key is secret, then only the operator can send packets over specific parts. For attackers, the load-balancing function is similar to a non-invertible hash. This should answer some of your security concerns (at least it's not worst than hash-based load balancing) >> >> http://inl.info.ucl.ac.be/publications/revisiting-flow-based-load-balancing-stateless-path-selection-data-center-networks > > We'll have a look, thanks for the reference. > > I believe, from the research I had to do personally when working on > this draft, that there is scope for an RFC giving a general overview > of load balancing. That would certainly have been a precious reference > for the current draft. Yes and the interactions between load balancing and networking protocols is worth being discussed as well. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From internet-drafts@ietf.org Wed Apr 24 08:36:22 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0737A21F91C3; Wed, 24 Apr 2013 08:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3gB4QyQji11; Wed, 24 Apr 2013 08:36:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2730F21F92C4; Wed, 24 Apr 2013 08:36:20 -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.44.p4 Message-ID: <20130424153620.7532.56721.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 08:36:20 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-10.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 15:36:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group= of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identif= ier (HOST_ID) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-10.txt Pages : 23 Date : 2013-04-24 Abstract: This document is a collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johnsonhammond2@hushmail.com Sat Apr 27 09:50:15 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6FF21F9820 for ; Sat, 27 Apr 2013 09:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Rr+iT+0kfM for ; Sat, 27 Apr 2013 09:50:15 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id E299B21F9742 for ; Sat, 27 Apr 2013 09:50:14 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id BB0AD30583 for ; Sat, 27 Apr 2013 16:50:12 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 16:50:12 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 76B6314DBDE; Sat, 27 Apr 2013 16:50:12 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 12:50:12 -0400 To: int-area@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427165012.76B6314DBDE@smtp.hushmail.com> Subject: [Int-area] Biggest Fake Conference in Computer Science X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:22:13 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.