From giles.heron@gmail.com Fri Jun 1 02:03:54 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CFB21F8668 for ; Fri, 1 Jun 2012 02:03:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+-E1I6bCvGR for ; Fri, 1 Jun 2012 02:03:52 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63AA521F8644 for ; Fri, 1 Jun 2012 02:03:51 -0700 (PDT) Received: by eekd4 with SMTP id d4so860615eek.31 for ; Fri, 01 Jun 2012 02:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=3fd6JzcDMnvD7WXKyuBTKdQmUFejOxuiEl1fqsZLKjo=; b=PpgObICmVfH9HUNooBwSwq8m3fKR63dzxlHiIwvltlcyY7SoJyHRB+9pcuZ12qgUM5 8pVoGPYC4d0gpDM3AxsxlOYMZXbjKPU1IyiZb3l8gNvVjHEKOCpP8NIiuP9SjoG5O3d6 oILHqn+N9cNccipej8qyVAHihKAsiJDlnRfCPqXK9gMqu+u36ruaHEB6bxegVB/TVBJh S930pEecGP/N9IN0XuRxtxb6wFOREUh28Dr8UK5jrINPvzMJXdh/0SKJif4m17vO9mZi YSxNAhAQC89rhB3YoaAoSagtrQvGasZ56aTvNuqObVCgIBqzRYr3LwvAykXVohslgArp vLCw== Received: by 10.14.53.6 with SMTP id f6mr914120eec.214.1338541430465; Fri, 01 Jun 2012 02:03:50 -0700 (PDT) Received: from [10.61.100.185] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e45sm4579536eeb.6.2012.06.01.02.03.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 02:03:48 -0700 (PDT) User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Fri, 01 Jun 2012 10:03:39 +0100 Subject: Progressing E-Tree - IPR issues From: Giles Heron To: Message-ID: Thread-Topic: Progressing E-Tree - IPR issues Thread-Index: Ac0/1W81Ihu2DKA2C0ieX8h0maJzKg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 09:03:54 -0000 Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. It appears that some or all of the current E-Tree drafts may be encumbered by IPR. We'd like to ask the WG whether we should continue to progress these drafts, or whether we should attempt to pursue alternatives that aren't encumbered. Would those with opinions please respond to this question within the next 2 weeks (i.e. by Friday 15th of June). Thanks in advance. Giles From tnadeau@lucidvision.com Fri Jun 1 04:44:53 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1A821F8503 for ; Fri, 1 Jun 2012 04:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJe-z9FnxyF0 for ; Fri, 1 Jun 2012 04:44:52 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6E99621F8501 for ; Fri, 1 Jun 2012 04:44:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id E0BAD214882D; Fri, 1 Jun 2012 07:44:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InOQMC0G14x4; Fri, 1 Jun 2012 07:44:51 -0400 (EDT) Received: from sa-nc-ipg-172-23-0-29.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id EF523214882A; Fri, 1 Jun 2012 07:44:50 -0400 (EDT) Subject: Re: Progressing E-Tree - IPR issues Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: Date: Fri, 1 Jun 2012 07:44:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Giles Heron X-Mailer: Apple Mail (2.1278) Cc: l2vpn@ietf.org, Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 11:44:53 -0000 It would be good to understand how they are encumbered as we = weigh the options. --Tom On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: > Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. >=20 > It appears that some or all of the current E-Tree drafts may be = encumbered > by IPR. >=20 > We'd like to ask the WG whether we should continue to progress these = drafts, > or whether we should attempt to pursue alternatives that aren't = encumbered. >=20 > Would those with opinions please respond to this question within the = next 2 > weeks (i.e. by Friday 15th of June). >=20 > Thanks in advance. >=20 > Giles >=20 >=20 >=20 From stbryant@cisco.com Fri Jun 1 05:05:01 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B3121F87A5 for ; Fri, 1 Jun 2012 05:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.46 X-Spam-Level: X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 fR2nRGPuObHF for ; Fri, 1 Jun 2012 05:05:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2462C21F87B1 for ; Fri, 1 Jun 2012 05:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=929; q=dns/txt; s=iport; t=1338552301; x=1339761901; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=53fB8IdKJh1jAA8KNg96teRrL+e3W8C7Jcrb62Uw+oA=; b=AoTFv1wxdPgFcSrYpoHO2KSSHddO6ZD4S8xMV3oaPOa7M/IWz0N6rK7y YkWRdZ/PIQ2XUSbvKP+oFonpZIzuiL4zskHUcIg94V6rBX5/xraiuz+XK ALfdGgV8ZTJMXSSR53z5UwfFWugK+qjmfJmTq2oAaRPEkZPO0/QKCLsUA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAISvyE+Q/khN/2dsb2JhbABEtDWBB4IYAQEBBBIBAiNAEQsYCRYPCQMCAQIBRRMIAQEeh2kLmCGDRxCcG4sPgl+DFgOVGY4PgQRigmE X-IronPort-AV: E=Sophos;i="4.75,698,1330905600"; d="scan'208";a="138965496" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Jun 2012 12:04:56 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q51C4t19026933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jun 2012 12:04:56 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q51C4lxJ014404; Fri, 1 Jun 2012 13:04:47 +0100 (BST) Message-ID: <4FC8AFDE.9060003@cisco.com> Date: Fri, 01 Jun 2012 13:04:46 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: l2vpn@ietf.org Subject: Re: Progressing E-Tree - IPR issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 12:05:02 -0000 Tom That is something that you need to analyze and determine for yourself. Stewart On 01/06/2012 12:44, Thomas Nadeau wrote: > It would be good to understand how they are encumbered as we weigh the options. > > --Tom > > On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: > >> Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. >> >> It appears that some or all of the current E-Tree drafts may be encumbered >> by IPR. >> >> We'd like to ask the WG whether we should continue to progress these drafts, >> or whether we should attempt to pursue alternatives that aren't encumbered. >> >> Would those with opinions please respond to this question within the next 2 >> weeks (i.e. by Friday 15th of June). >> >> Thanks in advance. >> >> Giles >> >> >> > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jiangyuanlong@huawei.com Fri Jun 1 09:31:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57BD11E80B4 for ; Fri, 1 Jun 2012 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 ki-hhnNMWBGa for ; Fri, 1 Jun 2012 09:31:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B540A11E8074 for ; Fri, 1 Jun 2012 09:31:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGT72447; Fri, 01 Jun 2012 12:31:27 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 1 Jun 2012 09:28:45 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 1 Jun 2012 09:28:43 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Sat, 2 Jun 2012 00:28:41 +0800 From: Jiangyuanlong To: Giles Heron Subject: Re: Progressing E-Tree - IPR issues Thread-Topic: Progressing E-Tree - IPR issues Thread-Index: Ac1AEy5pjwxhZR1rS7+Nj/ukBh6XqA== Date: Fri, 1 Jun 2012 16:28:40 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4156D0@szxeml546-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D4156D0szxeml546mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "stbryant@cisco.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:31:28 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D4156D0szxeml546mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpOb3Qgc3VyZSB3aGV0aGVyIHRoZSByZXF1aXJlbWVudCBvZiByb3lhbHR5IGZy b20gc29tZSBJUFIgaXMgYW4gaXNzdWUsIGhvd2V2ZXIsIGlmIHRoZSBzYW1lIElQUiBjYW4gYmUg Y2xhaW1lZCBmb3IgNyBkaWZmZXJlbnQgRS1UcmVlIGRyYWZ0cywgZG9uJ3QgeW91IHRoaW5rIGl0 IGFsc28gcG9zc2libGUgdG8gYmUgY2xhaW1lZCBmb3IgdGhlIDh0aCBkcmFmdCAodGhhdCBpcywg ZXZlbiB3aGVuIHRoZSBXRyBoYXMgYW5vdGhlciBhbHRlcm5hdGl2ZSBkcmFmdCk/DQoNCkluIGZh Y3QsIHRoZSB1c2Ugb2YgZGlmZmVyZW50IFZMQU5zIHRvIGluZGljYXRlIEUtVHJlZSByb290L2xl YWYgYXR0cmlidXRlcyBhbmQgcHJvaGliaXRpbmcgbGVhZi10by1sZWFmIHRyYWZmaWMgd2l0aCB0 aGUgaGVscCBvZiBWTEFOcyB3YXMgZmlyc3Qgc3RhbmRhcmRpemVkIGluIElFRUUgODAyLjFRLTIw MDMsIHdlbGwgYWhlYWQgb2YgYW55IElQUiBjbGFpbWVkIGluIHRoaXMgV0csIGFuZCBJIGJlbGll dmUgbGFyZ2UgcG9ydGlvbnMgb2YgdGhlIFZMQU4tYmFzZWQgc29sdXRpb24gYXJlIG5vdCBjb3Zl cmVkIGJ5IGFueSBJUFIsIHNvIHdoeSBub3QgZGV2ZWxvcCB0aGUgRS1UcmVlIHNvbHV0aW9uIHdp dGggdGhpcyBhcyBhIGJhc2VsaW5lPyBBcyBjby1hdXRob3JzIG9mIHRoaXMgSS1ELCB3ZSBhcmUg b3BlbiB0byBhZGFwdCBhbnkgb2YgaXRzIGNvbnRlbnRzIG9uIFdHJ3MgY29uc2Vuc3VzLg0KDQoN Cg0KVGhhbmtzLA0KWXVhbmxvbmcNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KICAqICAgVG86IDxsMnZwbiBhdCBpZXRmLm9yZzxtYWlsdG86bDJ2cG5ARE9NQUlOLkhJRERF Tj4+DQogICogICBTdWJqZWN0OiBQcm9ncmVzc2luZyBFLVRyZWUgLSBJUFIgaXNzdWVzDQogICog ICBGcm9tOiBHaWxlcyBIZXJvbiA8Z2lsZXMuaGVyb24gYXQgZ21haWwuY29tPG1haWx0bzpnaWxl cy5oZXJvbkBET01BSU4uSElEREVOPj4NCiAgKiAgIERhdGU6IEZyaSwgMDEgSnVuIDIwMTIgMTA6 MDM6MzkgKzAxMDANCiAgKiAgIENjOiBTdGV3YXJ0IEJyeWFudCA8c3RicnlhbnQgYXQgY2lzY28u Y29tPG1haWx0bzpzdGJyeWFudEBET01BSU4uSElEREVOPj4NCiAgKiAgIERlbGl2ZXJlZC10bzog bDJ2cG4gYXQgaWV0ZmEuYW1zbC5jb208bWFpbHRvOmwydnBuQERPTUFJTi5ISURERU4+DQogICog ICBEa2ltLXNpZ25hdHVyZTogdj0xOyBhPXJzYS1zaGEyNTY7IGM9cmVsYXhlZC9yZWxheGVkOyBk PWdtYWlsLmNvbTsgcz0yMDEyMDExMzsgaD11c2VyLWFnZW50OmRhdGU6c3ViamVjdDpmcm9tOnRv OmNjOm1lc3NhZ2UtaWQ6dGhyZWFkLXRvcGljIDp0aHJlYWQtaW5kZXg6bWltZS12ZXJzaW9uOmNv bnRlbnQtdHlwZTpjb250ZW50LXRyYW5zZmVyLWVuY29kaW5nOyBiaD0zZmQ2SnpjRE1udkQ3V1hL eXVCVEtkUW1VRmVqT3h1aUVsMWZxc1pMS2pvPTsgYj1QcGdPYklDbVZmSDlIVU5vb0J3U3dxOG0z ZktSNjNkenhsSGlJd3ZsdGxjeVk3U29KeUhSQis5cGN1WjEycWdVTTUgOHBWb0dQWUM0ZDBncERN M0F4c3hsT1lNWlhiaktQVTFJeWlaYjNsOGdOdlZqSEVLT0NwUDhOSWl1UDlTam9HNU8zZDYgb0lM SHFuK045Y05jY2lwZWo4cXlWQUhpaEtBc2lKRGxuUmZDUHFYSzlnTXF1K3UzNnJ1YUhFQjZieGVn VkIvVFZCSmggUzkzMHBFZWNHUC9OOUlOMFh1Unh0eGI2d0ZPUkVVaDI4RHI4VUs1anJJTlB2ek1K WGRoLzBTS0ppZjRtMTd2TzltWmkgWVN4TkFoQVFDODlyaEIzWW9hQW9TYWd0clF2R2FzWjU2YVR2 TnVxT2JWQ2dJQnF6UllyM0x3dkF5a1hWb2hzbGdBcnAgdkxDdz09DQogICogICBMaXN0LWFyY2hp dmU6IDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbDJ2cG4+DQogICogICBM aXN0LWhlbHA6IDxtYWlsdG86bDJ2cG4tcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PWhlbHA+DQog ICogICBMaXN0LWlkOiA8bDJ2cG4uaWV0Zi5vcmc+DQogICogICBMaXN0LXBvc3Q6IDxtYWlsdG86 bDJ2cG5AaWV0Zi5vcmc+DQogICogICBMaXN0LXN1YnNjcmliZTogPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbDJ2cG4+LCA8bWFpbHRvOmwydnBuLXJlcXVlc3RAaWV0Zi5v cmc/c3ViamVjdD1zdWJzY3JpYmU+DQogICogICBMaXN0LXVuc3Vic2NyaWJlOiA8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9vcHRpb25zL2wydnBuPiwgPG1haWx0bzpsMnZwbi1yZXF1ZXN0 QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmU+DQogICogICBUaHJlYWQtaW5kZXg6IEFjMC8x VzgxSWh1MkRLQTJDMGllWDhoMG1hSnpLZz09DQogICogICBUaHJlYWQtdG9waWM6IFByb2dyZXNz aW5nIEUtVHJlZSAtIElQUiBpc3N1ZXMNCiAgKiAgIFVzZXItYWdlbnQ6IE1pY3Jvc29mdC1FbnRv dXJhZ2UvMTIuMzMuMC4xMjA0MTENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KTmFiaWwsIFN0ZXdhcnQgYW5kIEkgZGlzY3Vzc2VkIHRoZSBpc3N1ZSBvZiBJUFIgYW5kIEUt VHJlZSByZWNlbnRseS4NCg0KSXQgYXBwZWFycyB0aGF0IHNvbWUgb3IgYWxsIG9mIHRoZSBjdXJy ZW50IEUtVHJlZSBkcmFmdHMgbWF5IGJlIGVuY3VtYmVyZWQNCmJ5IElQUi4NCg0KV2UnZCBsaWtl IHRvIGFzayB0aGUgV0cgd2hldGhlciB3ZSBzaG91bGQgY29udGludWUgdG8gcHJvZ3Jlc3MgdGhl c2UgZHJhZnRzLA0Kb3Igd2hldGhlciB3ZSBzaG91bGQgYXR0ZW1wdCB0byBwdXJzdWUgYWx0ZXJu YXRpdmVzIHRoYXQgYXJlbid0IGVuY3VtYmVyZWQuDQoNCldvdWxkIHRob3NlIHdpdGggb3Bpbmlv bnMgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBxdWVzdGlvbiB3aXRoaW4gdGhlIG5leHQgMg0Kd2Vl a3MgKGkuZS4gYnkgRnJpZGF5IDE1dGggb2YgSnVuZSkuDQoNClRoYW5rcyBpbiBhZHZhbmNlLg0K DQpHaWxlcw0KDQoNCg== --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D4156D0szxeml546mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,


Not sure whether the requirement of royalty from some IPR is an issue, howe= ver, if the same IPR can be claimed for 7 different E-Tree drafts, don't yo= u think it also possible to be claimed for the 8th draft (that is, even whe= n the WG has another alternative draft)?


In fact, the use of different VLANs to indicate E-Tree root/leaf attributes= and prohibiting leaf-to-leaf traffic with the help of VLANs was first stan= dardized in IEEE 802.1Q-2003, well ahead of any IPR claimed in this WG, and= I believe large portions of the VLAN-based solution are not covered by any IPR, so why not develop th= e E-Tree solution with this as a baseline? As co-authors of this I-D, we ar= e open to adapt any of its contents on WG's consensus.

 

Thanks,
Yuanlong
 

------------------------------------------------------------------------= ---------------

Nabil, Stewart and I discussed the issue of IPR and E-Tree recently.

It appears that some or all of the current E-Tree drafts may be encumbered
by IPR.

We'd like to ask the WG whether we should continue to progress these drafts=
,
or whether we should attempt to pursue alternatives that aren't encumbered.

Would those with opinions please respond to this question within the next 2
weeks (i.e. by Friday 15th of June).

Thanks in advance.

Giles
--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B1D4156D0szxeml546mbschi_-- From davari@broadcom.com Fri Jun 1 14:23:01 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636BB21F889A for ; Fri, 1 Jun 2012 14:23:01 -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 oZDZk9BciOoi for ; Fri, 1 Jun 2012 14:23:00 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 296C221F8896 for ; Fri, 1 Jun 2012 14:22:59 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 01 Jun 2012 14:23:41 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCAS01.corp.ad.broadcom.com (10.16.192.31) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 1 Jun 2012 14:22:47 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by sjexchcas01.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 1 Jun 2012 14:22:47 -0700 From: "Shahram Davari" To: "Giles Heron" , "l2vpn@ietf.org" Subject: RE: Progressing E-Tree - IPR issues Thread-Topic: Progressing E-Tree - IPR issues Thread-Index: Ac0/1W81Ihu2DKA2C0ieX8h0maJzKgAZg7rQ Date: Fri, 1 Jun 2012 21:22:46 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2804165F@SJEXCHMB12.corp.ad.broadcom.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.16.65.113] MIME-Version: 1.0 X-WSS-ID: 63D7ED5755G4667064-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 21:23:01 -0000 Hi Giles, I prefer the methods that have no IPR, if they are not significantly more c= omplex or in-efficient or less scalable compared to method with IPR. =20 Thanks Shahram -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of G= iles Heron Sent: Friday, June 01, 2012 2:04 AM To: l2vpn@ietf.org Cc: Stewart Bryant Subject: Progressing E-Tree - IPR issues Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. It appears that some or all of the current E-Tree drafts may be encumbered by IPR. We'd like to ask the WG whether we should continue to progress these drafts= , or whether we should attempt to pursue alternatives that aren't encumbered. Would those with opinions please respond to this question within the next 2 weeks (i.e. by Friday 15th of June). Thanks in advance. Giles From lizho.jin@gmail.com Sat Jun 2 19:36:22 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585F511E8080 for ; Sat, 2 Jun 2012 19:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgr5Jnk4IQDU for ; Sat, 2 Jun 2012 19:36:21 -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 9760811E8073 for ; Sat, 2 Jun 2012 19:36:21 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so5980137obb.31 for ; Sat, 02 Jun 2012 19:36:21 -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:cc:content-type; bh=55Wan6t7/rXeGR3mGaRr8PJBs0vX6DRFr4oB8CSPdWY=; b=NJRAM9XyehE4IDsMYhFxciLqz/80yXtB7ERG+iWXWYSwQKI5RShZ05GznqlfG81NWX WkU2pMIpePwOG/qTZqpwqbww6O+MzNx8KmGolywzpg5Au9q6wl1B8JMU5Z0KOM/cec2U XJGKWjllR+PfwcqUJr02VOnrh10UMxcebBmAtReRWf32R/3VG5P6YDk5cHZdmOKPUFA4 ddwaowyaE3CwXu1yrxdyJahP9vHjDh/SbkVYTHuyTaxWEGBEJhatO4nXIYk/4t4GOfPE I4ScxqZAZJ/9r0ANvYCe0f+PQITmrTziQUpSK0O37nemlyGEzXBQkyfjDJ6iHzw9QthW XtWw== MIME-Version: 1.0 Received: by 10.42.51.144 with SMTP id e16mr4764657icg.54.1338690980968; Sat, 02 Jun 2012 19:36:20 -0700 (PDT) Received: by 10.50.106.198 with HTTP; Sat, 2 Jun 2012 19:36:20 -0700 (PDT) Date: Sun, 3 Jun 2012 10:36:20 +0800 Message-ID: Subject: RE: Progressing E-Tree - IPR issues From: Lizhong Jin To: l2vpn@ietf.org Content-Type: multipart/alternative; boundary=20cf301cc2da627ae704c18848a4 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 02:36:22 -0000 --20cf301cc2da627ae704c18848a4 Content-Type: text/plain; charset=ISO-8859-1 Me too, prefer without any IPR. Lizhong > ---------------------------------------------------------------------- > > Date: Fri, 1 Jun 2012 21:22:46 +0000 > From: "Shahram Davari" > To: "Giles Heron" , "l2vpn@ietf.org" > > Cc: Stewart Bryant > Subject: RE: Progressing E-Tree - IPR issues > Message-ID: > < > 4A6CE49E6084B141B15C0713B8993F2804165F@SJEXCHMB12.corp.ad.broadcom.com> > > Content-Type: text/plain; charset=us-ascii > > Hi Giles, > > I prefer the methods that have no IPR, if they are not significantly more > complex or in-efficient or less scalable compared to method with IPR. > > Thanks > Shahram > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Giles Heron > Sent: Friday, June 01, 2012 2:04 AM > To: l2vpn@ietf.org > Cc: Stewart Bryant > Subject: Progressing E-Tree - IPR issues > > Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. > > It appears that some or all of the current E-Tree drafts may be encumbered > by IPR. > > We'd like to ask the WG whether we should continue to progress these > drafts, > or whether we should attempt to pursue alternatives that aren't encumbered. > > Would those with opinions please respond to this question within the next 2 > weeks (i.e. by Friday 15th of June). > > Thanks in advance. > > Giles > > > > > --20cf301cc2da627ae704c18848a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Me too, prefer without any IPR.
<= br>
Lizhong


----------------------------------------------------------------------
<= br> Date: Fri, 1 Jun 2012 21:22:46 +0000
From: "Shahram Davari" <davari@broadcom.com>
To: "Giles Heron" <gi= les.heron@gmail.com>, =A0 =A0 =A0"l2vpn@ietf.org"
=A0 =A0 =A0 =A0<l2vpn@ietf.org>= ;
Cc: Stewart Bryant <stbryant@cisco= .com>
Subject: RE: Progressing E-Tree - IPR issues
Message-ID:
=A0 =A0 =A0 =A0<4A6CE49E6084B141B15C0713B8993F2804165F@S= JEXCHMB12.corp.ad.broadcom.com>

Content-Type: text/plain; charset=3Dus-ascii

Hi Giles,

I prefer the methods that have no IPR, if they are not significantly more c= omplex or in-efficient or less scalable compared to method with IPR.

Thanks
Shahram

-----Original Message-----
From: l2vpn-bounces@ietf.org = [mailto:l2vpn-bounces@ietf.org] On Behalf Of Giles Heron
Sent: Friday, June 01, 2012 2:04 AM
To: l2vpn@ietf.org
Cc: Stewart Bryant
Subject: Progressing E-Tree - IPR issues

Nabil, Stewart and I discussed the issue of IPR and E-Tree recently.

It appears that some or all of the current E-Tree drafts may be encumbered<= br> by IPR.

We'd like to ask the WG whether we should continue to progress these dr= afts,
or whether we should attempt to pursue alternatives that aren't encumbe= red.

Would those with opinions please respond to this question within the next 2=
weeks (i.e. by Friday 15th of June).

Thanks in advance.

Giles





--20cf301cc2da627ae704c18848a4-- From tnadeau@lucidvision.com Mon Jun 4 11:38:03 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DD521F87CA for ; Mon, 4 Jun 2012 11:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuYOVBbaN7K2 for ; Mon, 4 Jun 2012 11:38:02 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC9321F87BF for ; Mon, 4 Jun 2012 11:37:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id D6E1B214E98A; Mon, 4 Jun 2012 14:37:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl2kcm2SW5p2; Mon, 4 Jun 2012 14:37:58 -0400 (EDT) Received: from sa-nc-common3-254.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id EB741214E984; Mon, 4 Jun 2012 14:37:57 -0400 (EDT) Subject: Re: Progressing E-Tree - IPR issues Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: Date: Mon, 4 Jun 2012 11:38:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Giles Heron X-Mailer: Apple Mail (2.1278) Cc: l2vpn@ietf.org, Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 18:38:03 -0000 Being encumbered by IPR can mean a number of things. I am ok = with having IPR claims for any of the solutions, as long as they agree = to the IETF's normal licensing requirements. I am not in favor of = adopting any solutions that do not follow these requirements. --Tom On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: > Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. >=20 > It appears that some or all of the current E-Tree drafts may be = encumbered > by IPR. >=20 > We'd like to ask the WG whether we should continue to progress these = drafts, > or whether we should attempt to pursue alternatives that aren't = encumbered. >=20 > Would those with opinions please respond to this question within the = next 2 > weeks (i.e. by Friday 15th of June). >=20 > Thanks in advance. >=20 > Giles >=20 >=20 >=20 From wim.henderickx@alcatel-lucent.com Mon Jun 4 12:54:41 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E6E11E80CD for ; Mon, 4 Jun 2012 12:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.941 X-Spam-Level: X-Spam-Status: No, score=-9.941 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwpMd4+D4tjC for ; Mon, 4 Jun 2012 12:54:40 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 69FD411E80B4 for ; Mon, 4 Jun 2012 12:54:39 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q54JsZ4h021798 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Jun 2012 21:54:35 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 4 Jun 2012 21:54:35 +0200 From: "Henderickx, Wim (Wim)" To: Thomas Nadeau , Giles Heron Date: Mon, 4 Jun 2012 21:54:36 +0200 Subject: RE: Progressing E-Tree - IPR issues Thread-Topic: Progressing E-Tree - IPR issues Thread-Index: Ac1CgTPtAX7cUBSAQg2JbQ1Mtt1OOwACqjJw Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF5B9A8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "l2vpn@ietf.org" , Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 19:54:41 -0000 +1 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of T= homas Nadeau Sent: maandag 4 juni 2012 17:38 To: Giles Heron Cc: l2vpn@ietf.org; Stewart Bryant Subject: Re: Progressing E-Tree - IPR issues Being encumbered by IPR can mean a number of things. I am ok with having I= PR claims for any of the solutions, as long as they agree to the IETF's nor= mal licensing requirements. I am not in favor of adopting any solutions tha= t do not follow these requirements. --Tom On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: > Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. >=20 > It appears that some or all of the current E-Tree drafts may be encumbere= d > by IPR. >=20 > We'd like to ask the WG whether we should continue to progress these draf= ts, > or whether we should attempt to pursue alternatives that aren't encumbere= d. >=20 > Would those with opinions please respond to this question within the next= 2 > weeks (i.e. by Friday 15th of June). >=20 > Thanks in advance. >=20 > Giles >=20 >=20 >=20 From paul@unbehagen.net Mon Jun 4 13:02:00 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E015321F885D for ; Mon, 4 Jun 2012 13:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9gFNLl0xnd6 for ; Mon, 4 Jun 2012 13:02:00 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6570121F8841 for ; Mon, 4 Jun 2012 13:02:00 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4107406ghb.31 for ; Mon, 04 Jun 2012 13:02:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=pqRks4MXblLwXeHrRhMXKTp0lf9nMRFlPF9zDYjeNMY=; b=Sc99edrAKuWSueDaF2iBTCETAQ+52OFPkby0MUeByG7dXNFl6RyTTMAivs289rnQZJ cOox73hP6aG4SbKyiS9Z8rIxSykbUUD/ZploJblJk6nrgtoEUna/W+y1vAbC7hWBDjPb Yw9E85iB3RAcy93vpo00Zc+vNr43icIJwFWTLTxmHdNB0ZUdvwvaIXOPvLiWygG4l6Nf 17/erLS4ZgmQnZkVHjXMN6grFiR4/Xz4W64LQ27tmFzwVVNYXysz/0MkVg1Mr9i8kiB4 mU5tM+jpvktF8KPS959eQILPUGPM4d5nJ+O5HIbtBkSXrMARFt4cq/QZzWLhb7iBkgXQ pjzA== Received: by 10.50.194.200 with SMTP id hy8mr9079049igc.58.1338840119711; Mon, 04 Jun 2012 13:01:59 -0700 (PDT) Received: from [10.0.1.5] (c-67-161-144-217.hsd1.co.comcast.net. [67.161.144.217]) by mx.google.com with ESMTPS id dw5sm7404080igc.6.2012.06.04.13.01.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 13:01:58 -0700 (PDT) References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF5B9A8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF5B9A8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8787D1C4-7215-4758-951D-71A48488810F@unbehagen.net> X-Mailer: iPad Mail (9B206) From: Paul Unbehagen Subject: Re: Progressing E-Tree - IPR issues Date: Mon, 4 Jun 2012 14:01:56 -0600 To: "Henderickx, Wim (Wim)" X-Gm-Message-State: ALoCoQk+98BCLxuBer2oQ4o3aB7ST4oab8a+MBmEjoct/RWEICr4Qb+9SJUewgofyPFADI8i/co2 Cc: "l2vpn@ietf.org" , Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:02:01 -0000 +1 On Jun 4, 2012, at 1:54 PM, "Henderickx, Wim (Wim)" wrote: > +1 >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of T= homas Nadeau > Sent: maandag 4 juni 2012 17:38 > To: Giles Heron > Cc: l2vpn@ietf.org; Stewart Bryant > Subject: Re: Progressing E-Tree - IPR issues >=20 >=20 > Being encumbered by IPR can mean a number of things. I am ok with havin= g IPR claims for any of the solutions, as long as they agree to the IETF's n= ormal licensing requirements. I am not in favor of adopting any solutions th= at do not follow these requirements. >=20 > --Tom >=20 >=20 > On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: >=20 >> Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. >>=20 >> It appears that some or all of the current E-Tree drafts may be encumbere= d >> by IPR. >>=20 >> We'd like to ask the WG whether we should continue to progress these draf= ts, >> or whether we should attempt to pursue alternatives that aren't encumbere= d. >>=20 >> Would those with opinions please respond to this question within the next= 2 >> weeks (i.e. by Friday 15th of June). >>=20 >> Thanks in advance. >>=20 >> Giles >>=20 >>=20 >>=20 >=20 From lufang@cisco.com Mon Jun 4 13:04:56 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6615221F85DF for ; Mon, 4 Jun 2012 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5EFaQA7oNKY for ; Mon, 4 Jun 2012 13:04:55 -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 9C70F21F85BB for ; Mon, 4 Jun 2012 13:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1797; q=dns/txt; s=iport; t=1338840295; x=1340049895; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6j6F3pSq+2iNB8rR7HYLes7xIUefOWwYWqWp+m5Xmeo=; b=awWQ5dbn82zfLmP55hoWTtCSCWoUY3EPFZtnTkwtS9rMxp2UIE3In/zX j8HqFy5QOfP6A3zHJhKXvwc8avc3HyP/dhh60P5+3Rt3m67X7ygKzMNLf CYIVHpVFdGqsBlRTGfJ1nmF+uO4obqhg3XAKpkef8VU+S3Hj2xL35iiXx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABIUzU+tJXG9/2dsb2JhbABEtCuBB4IYAQEBBBIBHQo/DAQCAQgRBAEBAQoGFwEGAUUJCAEBBBMIEweHaZcqn0uLEYUwYAOIQJprgWaCfg X-IronPort-AV: E=Sophos;i="4.75,714,1330905600"; d="scan'208";a="89399197" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 04 Jun 2012 20:04:55 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q54K4t5S029303; Mon, 4 Jun 2012 20:04:55 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jun 2012 15:04:54 -0500 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 Subject: RE: Progressing E-Tree - IPR issues Date: Mon, 4 Jun 2012 15:04:50 -0500 Message-ID: <238542D917511A45B6B8AA806E875E250940379F@XMB-RCD-201.cisco.com> In-Reply-To: <8787D1C4-7215-4758-951D-71A48488810F@unbehagen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Progressing E-Tree - IPR issues thread-index: Ac1CjOw2yQZfWL4bS8qP97dGLjuBMwAAB2Cw References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF5B9A8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <8787D1C4-7215-4758-951D-71A48488810F@unbehagen.net> From: "Luyuan Fang (lufang)" To: "Paul Unbehagen" , "Henderickx, Wim (Wim)" X-OriginalArrivalTime: 04 Jun 2012 20:04:54.0866 (UTC) FILETIME=[4F1BDB20:01CD428D] Cc: l2vpn@ietf.org, "Stewart Bryant \(stbryant\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:04:56 -0000 +1 Now, would it be up to each IPR applicant(s) to tell the WG if they agree to the IETF's normal licensing requirements or not? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Paul Unbehagen > Sent: Monday, June 04, 2012 4:02 PM > To: Henderickx, Wim (Wim) > Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) > Subject: Re: Progressing E-Tree - IPR issues >=20 > +1 >=20 >=20 >=20 > On Jun 4, 2012, at 1:54 PM, "Henderickx, Wim (Wim)" > wrote: >=20 > > +1 > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf Of Thomas Nadeau > > Sent: maandag 4 juni 2012 17:38 > > To: Giles Heron > > Cc: l2vpn@ietf.org; Stewart Bryant > > Subject: Re: Progressing E-Tree - IPR issues > > > > > > Being encumbered by IPR can mean a number of things. I am ok with > having IPR claims for any of the solutions, as long as they agree to > the IETF's normal licensing requirements. I am not in favor of adopting > any solutions that do not follow these requirements. > > > > --Tom > > > > > > On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: > > > >> Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. > >> > >> It appears that some or all of the current E-Tree drafts may be > encumbered > >> by IPR. > >> > >> We'd like to ask the WG whether we should continue to progress these > drafts, > >> or whether we should attempt to pursue alternatives that aren't > encumbered. > >> > >> Would those with opinions please respond to this question within the > next 2 > >> weeks (i.e. by Friday 15th of June). > >> > >> Thanks in advance. > >> > >> Giles > >> > >> > >> > > From DanielC@orckit.com Tue Jun 5 00:07:25 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259FB21F86A8 for ; Tue, 5 Jun 2012 00:07:25 -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 MaKxZwwF6DWM for ; Tue, 5 Jun 2012 00:07:24 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id BFBDD21F86A6 for ; Tue, 5 Jun 2012 00:07:22 -0700 (PDT) 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 Subject: RE: Progressing E-Tree - IPR issues Date: Tue, 5 Jun 2012 10:09:50 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081307892B6E@tlvmail1> In-Reply-To: <238542D917511A45B6B8AA806E875E250940379F@XMB-RCD-201.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing E-Tree - IPR issues Thread-Index: Ac1CjOw2yQZfWL4bS8qP97dGLjuBMwAAB2CwABYzOfA= References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF5B9A8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><8787D1C4-7215-4758-951D-71A48488810F@unbehagen.net> <238542D917511A45B6B8AA806E875E250940379F@XMB-RCD-201.cisco.com> From: "Daniel Cohn" To: "Luyuan Fang (lufang)" , "Paul Unbehagen" , "Henderickx, Wim (Wim)" Cc: l2vpn@ietf.org, "Stewart Bryant \(stbryant\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 07:07:25 -0000 Hi, The applicant licensing requirements can be verified in the IPR disclosure form, then everyone can judge if they conform to the "normal licensing requirements". Daniel -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: Monday, June 04, 2012 11:05 PM To: Paul Unbehagen; Henderickx, Wim (Wim) Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) Subject: RE: Progressing E-Tree - IPR issues +1 Now, would it be up to each IPR applicant(s) to tell the WG if they agree to the IETF's normal licensing requirements or not? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Paul Unbehagen > Sent: Monday, June 04, 2012 4:02 PM > To: Henderickx, Wim (Wim) > Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) > Subject: Re: Progressing E-Tree - IPR issues >=20 > +1 >=20 >=20 >=20 > On Jun 4, 2012, at 1:54 PM, "Henderickx, Wim (Wim)" > wrote: >=20 > > +1 > > > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On > Behalf Of Thomas Nadeau > > Sent: maandag 4 juni 2012 17:38 > > To: Giles Heron > > Cc: l2vpn@ietf.org; Stewart Bryant > > Subject: Re: Progressing E-Tree - IPR issues > > > > > > Being encumbered by IPR can mean a number of things. I am ok with > having IPR claims for any of the solutions, as long as they agree to > the IETF's normal licensing requirements. I am not in favor of adopting > any solutions that do not follow these requirements. > > > > --Tom > > > > > > On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: > > > >> Nabil, Stewart and I discussed the issue of IPR and E-Tree recently. > >> > >> It appears that some or all of the current E-Tree drafts may be > encumbered > >> by IPR. > >> > >> We'd like to ask the WG whether we should continue to progress these > drafts, > >> or whether we should attempt to pursue alternatives that aren't > encumbered. > >> > >> Would those with opinions please respond to this question within the > next 2 > >> weeks (i.e. by Friday 15th of June). > >> > >> Thanks in advance. > >> > >> Giles > >> > >> > >> > > From davari@broadcom.com Tue Jun 5 06:26:27 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C88121F86A8 for ; Tue, 5 Jun 2012 06:26:27 -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 cfgZhOgV4AI1 for ; Tue, 5 Jun 2012 06:26:26 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9673021F8683 for ; Tue, 5 Jun 2012 06:26:26 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 05 Jun 2012 06:27:05 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCAS01.corp.ad.broadcom.com (10.16.192.31) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 5 Jun 2012 06:26:07 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by sjexchcas01.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 5 Jun 2012 06:26:07 -0700 From: "Shahram Davari" To: "Daniel Cohn" Subject: Re: Progressing E-Tree - IPR issues Thread-Topic: Progressing E-Tree - IPR issues Thread-Index: Ac0/1W81Ihu2DKA2C0ieX8h0maJzKgCzUUMAAAj1lgAAAEGRAAAAGe0AABc5kQD///PHeg== Date: Tue, 5 Jun 2012 13:26:06 +0000 Message-ID: <01A028CA-3D54-472F-96F6-030D707A50B7@broadcom.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF5B9A8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><8787D1C4-7215-4758-951D-71A48488810F@unbehagen.net> <238542D917511A45B6B8AA806E875E250940379F@XMB-RCD-201.cisco.com>, <44F4E579A764584EA9BDFD07D0CA081307892B6E@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA081307892B6E@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 63D0D6A355G6387448-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@ietf.org" , "Stewart Bryant \(stbryant\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:26:27 -0000 Although IETF rules accept IPRs with licensing fee, but RF 3979 states and = I agree that no licensing fee is preferred.=20 The current disclosures either have not provided Licensing terms or they ar= e royalty-bearing or they would want cross licensing in case some one uses = their technology. So as I said before if there is not a huge difference, I prefer those draft= s that have no IPR or that have royalty-free IPR. Regards, Shahram On Jun 5, 2012, at 12:07 AM, "Daniel Cohn" wrote: > Hi, >=20 > The applicant licensing requirements can be verified in the IPR > disclosure form, then everyone can judge if they conform to the "normal > licensing requirements". >=20 > Daniel >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Luyuan Fang (lufang) > Sent: Monday, June 04, 2012 11:05 PM > To: Paul Unbehagen; Henderickx, Wim (Wim) > Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) > Subject: RE: Progressing E-Tree - IPR issues >=20 > +1 > Now, would it be up to each IPR applicant(s) to tell the WG if they > agree to the IETF's normal licensing requirements or not? >=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Paul Unbehagen >> Sent: Monday, June 04, 2012 4:02 PM >> To: Henderickx, Wim (Wim) >> Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: Progressing E-Tree - IPR issues >>=20 >> +1 >>=20 >>=20 >>=20 >> On Jun 4, 2012, at 1:54 PM, "Henderickx, Wim (Wim)" >> wrote: >>=20 >>> +1 >>>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf Of Thomas Nadeau >>> Sent: maandag 4 juni 2012 17:38 >>> To: Giles Heron >>> Cc: l2vpn@ietf.org; Stewart Bryant >>> Subject: Re: Progressing E-Tree - IPR issues >>>=20 >>>=20 >>> Being encumbered by IPR can mean a number of things. I am ok with >> having IPR claims for any of the solutions, as long as they agree to >> the IETF's normal licensing requirements. I am not in favor of > adopting >> any solutions that do not follow these requirements. >>>=20 >>> --Tom >>>=20 >>>=20 >>> On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: >>>=20 >>>> Nabil, Stewart and I discussed the issue of IPR and E-Tree > recently. >>>>=20 >>>> It appears that some or all of the current E-Tree drafts may be >> encumbered >>>> by IPR. >>>>=20 >>>> We'd like to ask the WG whether we should continue to progress > these >> drafts, >>>> or whether we should attempt to pursue alternatives that aren't >> encumbered. >>>>=20 >>>> Would those with opinions please respond to this question within > the >> next 2 >>>> weeks (i.e. by Friday 15th of June). >>>>=20 >>>> Thanks in advance. >>>>=20 >>>> Giles >>>>=20 >>>>=20 >>>>=20 >>>=20 >=20 From jiangyuanlong@huawei.com Tue Jun 5 21:11:32 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E882E21F8638 for ; Tue, 5 Jun 2012 21:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 gRK4amZJxfdm for ; Tue, 5 Jun 2012 21:11:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B231121F8595 for ; Tue, 5 Jun 2012 21:11:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGX02152; Wed, 06 Jun 2012 00:11:24 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 5 Jun 2012 21:07:22 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 5 Jun 2012 21:07:25 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 6 Jun 2012 12:07:21 +0800 From: Jiangyuanlong To: Shahram Davari , Daniel Cohn , Stewart Bryant Subject: Re: Progressing E-Tree - IPR issues Thread-Topic: Progressing E-Tree - IPR issues Thread-Index: AQHNQ5ne7Qacf+K8QUi4rlS1/yNstA== Date: Wed, 6 Jun 2012 04:07:19 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D415E9A@szxeml546-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.40.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 04:11:32 -0000 Hi Shahram, Please see my comments in line. ------------------------------ Date: Tue, 5 Jun 2012 13:26:06 +0000 From: "Shahram Davari" To: "Daniel Cohn" Cc: "l2vpn@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: Progressing E-Tree - IPR issues Message-ID: <01A028CA-3D54-472F-96F6-030D707A50B7@broadcom.com> Content-Type: text/plain; charset=3Dus-ascii Although IETF rules accept IPRs with licensing fee, but RF 3979 states and = I agree that no licensing fee is preferred.=20 The current disclosures either have not provided Licensing terms or they ar= e royalty-bearing or they would want cross licensing in case some one uses = their technology. [JY] As I am aware, all E-Tree IPR claims either follow option b) or c) of = RFC 3905, just as most IPRs already claimed in this WG. Or did I miss somet= hing?=20 So as I said before if there is not a huge difference, I prefer those draft= s that have no IPR or that have royalty-free IPR. [JY] Taken from RFC 3979: "It should also be noted that the absence of IPR= disclosures is not the same thing as the knowledge that there will be no I= PR claims in the future." and "It should also be noted that the validity an= d enforceability of any IPR may be challenged for legitimate reasons, and t= he mere existence of an IPR disclosure should not automatically be taken to= mean that the disclosed IPR is valid or enforceable." We've seen many IPRs= claimed only after WG adoption, can we guarantee that a new draft will hav= e no IPR claim at all in the end? After all, alternative E-Tree solutions h= ad been explored and discussed for almost 2 years, and now all seem to be e= ncumbered with IPRs, IMHO, a new fancy solution may more likely be patent-e= ncumbered. Anyway, all these E-Tree I-Ds are only individual drafts, and any people ca= n contribute new I-Ds to this WG, which will further enrich the solution sp= ace for the WG's choice. With regard to Evaluating Alternative Technologies= in IETF Working Groups, besides the preference of technologies with no IPR= or that have royalty-free IPR as you mentioned, RFC 3979 also indicates: "= But IETF working groups have the discretion to adopt technology with a comm= itment of fair and non-discriminatory terms, or even with no licensing comm= itment, if they feel that this technology is superior enough to alternative= s with fewer IPR claims or free licensing to outweigh the potential cost of= the licenses." Thanks, Yuanlong Regards, Shahram On Jun 5, 2012, at 12:07 AM, "Daniel Cohn" wrote: > Hi, >=20 > The applicant licensing requirements can be verified in the IPR > disclosure form, then everyone can judge if they conform to the "normal > licensing requirements". >=20 > Daniel >=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Luyuan Fang (lufang) > Sent: Monday, June 04, 2012 11:05 PM > To: Paul Unbehagen; Henderickx, Wim (Wim) > Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) > Subject: RE: Progressing E-Tree - IPR issues >=20 > +1 > Now, would it be up to each IPR applicant(s) to tell the WG if they > agree to the IETF's normal licensing requirements or not? >=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Paul Unbehagen >> Sent: Monday, June 04, 2012 4:02 PM >> To: Henderickx, Wim (Wim) >> Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: Progressing E-Tree - IPR issues >>=20 >> +1 >>=20 >>=20 >>=20 >> On Jun 4, 2012, at 1:54 PM, "Henderickx, Wim (Wim)" >> wrote: >>=20 >>> +1 >>>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >> Behalf Of Thomas Nadeau >>> Sent: maandag 4 juni 2012 17:38 >>> To: Giles Heron >>> Cc: l2vpn@ietf.org; Stewart Bryant >>> Subject: Re: Progressing E-Tree - IPR issues >>>=20 >>>=20 >>> Being encumbered by IPR can mean a number of things. I am ok with >> having IPR claims for any of the solutions, as long as they agree to >> the IETF's normal licensing requirements. I am not in favor of > adopting >> any solutions that do not follow these requirements. >>>=20 >>> --Tom >>>=20 >>>=20 >>> On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: >>>=20 >>>> Nabil, Stewart and I discussed the issue of IPR and E-Tree > recently. >>>>=20 >>>> It appears that some or all of the current E-Tree drafts may be >> encumbered >>>> by IPR. >>>>=20 >>>> We'd like to ask the WG whether we should continue to progress > these >> drafts, >>>> or whether we should attempt to pursue alternatives that aren't >> encumbered. >>>>=20 >>>> Would those with opinions please respond to this question within > the >> next 2 >>>> weeks (i.e. by Friday 15th of June). >>>>=20 >>>> Thanks in advance. >>>>=20 >>>> Giles >>>>=20 >>>>=20 >>>>=20 >>>=20 >=20 ------------------------------ _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest, Vol 97, Issue 5 ************************************ From davari@broadcom.com Tue Jun 5 21:45:58 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFB521F86DF for ; Tue, 5 Jun 2012 21:45:57 -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 UJMaxzgDBvk7 for ; Tue, 5 Jun 2012 21:45:46 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50A21F8499 for ; Tue, 5 Jun 2012 21:45:39 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 05 Jun 2012 21:46:24 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 5 Jun 2012 21:45:25 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 5 Jun 2012 21:45:24 -0700 From: "Shahram Davari" To: Jiangyuanlong Subject: Re: Progressing E-Tree - IPR issues Thread-Topic: Progressing E-Tree - IPR issues Thread-Index: AQHNQ5neIhu2DKA2C0ieX8h0maJzKpbstys1 Date: Wed, 6 Jun 2012 04:45:24 +0000 Message-ID: References: , <3B0A1BED22CAD649A1B3E97BE5DDD68B1D415E9A@szxeml546-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D415E9A@szxeml546-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 63D03F2A3IK148506-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@ietf.org" , Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 04:45:58 -0000 Hi, You hit the nail in the head in your last sentence. Royalty-Bearing IPRs sh= ould be considered only if they are technologically superior. Regards, Shahram On Jun 5, 2012, at 9:11 PM, "Jiangyuanlong" wrot= e: > Hi Shahram, >=20 > Please see my comments in line. > ------------------------------ > Date: Tue, 5 Jun 2012 13:26:06 +0000 > From: "Shahram Davari" > To: "Daniel Cohn" > Cc: "l2vpn@ietf.org" , "Stewart Bryant \(stbryant\)" > > Subject: Re: Progressing E-Tree - IPR issues > Message-ID: <01A028CA-3D54-472F-96F6-030D707A50B7@broadcom.com> > Content-Type: text/plain; charset=3Dus-ascii >=20 > Although IETF rules accept IPRs with licensing fee, but RF 3979 states an= d I agree that no licensing fee is preferred.=20 >=20 > The current disclosures either have not provided Licensing terms or they = are royalty-bearing or they would want cross licensing in case some one use= s their technology. > [JY] As I am aware, all E-Tree IPR claims either follow option b) or c) o= f RFC 3905, just as most IPRs already claimed in this WG. Or did I miss som= ething?=20 >=20 > So as I said before if there is not a huge difference, I prefer those dra= fts that have no IPR or that have royalty-free IPR. > [JY] Taken from RFC 3979: "It should also be noted that the absence of I= PR disclosures is not the same thing as the knowledge that there will be no= IPR claims in the future." and "It should also be noted that the validity = and enforceability of any IPR may be challenged for legitimate reasons, and= the mere existence of an IPR disclosure should not automatically be taken = to mean that the disclosed IPR is valid or enforceable." We've seen many IP= Rs claimed only after WG adoption, can we guarantee that a new draft will h= ave no IPR claim at all in the end? After all, alternative E-Tree solutions= had been explored and discussed for almost 2 years, and now all seem to be= encumbered with IPRs, IMHO, a new fancy solution may more likely be patent= -encumbered. > Anyway, all these E-Tree I-Ds are only individual drafts, and any people = can contribute new I-Ds to this WG, which will further enrich the solution = space for the WG's choice. With regard to Evaluating Alternative Technologi= es in IETF Working Groups, besides the preference of technologies with no I= PR or that have royalty-free IPR as you mentioned, RFC 3979 also indicates:= "But IETF working groups have the discretion to adopt technology with a co= mmitment of fair and non-discriminatory terms, or even with no licensing co= mmitment, if they feel that this technology is superior enough to alternati= ves with fewer IPR claims or free licensing to outweigh the potential cost = of the licenses." >=20 > Thanks, > Yuanlong >=20 > Regards, > Shahram >=20 >=20 > On Jun 5, 2012, at 12:07 AM, "Daniel Cohn" wrote: >=20 >> Hi, >>=20 >> The applicant licensing requirements can be verified in the IPR >> disclosure form, then everyone can judge if they conform to the "normal >> licensing requirements". >>=20 >> Daniel >>=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Luyuan Fang (lufang) >> Sent: Monday, June 04, 2012 11:05 PM >> To: Paul Unbehagen; Henderickx, Wim (Wim) >> Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) >> Subject: RE: Progressing E-Tree - IPR issues >>=20 >> +1 >> Now, would it be up to each IPR applicant(s) to tell the WG if they >> agree to the IETF's normal licensing requirements or not? >>=20 >>> -----Original Message----- >>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>> Of Paul Unbehagen >>> Sent: Monday, June 04, 2012 4:02 PM >>> To: Henderickx, Wim (Wim) >>> Cc: l2vpn@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: Progressing E-Tree - IPR issues >>>=20 >>> +1 >>>=20 >>>=20 >>>=20 >>> On Jun 4, 2012, at 1:54 PM, "Henderickx, Wim (Wim)" >>> wrote: >>>=20 >>>> +1 >>>>=20 >>>> -----Original Message----- >>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On >>> Behalf Of Thomas Nadeau >>>> Sent: maandag 4 juni 2012 17:38 >>>> To: Giles Heron >>>> Cc: l2vpn@ietf.org; Stewart Bryant >>>> Subject: Re: Progressing E-Tree - IPR issues >>>>=20 >>>>=20 >>>> Being encumbered by IPR can mean a number of things. I am ok with >>> having IPR claims for any of the solutions, as long as they agree to >>> the IETF's normal licensing requirements. I am not in favor of >> adopting >>> any solutions that do not follow these requirements. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>> On Jun 1, 2012:5:03 AM, at 5:03 AM, Giles Heron wrote: >>>>=20 >>>>> Nabil, Stewart and I discussed the issue of IPR and E-Tree >> recently. >>>>>=20 >>>>> It appears that some or all of the current E-Tree drafts may be >>> encumbered >>>>> by IPR. >>>>>=20 >>>>> We'd like to ask the WG whether we should continue to progress >> these >>> drafts, >>>>> or whether we should attempt to pursue alternatives that aren't >>> encumbered. >>>>>=20 >>>>> Would those with opinions please respond to this question within >> the >>> next 2 >>>>> weeks (i.e. by Friday 15th of June). >>>>>=20 >>>>> Thanks in advance. >>>>>=20 >>>>> Giles >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>=20 >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > L2vpn mailing list > L2vpn@ietf.org > https://www.ietf.org/mailman/listinfo/l2vpn >=20 >=20 > End of L2vpn Digest, Vol 97, Issue 5 > ************************************ >=20 From stbryant@cisco.com Wed Jun 6 02:11:51 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD9B21F86A2 for ; Wed, 6 Jun 2012 02:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wBl6FKX2UIza for ; Wed, 6 Jun 2012 02:11:50 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id F102821F869D for ; Wed, 6 Jun 2012 02:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=460; q=dns/txt; s=iport; t=1338973910; x=1340183510; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ggme0xTa45WtuNF4mGImmDePCEUgCHdamuxXzmqGfG8=; b=Xx8qcQzP52OTLpfGG4pmv6PtHCsXpTQQrekpq3ixEvvhxASfd07b0IVC CrF3f9rzJUZz0LM4qCXrI74miPIcTIslbFkzO/GBTQGjGSTgym/G2mgTV GI9zvW7ATVIAokEFieBT0PQ6ws+R9SVjd4AAjXGZOiMfAYlP2Xk5Caw9g w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAOUdz0+Q/khM/2dsb2JhbABFhU6rCINagQeCGAEBAQQSAQIOFUABEAsOCgICBRYLAgIJAwIBAgFFBg0BBwEBFweHaZcvg0cQiT+SZ4EjiXGFB4ESA5UcjhKBBGKCYQ X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="74094052" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 06 Jun 2012 09:11:48 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q569BmA8015094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 09:11:48 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q569BkET027970; Wed, 6 Jun 2012 10:11:47 +0100 (BST) Message-ID: <4FCF1ED2.4060608@cisco.com> Date: Wed, 06 Jun 2012 10:11:46 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Thomas Nadeau Subject: Re: Progressing E-Tree - IPR issues References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:11:51 -0000 On 04/06/2012 16:38, Thomas Nadeau wrote: > Being encumbered by IPR can mean a number of things. I am ok with having IPR claims for any of the solutions, as long as they agree to the IETF's normal licensing requirements. I am not in favor of adopting any solutions that do not follow these requirements. > > --Tom Tom It is inappropriate to discuss license terms, or to pressure an IPR holder to change their license terms on this list. Stewart From stbryant@cisco.com Wed Jun 6 02:15:06 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044CE21F85A3 for ; Wed, 6 Jun 2012 02:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 F9440Rwh31vH for ; Wed, 6 Jun 2012 02:15:05 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1A60321F85A1 for ; Wed, 6 Jun 2012 02:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=335; q=dns/txt; s=iport; t=1338974105; x=1340183705; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Wcpht9GeWWEg5ptOlzy82QYyaSp+X1xD6metERjUKX0=; b=bI4uAwLDV992fMnE9aGS9fB2ZW6lxMWX6oemjZFVsd2P00bNIWBcQkug JJOIJvQkPNIuxc5PWURc6SR7efsD7bILTWulJ7bOi6my2nxZhwx1E43h+ 2QotKLkUxX7wSovVWrBXSTx5+WXryV56gxodjsF6WQAuxn7n+ESYnOoKK 8=; X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="5432649" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 06 Jun 2012 09:15:04 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q569F3YV016058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 09:15:04 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q569F2te028203; Wed, 6 Jun 2012 10:15:02 +0100 (BST) Message-ID: <4FCF1F96.9020209@cisco.com> Date: Wed, 06 Jun 2012 10:15:02 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Luyuan Fang (lufang)" Subject: Re: Progressing E-Tree - IPR issues References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF5B9A8C@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <8787D1C4-7215-4758-951D-71A48488810F@unbehagen.net> <238542D917511A45B6B8AA806E875E250940379F@XMB-RCD-201.cisco.com> In-Reply-To: <238542D917511A45B6B8AA806E875E250940379F@XMB-RCD-201.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:15:06 -0000 On 04/06/2012 21:04, Luyuan Fang (lufang) wrote: > +1 > Now, would it be up to each IPR applicant(s) to tell the WG if they > agree to the IETF's normal licensing requirements or not? There are no "normal" IETF licensing terms. For anti-trust reasons the IETF does not engage in discussions of licensing terms. Stewart From tnadeau@lucidvision.com Wed Jun 6 06:41:16 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFF321F8855 for ; Wed, 6 Jun 2012 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 5yLNkWNd5015 for ; Wed, 6 Jun 2012 06:41:15 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBC321F8869 for ; Wed, 6 Jun 2012 06:41:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id D702F2153FF2; Wed, 6 Jun 2012 09:41:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wvkwbVHcvz7; Wed, 6 Jun 2012 09:41:10 -0400 (EDT) Received: from [10.4.44.243] (mobile-198-228-214-174.mycingular.net [198.228.214.174]) by lucidvision.com (Postfix) with ESMTP id 5D0F62153FEE; Wed, 6 Jun 2012 09:41:10 -0400 (EDT) References: <4FCF1ED2.4060608@cisco.com> In-Reply-To: <4FCF1ED2.4060608@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Thomas Nadeau Subject: Re: Progressing E-Tree - IPR issues Date: Wed, 6 Jun 2012 06:41:05 -0700 To: "stbryant@cisco.com" Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 13:41:16 -0000 I think it's inappropriate to not follow the ietfs licensing requirements by= proposing solutions that are not in line with them. Tom=20 On Jun 6, 2012, at 2:11 AM, Stewart Bryant wrote: > On 04/06/2012 16:38, Thomas Nadeau wrote: >> Being encumbered by IPR can mean a number of things. I am ok with havi= ng IPR claims for any of the solutions, as long as they agree to the IETF's n= ormal licensing requirements. I am not in favor of adopting any solutions th= at do not follow these requirements. >>=20 >> --Tom > Tom >=20 > It is inappropriate to discuss license terms, or to pressure an IPR holder= to change their license terms on this list. >=20 > Stewart >=20 >=20 >=20 From wwwrun@rfc-editor.org Mon Jun 11 15:48:32 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14A611E80AD; Mon, 11 Jun 2012 15:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 rZv1CaxS2XRi; Mon, 11 Jun 2012 15:48:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2411E80B1; Mon, 11 Jun 2012 15:48:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E5979B1E00E; Mon, 11 Jun 2012 15:48:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6575 on Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs From: rfc-editor@rfc-editor.org Message-Id: <20120611224820.E5979B1E00E@rfc-editor.org> Date: Mon, 11 Jun 2012 15:48:20 -0700 (PDT) Cc: l2vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 22:48:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6575 Title: Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs Author: H. Shah, Ed., E. Rosen, Ed., G. Heron, Ed., V. Kompella, Ed. Status: Standards Track Stream: IETF Date: June 2012 Mailbox: hshah@ciena.com, erosen@cisco.com, giheron@cisco.com, vach.kompella@alcatel-lucent.com Pages: 28 Characters: 65881 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-arp-mediation-19.txt URL: http://www.rfc-editor.org/rfc/rfc6575.txt The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet or both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. [STANDARDS-TRACK] This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From yuqun.cao@gmail.com Mon Jun 11 23:19:42 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3001421F85AD for ; Mon, 11 Jun 2012 23:19:42 -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_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNFPUC+JaLAW for ; Mon, 11 Jun 2012 23:19:40 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4C221F85A3 for ; Mon, 11 Jun 2012 23:19:40 -0700 (PDT) Received: by dacx6 with SMTP id x6so6390117dac.31 for ; Mon, 11 Jun 2012 23:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :x-mimeole:in-reply-to; bh=PNFKu7b3T0DqhIoXlPn/miRI5SID9UqoylCm2RCupvU=; b=0B9bAkBTSwOy/8D82hAzmFF5+MoPBjmtg2otgwr40jwDMJnvI1YlGY77Zkg10gOl5E 3TRO+58aD9NoBmuqozKYjTWNZt/JaBPa5cYZIFWs3bWnY3liwKj/wK/MjHFwIPyLzkI5 m+9T6V3RQxzpygzAD+5UbHr75UYdejMLZqh24I3SRS7L07yvjIjg5Ae8lRvrFLecTC99 6GOssWk9N6L2b1vljo1GPDpYQ1hwxUg+cPemz2c1AcQsAEs2DM7eAQKXkJfBaZj5fXbC 4kn9AuDBaAeNzyqOymcRIfFfaG9dUA1iquQb+ZfxwKnP5nAmiLhok1S105A6wMaT5RM5 +Vrg== Received: by 10.68.236.129 with SMTP id uu1mr34952683pbc.77.1339481979999; Mon, 11 Jun 2012 23:19:39 -0700 (PDT) Received: from R01842 ([110.90.119.113]) by mx.google.com with ESMTPS id sy3sm924314pbc.18.2012.06.11.23.19.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 23:19:38 -0700 (PDT) From: "Sam Cao" To: "'David Allan I'" , "'Lucy yong'" , "'Balus, Florin Stelian \(Florin\)'" , "'Jiangyuanlong'" , "'Daniel Cohn'" , "'Alexander Vainshtein'" References: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D411694@szxeml546-mbx.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF5C@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D4130E1@szxeml546-mbs.china.huawei.com> <44F4E579A764584EA9BDFD07D0CA08130780CF8F@tlvmail1> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413216@szxeml546-mbs.china.huawei.com> <3F1F3739E2B04D399CC7D26CE934F91A@v2comsam> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413694@szxeml546-mbs.china.huawei.com> <7A564821DF1642E592E884D5C623772C@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D41370E@szxeml546-mbs.china.huawei.com> <400D5D93E6AA4075861CE09919D84747@R01842> <3B0A1BED22CAD649A1B3E97BE5DDD68B1D413741@szxeml546-mbs.china.huawei.com> <7BDA456234D045E1BD42EA059A4E9579@v2comsam> <2073A6C5467C99478898544C6EBA3F4602C1907568@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <60C093A41B5E45409A19D42CF7786DFD52328D98DF@EUSAACMS0703.eamcs.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D33108DD9@dfweml506-m bx> <1A7E043E03FF48A 2B3E5ECCD4F124B4C@R01842> <60C093A41B5E45409A19D42CF7786DFD5232948CBE@EUSAACMS0703.eamcs.ericsson.se> Subject: RE: Discussion on forwarding performance Date: Tue, 12 Jun 2012 14:19:36 +0800 Message-ID: <99077FDD8A2F4DAC83EBD3CEC0159673@R01842> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AQHNLxo31u2OjZw96UuBF9QPOwJXg5bHcLkAgAGHLZCAAAmjYIAAHGPggAAUqSCAAOHDIIAAM7tggAAlyMCAADHVIIAAElJAgAAmSSCAAGzc8IAABagAgAAFRDCAAFXG8IAA+RMggCnFb6A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5232948CBE@EUSAACMS0703.eamcs.ericsson.se> Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 06:19:42 -0000 Dave and all, Sorry for later reply and thank you very much for your comments. Based on your comments I assume you believe that the scope of the S-tag is only the PW section, so it is imposed by the ingress PE and removed by the egress PE? [Sam] Yes. My understanding on this is, yes. Or just as Yuanlong said, VLAN mapping (S-tag is imposed by ingress PE) may be processed on a logical port. And you would prefer recreating an S-tag if an egress PE had a subtending PBN and stripping it if it in is an ingress from a PBN? [Sam] Dave, no, my understanding is, VLAN ID (Or S-tag you said) is useful and negotiated between ingress PE and egress PE. If it is striped out, egress PE will forward the frame to the corresponding ACs. So don't need to recreate new S-tag. Sam -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Thursday, May 17, 2012 12:21 AM To: Sam Cao; 'Lucy yong'; 'Balus, Florin Stelian (Florin)'; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Hi Sam: Thanks for explaining your reasoning, this is useful. Based on your comments I assume you believe that the scope of the S-tag is only the PW section, so it is imposed by the ingress PE and removed by the egress PE? And you would prefer recreating an S-tag if an egress PE had a subtending PBN and stripping it if it in is an ingress from a PBN? So this has little to do with ETREE itself, but tag interworking with a PBN or not? Thanks Dave -----Original Message----- From: Sam Cao [mailto:yuqun.cao@gmail.com] Sent: Tuesday, May 15, 2012 7:09 PM To: 'Lucy yong'; David Allan I; 'Balus, Florin Stelian (Florin)'; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Lucy/David/Florin, Thank you very much for your comments. I can not give the accurate data to support my conclusion, and just conclude that if we implement it in NP module. Except for common operations of 2 approaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., Dual-VLAN needs one more VLAN push/pop-out operation while forwarding every frame. So compared with Multi-PW, it needs more resource and time for NP module if there are VSIs or PWs up limit to the capacity on one PE, and standing on software architect's side, the performance will be decreased by at least 20%, I guess. I implemented one prototype which has similar solution as current Multi-PW, and the performance will be decreased by 5%, compared with traditional VPLS. Daniel has experience on 2-PW deployment, maybe he can give accurate data on Multi-PW. Florin, do you mean that you have implemented E-Tree in MPLS network? If chipset can support this and we don't care NP or other solutions, yes, we can ignore any side effect on forwarding performance. Yes, it can support E-tree in IP (Ethernet) network, but I read some CHIP datasheets, after strip PW label out, chip can not handle 2 VLAN IDs at same time. Could you please give me some hints, say, which chip you used? Maybe if we raised only one issue in one mail, we can get more and insight comments :). I will raise another after we agree with this in the main :). Thanks, Sam -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, May 16, 2012 4:15 AM To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance +1 We can't just make a conclusion from nowhere. Lucy -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of David Allan I Sent: Tuesday, May 15, 2012 2:55 PM To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Florin: I agree. The statement, at least to me, is a non-sequitor... Cheers Dave -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Balus, Florin Stelian (Florin) Sent: Tuesday, May 15, 2012 12:53 PM To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: RE: Discussion on forwarding performance Sam, > Obviously the forwarding performance of Dual-VLAN will be much lower > than what of Multi-PW. Sorry I could not keep up with some of the threads on this subject but the above statement caught my eyes. We have been doing all kind of egress operations on VLANs in the egress PE for the last 8 years and I am not aware of any "much lower" forwarding performance. As far as I know the chipsets used in the PEs can do this processing no problem. Do you want to clarify which kind of hardware may have problems? > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Sam Cao > Sent: Tuesday, May 15, 2012 6:32 AM > To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on forwarding performance > > Hi Yuanlong, > > 3rd mapping will make data plane complex, I think. Anyway, we reached > a consensus on Multi-PW implementation. > > If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN > seems simple, but 2 mapping is enough. Then we can focus on data plane > performance. While stripe PW label out on egress PE, data-plane knows > how to forward the frames from PW, to Root AC or Leaf AC or all. But > if we use Dual-VLAN, after strip PW label out, data plane should strip > VLAN-ID out and then does same forwarding work as Multi-PW does. The > most important is, do one more operation while forwarding E-Tree > frames. Obviously the forwarding performance of Dual-VLAN will be much > lower than what of Multi-PW. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 7:03 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > See my further comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Tuesday, May 15, 2012 6:14 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Thank you very much for your comments. I draw the topology you gave, > and 7 PWs will be established if we follow 01. > > Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC > | \ / || > | \ /===PW 6,7=== || > PW 2 -----PW 5------\ || > | /----Root PW 3 --- \ || > Root _AC ---- PE 3 PE 4 ------ Root AC > | \ / | > | ----Leaf PW 4----- | > Leaf AC Leaf AC > Yes, on PE 3 there are several PWs, but if you want to clarify it, > there are only 3 types, one can carry frames originated from Root and > Leaf AC(one endpoint of this PW should be Root-only, otherwise this is > invalid), one only can carry frames from Root AC, and the last can > carry frames from Leaf ACs. On second thoughts, we still can classify > the PWs into 2 sets, one is Leaf set, and another is Root set, and the > union of the sets Leaf and Root is the PW we called it as compatible > PW (Maybe this is not correct, we can find one good term on this). > > So this optimization still follows the original design of Dual-PW > approach, Leaf PW only carries frames from Leaf AC; Root-PW only > carries frames from Root AC. Is it right? > > I don't know whether chip can support this forwarding behavior for > compatible PW or not, but if we implement it in NP, it is nearly same > as VPLS. The only difference is, setup 2 mappings, one between > Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For > traditional VPLS, there is only one mapping. > > [JY] It seems you may need a 3rd mapping: from both root & leaf AC to > a compatible PW. > BTW, for the forwarding and reverse direction, the mapping may be > asymmetric for you compatible PW. > > Based on my understanding, all drafts should have similar mapping. > > [JY] Dual-VLAN seems simpler here. > > Thanks, > > Sam > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 3:32 PM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, > > Thanks, please see my further comments with [JY]. > > Ok, we go on the case in your mail, where PE1 has one Root-only AC, > AC1, and > PE2 has one Leaf-only AC, AC2. In general we can setup 2 > "unidirectional" > PWs (bidirectional PW, but just carry unidirectional frames), Root-PW > which carries frames originated from AC1 and Leaf-PW which carries > frames originated from AC2. But only one PW also can work, just as > some members commented. Ok, we setup one PW between PE1 and PE2, we > can call this PW as compatible PW or something else. Frames originated > from Root or leaf ACs will be carried via this PW. Its forwarding > behavior is fully same as what traditional VPLS did, MAC learning on > AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will > setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. > If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be > established. As you know, this can be done on control plane. > > [JY] Assume there are 2 other nodes PE3 & PE4 in this network > scenario, and both PE3 and PE4 have both root and leaf ACs, then there > are compatible PWs from PE3 which may carry both root and leaf traffic > (to PE1), which may carry only root traffic (to PE2); and further > there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at > least 4 different types of PW transmitting behaviours with regard to > the E-Tree traffic. In the reverse direction, the VSI on PE3 further > has at least > 4 different types of PW receiving behaviours. Not sure how you will > accommodate for these PWs in both the data plane and control plane. > > Regards, > Yuanlong > > Is this clear for you? Is this necessary to optimize PW setup in this > case? > > Maybe we need to add one paragraph on forwarding behavior. > > Again thank you very much for your comments, > > Sam > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Tuesday, May 15, 2012 10:27 AM > To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Please see my comments in line. > > -----Original Message----- > From: Sam Cao [mailto:yuqun.cao@gmail.com] > Sent: Monday, May 14, 2012 8:31 PM > To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > We have discussed this in another thread. In fact, Daniel or I have > given the answers to the questions you raised here for several time :). > If we do in this way, we will reach deadlock and can not move forward > :). I try to explain it again. > > [JY] I will apologize if you had ever provided such answers before, > and you may just refer to the links rather than repeat the explanation. > As you can see, I just try to understand the mechanism of 2PW and its > implications, but the I-D does not include enough information. > > As you know, initial design we will setup 2 PWs all the time (if do in > this way, I think that you have no question), > > [JY] I will be concerned with the operational complexity of this > approach. > > but in most cases 2 PWs are not > necessary. So in 01 version, we optimize it. > > "Root-only VSI <-> any VSI: only root PW required" > "Leaf-only VSI <-> leaf-only VSI: no PWs required" > > In other cases 2 PWs are needed. If so, "Leaf-only -> root-only = one > leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is > created between Local Leaf type with remote Root type; on root-only > side, one root-only PW is created. Maybe it is better to call this as > compatible or mixed PW. So the left items you list are not correct for > multi_PW solution. > > [JY] This is something new, right? To be honest, I could not > understand what is your point: doesn't the mixed PW as you called also > consist of one Leaf-only PW in one direction and one root-only PW in > the other direction? > Furthermore, the case you took is also one case in your guideline > "Root-only VSI <-> any VSI: only root PW required", don't you think > that only one root PW is required following this guideline? > Actually, I don't care much about what is the bidirectional PW or > unidirectional PW called, but how can a VSI support such a mixed > scenarios: > traditional VSI assumes only one PW is required for each peer VSI, and > its MAC leaning is based on bidirectional PW. But for 2PW, there are > bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to > support these kinds of PWs in the same VSI is my top concern. > > BTW, I guess you also care this case we also have discussed before: > for example, if we configure one Leaf AC on root-only PE (then it will > be root-leaf-mixed PE), we will teardown the compatible PW and > re-setup PWs again with 01. > [JY] This was discussed in the emails indeed. > > Regards, > > Yuqun (Sam) Cao > E-mail: Yuqun.cao@gmail.com > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 7:10 PM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel, > > Fine, now it seems more in line with what we had proposed in 2VLAN: a > spoke PW behaves like root/leaf AC for a PE-r. > > But the same problem may also apply to the root/spoke "core PW" for > Multi-PW: > According to Multi-PW, only one PW is required between two PEs except > when both PEs are mixed with root and leaf, so these PWs may be formed > by combinations of the following unidirectional PW cases (extracted > and adapted from Josh's email): > Root-only -> any VSI = one root PW > Leaf-only -> root-only = one leaf PW > Leaf-only -> mixed = one leaf PW > Mixed -> root-only = one (root+leaf) PW Mixed -> leaf-only = one > (root+leaf) PW > > I have a concern that the forwarding plane of PE to implement this > will be very different from the traditional VPLS. > > Regards, > Yuanlong > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 5:00 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not > like root/spoke "core PW". So no changes to forwarding plane once this > is understood. > > DC > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Monday, May 14, 2012 11:36 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Daniel, please see my comments in line. > > -----Original Message----- > From: Daniel Cohn [mailto:DanielC@orckit.com] > Sent: Monday, May 14, 2012 3:37 PM > To: Jiangyuanlong; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Yuanlong, > > As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a > single PW per AC - root PW for root AC and leaf PW for leaf AC. With > local configuration at the PE-rs as part of the spoke PW provisioning. > And the PE-rs will treat root/leaf spoke PWs exactly as it treat > root/leaf ACs. So when leaf-originated BUM traffic arrives from the > core (over a leaf PW), it will be forwarded over all root spoke PWs > but not on the leaf spoke PWs. > > [JY] So in the reverse direction, you need to transport both root and > leaf traffic from PE-rs over a root PW to PE-r, and transport root > traffic over a leaf PW. It seems against the definition of root PW and > leaf PW in the multi-PW draft. Don't this make the forwarding plane of > PE-rs more complex? > > The forwarding plane is exactly the same as described in the multi-PW > draft, where spoke PWs are treated exactly like ACs. > > Regards, > > Daniel > > > -----Original Message----- > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] > Sent: Friday, May 11, 2012 5:03 AM > To: Daniel Cohn; Alexander Vainshtein; Sam Cao > Cc: l2vpn@ietf.org > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Daniel and all, > > When you set up two PWs from the PE-rs to a PE-r for each of its AC, > do you mean that one PW is bidirectional root PW and the other is > bidirectional leaf PW? > My concern is: where should the leaf traffic be filtered, on the PE-rs > or on the PE-r? > If filtered on the PE-r, then lots of bandwidth will be wasted (for > example, if the PE-r is attached with 9 leafs, then the BUM traffic > from one of its leafs will be multiplied by 8 times, and be forwarded > by the PE-rs to the same PE-r). > If filtered on the PE-rs, not sure how you will design its forwarding > plane, can you give a hint? > > Thanks, > Yuanlong > > ------------------------------ > Date: Wed, 9 May 2012 09:16:36 +0300 > From: "Daniel Cohn" > To: "Alexander Vainshtein" , "Sam > Cao" , > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> > Content-Type: text/plain; charset="ISO-2022-JP" > > Hi Sasha, > > It's actually very simple. A frame that originated in a root AC is > always transmitted only in root PW, no matter what the frame type > (known/unknown unicast or broadcast). This is how the frame source > information is propagated across the VPLS. So in the H-VPLS example, > the PE-r will never forward a frame received over a root PW on any > leaf PW, only on root PWs (toward the core or toward other spokes). > > Hope this clarifies it, regards, > > Daniel > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf > Of Alexander Vainshtein > Sent: Wednesday, May 09, 2012 7:59 AM > To: Sam Cao; l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Sam, Lizhong and all, > You've written that in the two-PW solution combined with H-VPLS the > PE- r must set up two PWs with each MTU-s. > > If this is the case, what kind of forwarding logic should be used to > prevent sending a BUM frame received from a root-PW to a given MTU-S: > - back to the same MTU-S on the corresponding leaf-PW? > - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how > is the PW selected in this case? > > I am aware of a technique of multiple split horizon groups in PE-r > which could be possibly used for this purpose. However, since these > groups have to be represented explicitly in the data plane, their > potential number is limited by the forwarding HW. Other methods could > be probably used for the same purpose, but they would probably subject > to similar HW-based limitations. > > I suspect that with the dual-PW approach, the HW would pose an > implicit limit, say, on a number of MTU-s that can be connected to the > same PE-r and that this limit could be quite low in most cases. > > Based on this I suspect that the H-VPLS issue as a critical drawback > of the dual-PW approach to E-Tree. > > My 2c, > Sasha > > > ________________________________________ > From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam > Cao [yuqun.cao@gmail.com] > Sent: Wednesday, May 09, 2012 3:40 AM > To: l2vpn@ietf.org > Cc: lizhong.jin@zte.com.cn > Subject: RE: Discussion on E-Tree and H-VPLS > > Hi Lizhong? > > Thank you very much for your comments. I updated the result on this > question. > > [Lizhong] agree with the above analysis. And we did not say it is a > technical problem, but it is an operational problem again. > [Sam] I agree. Dual-VLAN does not make sense. I also discussed this > with Giles and Yuanlong in another mail, and we reached agreement on > this: > MTU should know the access mode, VPWS or VPLS, VPWS mode should > configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT > reasonable :), but we can figure this out in draft. It seems ok. > > [Lizhong] not fully understand. Do you mean, when VPWS accessing for > H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf > PW) for each AC access? > [Sam] Yes. > > Thanks, > > Sam > > > > From josh.rogers@twcable.com Tue Jun 12 05:52:41 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF81721F84A5 for ; Tue, 12 Jun 2012 05:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvtbe7WkYsnp for ; Tue, 12 Jun 2012 05:52:40 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id DC01621F8497 for ; Tue, 12 Jun 2012 05:52:39 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="377218446" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Jun 2012 08:52:01 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 12 Jun 2012 08:52:39 -0400 From: "Rogers, Josh" To: Sam Cao , 'David Allan I' , 'Lucy yong' , "'Balus, Florin Stelian (Florin)'" , 'Jiangyuanlong' , 'Daniel Cohn' , 'Alexander Vainshtein' Date: Tue, 12 Jun 2012 08:52:38 -0400 Subject: Re: ETREE Methods - Discussion on forwarding performance Thread-Topic: ETREE Methods - Discussion on forwarding performance Thread-Index: Ac1Imj6fFBCSlnS9QD20aESa0KEJ/g== Message-ID: In-Reply-To: <99077FDD8A2F4DAC83EBD3CEC0159673@R01842> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 12:52:41 -0000 I was under the impression that multi-pw method supported both ethernet tagged mode (0x0004), and ethernet raw mode (0x0005), where 2vlan supported only ethernet tagged mode (0x0004) ? Is that correct? On 6/12/12 1:19 AM, "Sam Cao" wrote: >Dave and all, > >Sorry for later reply and thank you very much for your comments. > >Based on your comments I assume you believe that the scope of the S-tag is >only the PW section, so it is imposed by the ingress PE and removed by the >egress PE? >[Sam] Yes. My understanding on this is, yes. Or just as Yuanlong said, >VLAN >mapping (S-tag is imposed by ingress PE) may be processed on a logical >port. > >And you would prefer recreating an S-tag if an egress PE had a subtending >PBN and stripping it if it in is an ingress from a PBN? >[Sam] Dave, no, my understanding is, VLAN ID (Or S-tag you said) is useful >and negotiated between ingress PE and egress PE. If it is striped out, >egress PE will forward the frame to the corresponding ACs. So don't need >to >recreate new S-tag. > >Sam > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: Thursday, May 17, 2012 12:21 AM >To: Sam Cao; 'Lucy yong'; 'Balus, Florin Stelian (Florin)'; >'Jiangyuanlong'; >'Daniel Cohn'; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Hi Sam: > >Thanks for explaining your reasoning, this is useful. > >Based on your comments I assume you believe that the scope of the S-tag is >only the PW section, so it is imposed by the ingress PE and removed by the >egress PE? > >And you would prefer recreating an S-tag if an egress PE had a subtending >PBN and stripping it if it in is an ingress from a PBN? > >So this has little to do with ETREE itself, but tag interworking with a >PBN >or not? > >Thanks >Dave > >-----Original Message----- >From: Sam Cao [mailto:yuqun.cao@gmail.com] >Sent: Tuesday, May 15, 2012 7:09 PM >To: 'Lucy yong'; David Allan I; 'Balus, Florin Stelian (Florin)'; >'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Lucy/David/Florin, > >Thank you very much for your comments. > >I can not give the accurate data to support my conclusion, and just >conclude >that if we implement it in NP module. Except for common operations of 2 >approaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., >Dual-VLAN needs one more VLAN push/pop-out operation while forwarding >every >frame. So compared with Multi-PW, it needs more resource and time for NP >module if there are VSIs or PWs up limit to the capacity on one PE, and >standing on software architect's side, the performance will be decreased >by >at least 20%, I guess. I implemented one prototype which has similar >solution as current Multi-PW, and the performance will be decreased by 5%, >compared with traditional VPLS. Daniel has experience on 2-PW deployment, >maybe he can give accurate data on Multi-PW. > >Florin, do you mean that you have implemented E-Tree in MPLS network? If >chipset can support this and we don't care NP or other solutions, yes, we >can ignore any side effect on forwarding performance. Yes, it can support >E-tree in IP (Ethernet) network, but I read some CHIP datasheets, after >strip PW label out, chip can not handle 2 VLAN IDs at same time. Could you >please give me some hints, say, which chip you used? > >Maybe if we raised only one issue in one mail, we can get more and insight >comments :). I will raise another after we agree with this in the main :). > >Thanks, > >Sam > > >-----Original Message----- >From: Lucy yong [mailto:lucy.yong@huawei.com] >Sent: Wednesday, May 16, 2012 4:15 AM >To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; >'Daniel Cohn'; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >+1 > >We can't just make a conclusion from nowhere. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Tuesday, May 15, 2012 2:55 PM >To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; >'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Florin: > >I agree. The statement, at least to me, is a non-sequitor... > >Cheers >Dave > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Balus, Florin Stelian (Florin) >Sent: Tuesday, May 15, 2012 12:53 PM >To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Sam, > >> Obviously the forwarding performance of Dual-VLAN will be much lower >> than >what of Multi-PW. > >Sorry I could not keep up with some of the threads on this subject but the >above statement caught my eyes. We have been doing all kind of egress >operations on VLANs in the egress PE for the last 8 years and I am not >aware >of any "much lower" forwarding performance. As far as I know the chipsets >used in the PEs can do this processing no problem. Do you want to clarify >which kind of hardware may have problems? > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Sam Cao >> Sent: Tuesday, May 15, 2012 6:32 AM >> To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on forwarding performance >> >> Hi Yuanlong, >> >> 3rd mapping will make data plane complex, I think. Anyway, we reached >> a consensus on Multi-PW implementation. >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN >> seems simple, but 2 mapping is enough. Then we can focus on data plane >> performance. While stripe PW label out on egress PE, data-plane knows >> how to forward the frames from PW, to Root AC or Leaf AC or all. But >> if we use Dual-VLAN, after strip PW label out, data plane should strip >> VLAN-ID out and then does same forwarding work as Multi-PW does. The >> most important is, do one more operation while forwarding E-Tree >> frames. Obviously the forwarding performance of Dual-VLAN will be much >> lower than what of Multi-PW. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 7:03 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> See my further comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Tuesday, May 15, 2012 6:14 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Thank you very much for your comments. I draw the topology you gave, >> and 7 PWs will be established if we follow 01. >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC >> | \ / || >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || >> PW 2 -----PW 5------\ || >> | /----Root PW 3 --- \ || >> Root _AC ---- PE 3 PE 4 ------ Root AC >> | \ / | >> | ----Leaf PW 4----- | >> Leaf AC Leaf AC >> Yes, on PE 3 there are several PWs, but if you want to clarify it, >> there are only 3 types, one can carry frames originated from Root and >> Leaf AC(one endpoint of this PW should be Root-only, otherwise this is >> invalid), one only can carry frames from Root AC, and the last can >> carry frames from Leaf ACs. On second thoughts, we still can classify >> the PWs into 2 sets, one is Leaf set, and another is Root set, and the >> union of the sets Leaf and Root is the PW we called it as compatible >> PW (Maybe this is not correct, we can find one good term on this). >> >> So this optimization still follows the original design of Dual-PW >> approach, Leaf PW only carries frames from Leaf AC; Root-PW only >> carries frames from Root AC. Is it right? >> >> I don't know whether chip can support this forwarding behavior for >> compatible PW or not, but if we implement it in NP, it is nearly same >> as VPLS. The only difference is, setup 2 mappings, one between >> Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For >> traditional VPLS, there is only one mapping. >> >> [JY] It seems you may need a 3rd mapping: from both root & leaf AC to >> a compatible PW. >> BTW, for the forwarding and reverse direction, the mapping may be >> asymmetric for you compatible PW. >> >> Based on my understanding, all drafts should have similar mapping. >> >> [JY] Dual-VLAN seems simpler here. >> >> Thanks, >> >> Sam >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 3:32 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, >> >> Thanks, please see my further comments with [JY]. >> >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, >> AC1, and >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 >> "unidirectional" >> PWs (bidirectional PW, but just carry unidirectional frames), Root-PW >> which carries frames originated from AC1 and Leaf-PW which carries >> frames originated from AC2. But only one PW also can work, just as >> some members commented. Ok, we setup one PW between PE1 and PE2, we >> can call this PW as compatible PW or something else. Frames originated >> from Root or leaf ACs will be carried via this PW. Its forwarding >> behavior is fully same as what traditional VPLS did, MAC learning on >> AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will >> setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. >> If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be >> established. As you know, this can be done on control plane. >> >> [JY] Assume there are 2 other nodes PE3 & PE4 in this network >> scenario, and both PE3 and PE4 have both root and leaf ACs, then there >> are compatible PWs from PE3 which may carry both root and leaf traffic >> (to PE1), which may carry only root traffic (to PE2); and further >> there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at >> least 4 different types of PW transmitting behaviours with regard to >> the E-Tree traffic. In the reverse direction, the VSI on PE3 further >> has at least >> 4 different types of PW receiving behaviours. Not sure how you will >> accommodate for these PWs in both the data plane and control plane. >> >> Regards, >> Yuanlong >> >> Is this clear for you? Is this necessary to optimize PW setup in this >> case? >> >> Maybe we need to add one paragraph on forwarding behavior. >> >> Again thank you very much for your comments, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 10:27 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Please see my comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Monday, May 14, 2012 8:31 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> We have discussed this in another thread. In fact, Daniel or I have >> given the answers to the questions you raised here for several time :). >> If we do in this way, we will reach deadlock and can not move forward >> :). I try to explain it again. >> >> [JY] I will apologize if you had ever provided such answers before, >> and you may just refer to the links rather than repeat the explanation. >> As you can see, I just try to understand the mechanism of 2PW and its >> implications, but the I-D does not include enough information. >> >> As you know, initial design we will setup 2 PWs all the time (if do in >> this way, I think that you have no question), >> >> [JY] I will be concerned with the operational complexity of this >> approach. >> >> but in most cases 2 PWs are not >> necessary. So in 01 version, we optimize it. >> >> "Root-only VSI <-> any VSI: only root PW required" >> "Leaf-only VSI <-> leaf-only VSI: no PWs required" >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one >> leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is >> created between Local Leaf type with remote Root type; on root-only >> side, one root-only PW is created. Maybe it is better to call this as >> compatible or mixed PW. So the left items you list are not correct for >> multi_PW solution. >> >> [JY] This is something new, right? To be honest, I could not >> understand what is your point: doesn't the mixed PW as you called also >> consist of one Leaf-only PW in one direction and one root-only PW in >> the other direction? >> Furthermore, the case you took is also one case in your guideline >> "Root-only VSI <-> any VSI: only root PW required", don't you think >> that only one root PW is required following this guideline? >> Actually, I don't care much about what is the bidirectional PW or >> unidirectional PW called, but how can a VSI support such a mixed >> scenarios: >> traditional VSI assumes only one PW is required for each peer VSI, and >> its MAC leaning is based on bidirectional PW. But for 2PW, there are >> bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to >> support these kinds of PWs in the same VSI is my top concern. >> >> BTW, I guess you also care this case we also have discussed before: >> for example, if we configure one Leaf AC on root-only PE (then it will >> be root-leaf-mixed PE), we will teardown the compatible PW and >> re-setup PWs again with 01. >> [JY] This was discussed in the emails indeed. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 7:10 PM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel, >> >> Fine, now it seems more in line with what we had proposed in 2VLAN: a >> spoke PW behaves like root/leaf AC for a PE-r. >> >> But the same problem may also apply to the root/spoke "core PW" for >> Multi-PW: >> According to Multi-PW, only one PW is required between two PEs except >> when both PEs are mixed with root and leaf, so these PWs may be formed >> by combinations of the following unidirectional PW cases (extracted >> and adapted from Josh's email): >> Root-only -> any VSI =3D one root PW >> Leaf-only -> root-only =3D one leaf PW >> Leaf-only -> mixed =3D one leaf PW >> Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one >> (root+leaf) PW >> >> I have a concern that the forwarding plane of PE to implement this >> will be very different from the traditional VPLS. >> >> Regards, >> Yuanlong >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 5:00 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not >> like root/spoke "core PW". So no changes to forwarding plane once this >> is understood. >> >> DC >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 11:36 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Daniel, please see my comments in line. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 3:37 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With >> local configuration at the PE-rs as part of the spoke PW provisioning. >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the >> core (over a leaf PW), it will be forwarded over all root spoke PWs >> but not on the leaf spoke PWs. >> >> [JY] So in the reverse direction, you need to transport both root and >> leaf traffic from PE-rs over a root PW to PE-r, and transport root >> traffic over a leaf PW. It seems against the definition of root PW and >> leaf PW in the multi-PW draft. Don't this make the forwarding plane of >> PE-rs more complex? >> >> The forwarding plane is exactly the same as described in the multi-PW >> draft, where spoke PWs are treated exactly like ACs. >> >> Regards, >> >> Daniel >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Friday, May 11, 2012 5:03 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel and all, >> >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, >> do you mean that one PW is bidirectional root PW and the other is >> bidirectional leaf PW? >> My concern is: where should the leaf traffic be filtered, on the PE-rs >> or on the PE-r? >> If filtered on the PE-r, then lots of bandwidth will be wasted (for >> example, if the PE-r is attached with 9 leafs, then the BUM traffic >> from one of its leafs will be multiplied by 8 times, and be forwarded >> by the PE-rs to the same PE-r). >> If filtered on the PE-rs, not sure how you will design its forwarding >> plane, can you give a hint? >> >> Thanks, >> Yuanlong >> >> ------------------------------ >> Date: Wed, 9 May 2012 09:16:36 +0300 >> From: "Daniel Cohn" >> To: "Alexander Vainshtein" , >>"Sam >> Cao" , >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> >> Content-Type: text/plain; charset=3D"ISO-2022-JP" >> >> Hi Sasha, >> >> It's actually very simple. A frame that originated in a root AC is >> always transmitted only in root PW, no matter what the frame type >> (known/unknown unicast or broadcast). This is how the frame source >> information is propagated across the VPLS. So in the H-VPLS example, >> the PE-r will never forward a frame received over a root PW on any >> leaf PW, only on root PWs (toward the core or toward other spokes). >> >> Hope this clarifies it, regards, >> >> Daniel >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: Wednesday, May 09, 2012 7:59 AM >> To: Sam Cao; l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, Lizhong and all, >> You've written that in the two-PW solution combined with H-VPLS the >> PE- r must set up two PWs with each MTU-s. >> >> If this is the case, what kind of forwarding logic should be used to >> prevent sending a BUM frame received from a root-PW to a given MTU-S: >> - back to the same MTU-S on the corresponding leaf-PW? >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how >> is the PW selected in this case? >> >> I am aware of a technique of multiple split horizon groups in PE-r >> which could be possibly used for this purpose. However, since these >> groups have to be represented explicitly in the data plane, their >> potential number is limited by the forwarding HW. Other methods could >> be probably used for the same purpose, but they would probably subject >> to similar HW-based limitations. >> >> I suspect that with the dual-PW approach, the HW would pose an >> implicit limit, say, on a number of MTU-s that can be connected to the >> same PE-r and that this limit could be quite low in most cases. >> >> Based on this I suspect that the H-VPLS issue as a critical drawback >> of the dual-PW approach to E-Tree. >> >> My 2c, >> Sasha >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam >> Cao [yuqun.cao@gmail.com] >> Sent: Wednesday, May 09, 2012 3:40 AM >> To: l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Lizhong? >> >> Thank you very much for your comments. I updated the result on this >> question. >> >> [Lizhong] agree with the above analysis. And we did not say it is a >> technical problem, but it is an operational problem again. >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this >> with Giles and Yuanlong in another mail, and we reached agreement on >> this: >> MTU should know the access mode, VPWS or VPLS, VPWS mode should >> configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT >> reasonable :), but we can figure this out in draft. It seems ok. >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing for >> H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf >> PW) for each AC access? >> [Sam] Yes. >> >> Thanks, >> >> Sam >> >> >> >> > > > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jiangyuanlong@huawei.com Tue Jun 12 18:45:38 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FED321F86FD for ; Tue, 12 Jun 2012 18:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 H37oS+A7sqg9 for ; Tue, 12 Jun 2012 18:45:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 421B921F861F for ; Tue, 12 Jun 2012 18:45:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHD20544; Tue, 12 Jun 2012 21:45:35 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 12 Jun 2012 18:42:53 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 12 Jun 2012 18:42:56 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 13 Jun 2012 09:42:41 +0800 From: Jiangyuanlong To: "Rogers, Josh" , Sam Cao , 'David Allan I' , Lucy yong , "'Balus, Florin Stelian (Florin)'" , 'Daniel Cohn' , 'Alexander Vainshtein' Subject: RE: ETREE Methods - Discussion on forwarding performance Thread-Topic: ETREE Methods - Discussion on forwarding performance Thread-Index: AQHNMp8ego9/CtMoakapN2JoMtGUPZbKvTGAgAAAzYCAAAV4AIAAYvAAgADt5QCAKccIAIAAbdAAgAFWXZA= Date: Wed, 13 Jun 2012 01:42:40 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D416FB2@szxeml546-mbs.china.huawei.com> References: <99077FDD8A2F4DAC83EBD3CEC0159673@R01842> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 01:45:38 -0000 For some special scenarios, Dual-VLAN may use a PW in raw mode. For example= , when the PE is working in Compatible mode. -----Original Message----- From: Rogers, Josh [mailto:josh.rogers@twcable.com]=20 Sent: Tuesday, June 12, 2012 8:53 PM To: Sam Cao; 'David Allan I'; Lucy yong; 'Balus, Florin Stelian (Florin)'; = Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' Cc: l2vpn@ietf.org Subject: Re: ETREE Methods - Discussion on forwarding performance I was under the impression that multi-pw method supported both ethernet tagged mode (0x0004), and ethernet raw mode (0x0005), where 2vlan supported only ethernet tagged mode (0x0004) ? Is that correct? On 6/12/12 1:19 AM, "Sam Cao" wrote: >Dave and all, > >Sorry for later reply and thank you very much for your comments. > >Based on your comments I assume you believe that the scope of the S-tag is >only the PW section, so it is imposed by the ingress PE and removed by the >egress PE? >[Sam] Yes. My understanding on this is, yes. Or just as Yuanlong said, >VLAN >mapping (S-tag is imposed by ingress PE) may be processed on a logical >port. > >And you would prefer recreating an S-tag if an egress PE had a subtending >PBN and stripping it if it in is an ingress from a PBN? >[Sam] Dave, no, my understanding is, VLAN ID (Or S-tag you said) is useful >and negotiated between ingress PE and egress PE. If it is striped out, >egress PE will forward the frame to the corresponding ACs. So don't need >to >recreate new S-tag. > >Sam > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: Thursday, May 17, 2012 12:21 AM >To: Sam Cao; 'Lucy yong'; 'Balus, Florin Stelian (Florin)'; >'Jiangyuanlong'; >'Daniel Cohn'; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Hi Sam: > >Thanks for explaining your reasoning, this is useful. > >Based on your comments I assume you believe that the scope of the S-tag is >only the PW section, so it is imposed by the ingress PE and removed by the >egress PE? > >And you would prefer recreating an S-tag if an egress PE had a subtending >PBN and stripping it if it in is an ingress from a PBN? > >So this has little to do with ETREE itself, but tag interworking with a >PBN >or not? > >Thanks >Dave > >-----Original Message----- >From: Sam Cao [mailto:yuqun.cao@gmail.com] >Sent: Tuesday, May 15, 2012 7:09 PM >To: 'Lucy yong'; David Allan I; 'Balus, Florin Stelian (Florin)'; >'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Lucy/David/Florin, > >Thank you very much for your comments. > >I can not give the accurate data to support my conclusion, and just >conclude >that if we implement it in NP module. Except for common operations of 2 >approaches, Tunnel Label push/pop-out, MAC-based forwarding, and etc., >Dual-VLAN needs one more VLAN push/pop-out operation while forwarding >every >frame. So compared with Multi-PW, it needs more resource and time for NP >module if there are VSIs or PWs up limit to the capacity on one PE, and >standing on software architect's side, the performance will be decreased >by >at least 20%, I guess. I implemented one prototype which has similar >solution as current Multi-PW, and the performance will be decreased by 5%, >compared with traditional VPLS. Daniel has experience on 2-PW deployment, >maybe he can give accurate data on Multi-PW. > >Florin, do you mean that you have implemented E-Tree in MPLS network? If >chipset can support this and we don't care NP or other solutions, yes, we >can ignore any side effect on forwarding performance. Yes, it can support >E-tree in IP (Ethernet) network, but I read some CHIP datasheets, after >strip PW label out, chip can not handle 2 VLAN IDs at same time. Could you >please give me some hints, say, which chip you used? > >Maybe if we raised only one issue in one mail, we can get more and insight >comments :). I will raise another after we agree with this in the main :). > >Thanks, > >Sam > > >-----Original Message----- >From: Lucy yong [mailto:lucy.yong@huawei.com] >Sent: Wednesday, May 16, 2012 4:15 AM >To: David Allan I; Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; >'Daniel Cohn'; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >+1 > >We can't just make a conclusion from nowhere. > >Lucy > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Tuesday, May 15, 2012 2:55 PM >To: Balus, Florin Stelian (Florin); Sam Cao; Jiangyuanlong; 'Daniel Cohn'; >'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Florin: > >I agree. The statement, at least to me, is a non-sequitor... > >Cheers >Dave > >-----Original Message----- >From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of >Balus, Florin Stelian (Florin) >Sent: Tuesday, May 15, 2012 12:53 PM >To: Sam Cao; 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >Cc: l2vpn@ietf.org >Subject: RE: Discussion on forwarding performance > >Sam, > >> Obviously the forwarding performance of Dual-VLAN will be much lower >> than >what of Multi-PW. > >Sorry I could not keep up with some of the threads on this subject but the >above statement caught my eyes. We have been doing all kind of egress >operations on VLANs in the egress PE for the last 8 years and I am not >aware >of any "much lower" forwarding performance. As far as I know the chipsets >used in the PEs can do this processing no problem. Do you want to clarify >which kind of hardware may have problems? > >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Sam Cao >> Sent: Tuesday, May 15, 2012 6:32 AM >> To: 'Jiangyuanlong'; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on forwarding performance >> >> Hi Yuanlong, >> >> 3rd mapping will make data plane complex, I think. Anyway, we reached >> a consensus on Multi-PW implementation. >> >> If we use 3rd mapping, I agree with your opinion, maybe dual-VLAN >> seems simple, but 2 mapping is enough. Then we can focus on data plane >> performance. While stripe PW label out on egress PE, data-plane knows >> how to forward the frames from PW, to Root AC or Leaf AC or all. But >> if we use Dual-VLAN, after strip PW label out, data plane should strip >> VLAN-ID out and then does same forwarding work as Multi-PW does. The >> most important is, do one more operation while forwarding E-Tree >> frames. Obviously the forwarding performance of Dual-VLAN will be much >> lower than what of Multi-PW. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 7:03 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> See my further comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Tuesday, May 15, 2012 6:14 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Thank you very much for your comments. I draw the topology you gave, >> and 7 PWs will be established if we follow 01. >> >> Root AC ---- PE 1 ----- PW 1 -------- PE 2 ----- Leaf _AC >> | \ / || >> | \ /=3D=3D=3DPW 6,7=3D=3D=3D || >> PW 2 -----PW 5------\ || >> | /----Root PW 3 --- \ || >> Root _AC ---- PE 3 PE 4 ------ Root AC >> | \ / | >> | ----Leaf PW 4----- | >> Leaf AC Leaf AC >> Yes, on PE 3 there are several PWs, but if you want to clarify it, >> there are only 3 types, one can carry frames originated from Root and >> Leaf AC(one endpoint of this PW should be Root-only, otherwise this is >> invalid), one only can carry frames from Root AC, and the last can >> carry frames from Leaf ACs. On second thoughts, we still can classify >> the PWs into 2 sets, one is Leaf set, and another is Root set, and the >> union of the sets Leaf and Root is the PW we called it as compatible >> PW (Maybe this is not correct, we can find one good term on this). >> >> So this optimization still follows the original design of Dual-PW >> approach, Leaf PW only carries frames from Leaf AC; Root-PW only >> carries frames from Root AC. Is it right? >> >> I don't know whether chip can support this forwarding behavior for >> compatible PW or not, but if we implement it in NP, it is nearly same >> as VPLS. The only difference is, setup 2 mappings, one between >> Leaf-ACs and Leaf-PWs, one between Root-ACs and Root-PWs. For >> traditional VPLS, there is only one mapping. >> >> [JY] It seems you may need a 3rd mapping: from both root & leaf AC to >> a compatible PW. >> BTW, for the forwarding and reverse direction, the mapping may be >> asymmetric for you compatible PW. >> >> Based on my understanding, all drafts should have similar mapping. >> >> [JY] Dual-VLAN seems simpler here. >> >> Thanks, >> >> Sam >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 3:32 PM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, >> >> Thanks, please see my further comments with [JY]. >> >> Ok, we go on the case in your mail, where PE1 has one Root-only AC, >> AC1, and >> PE2 has one Leaf-only AC, AC2. In general we can setup 2 >> "unidirectional" >> PWs (bidirectional PW, but just carry unidirectional frames), Root-PW >> which carries frames originated from AC1 and Leaf-PW which carries >> frames originated from AC2. But only one PW also can work, just as >> some members commented. Ok, we setup one PW between PE1 and PE2, we >> can call this PW as compatible PW or something else. Frames originated >> from Root or leaf ACs will be carried via this PW. Its forwarding >> behavior is fully same as what traditional VPLS did, MAC learning on >> AC or PW in one E-Tree. Or say, if one PE has Root-only ACs, it will >> setup one PW with another PE, Root-only, Leaf-only or Root-Leaf-Mixed. >> If 2 PEs are root-Leaf-Mixed or other cases, then 2 PWs will be >> established. As you know, this can be done on control plane. >> >> [JY] Assume there are 2 other nodes PE3 & PE4 in this network >> scenario, and both PE3 and PE4 have both root and leaf ACs, then there >> are compatible PWs from PE3 which may carry both root and leaf traffic >> (to PE1), which may carry only root traffic (to PE2); and further >> there are root PW and leaf PW to PE4. Thus, the VSI on PE3 has at >> least 4 different types of PW transmitting behaviours with regard to >> the E-Tree traffic. In the reverse direction, the VSI on PE3 further >> has at least >> 4 different types of PW receiving behaviours. Not sure how you will >> accommodate for these PWs in both the data plane and control plane. >> >> Regards, >> Yuanlong >> >> Is this clear for you? Is this necessary to optimize PW setup in this >> case? >> >> Maybe we need to add one paragraph on forwarding behavior. >> >> Again thank you very much for your comments, >> >> Sam >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Tuesday, May 15, 2012 10:27 AM >> To: Sam Cao; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Please see my comments in line. >> >> -----Original Message----- >> From: Sam Cao [mailto:yuqun.cao@gmail.com] >> Sent: Monday, May 14, 2012 8:31 PM >> To: Jiangyuanlong; 'Daniel Cohn'; 'Alexander Vainshtein' >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> We have discussed this in another thread. In fact, Daniel or I have >> given the answers to the questions you raised here for several time :). >> If we do in this way, we will reach deadlock and can not move forward >> :). I try to explain it again. >> >> [JY] I will apologize if you had ever provided such answers before, >> and you may just refer to the links rather than repeat the explanation. >> As you can see, I just try to understand the mechanism of 2PW and its >> implications, but the I-D does not include enough information. >> >> As you know, initial design we will setup 2 PWs all the time (if do in >> this way, I think that you have no question), >> >> [JY] I will be concerned with the operational complexity of this >> approach. >> >> but in most cases 2 PWs are not >> necessary. So in 01 version, we optimize it. >> >> "Root-only VSI <-> any VSI: only root PW required" >> "Leaf-only VSI <-> leaf-only VSI: no PWs required" >> >> In other cases 2 PWs are needed. If so, "Leaf-only -> root-only =3D one >> leaf PW" is not correct: On Leaf-only side, yes, one Leaf-only PW is >> created between Local Leaf type with remote Root type; on root-only >> side, one root-only PW is created. Maybe it is better to call this as >> compatible or mixed PW. So the left items you list are not correct for >> multi_PW solution. >> >> [JY] This is something new, right? To be honest, I could not >> understand what is your point: doesn't the mixed PW as you called also >> consist of one Leaf-only PW in one direction and one root-only PW in >> the other direction? >> Furthermore, the case you took is also one case in your guideline >> "Root-only VSI <-> any VSI: only root PW required", don't you think >> that only one root PW is required following this guideline? >> Actually, I don't care much about what is the bidirectional PW or >> unidirectional PW called, but how can a VSI support such a mixed >> scenarios: >> traditional VSI assumes only one PW is required for each peer VSI, and >> its MAC leaning is based on bidirectional PW. But for 2PW, there are >> bidirectional root PW, bidirectional leaf PW, mixed PW, etc..., how to >> support these kinds of PWs in the same VSI is my top concern. >> >> BTW, I guess you also care this case we also have discussed before: >> for example, if we configure one Leaf AC on root-only PE (then it will >> be root-leaf-mixed PE), we will teardown the compatible PW and >> re-setup PWs again with 01. >> [JY] This was discussed in the emails indeed. >> >> Regards, >> >> Yuqun (Sam) Cao >> E-mail: Yuqun.cao@gmail.com >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 7:10 PM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel, >> >> Fine, now it seems more in line with what we had proposed in 2VLAN: a >> spoke PW behaves like root/leaf AC for a PE-r. >> >> But the same problem may also apply to the root/spoke "core PW" for >> Multi-PW: >> According to Multi-PW, only one PW is required between two PEs except >> when both PEs are mixed with root and leaf, so these PWs may be formed >> by combinations of the following unidirectional PW cases (extracted >> and adapted from Josh's email): >> Root-only -> any VSI =3D one root PW >> Leaf-only -> root-only =3D one leaf PW >> Leaf-only -> mixed =3D one leaf PW >> Mixed -> root-only =3D one (root+leaf) PW Mixed -> leaf-only =3D one >> (root+leaf) PW >> >> I have a concern that the forwarding plane of PE to implement this >> will be very different from the traditional VPLS. >> >> Regards, >> Yuanlong >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 5:00 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> Like I wrote below, root/leaf spoke PW behave like root/leaf AC, not >> like root/spoke "core PW". So no changes to forwarding plane once this >> is understood. >> >> DC >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Monday, May 14, 2012 11:36 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Daniel, please see my comments in line. >> >> -----Original Message----- >> From: Daniel Cohn [mailto:DanielC@orckit.com] >> Sent: Monday, May 14, 2012 3:37 PM >> To: Jiangyuanlong; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Yuanlong, >> >> As I see it, for the PE-r spoke (figure 4 in RFC 4762) we establish a >> single PW per AC - root PW for root AC and leaf PW for leaf AC. With >> local configuration at the PE-rs as part of the spoke PW provisioning. >> And the PE-rs will treat root/leaf spoke PWs exactly as it treat >> root/leaf ACs. So when leaf-originated BUM traffic arrives from the >> core (over a leaf PW), it will be forwarded over all root spoke PWs >> but not on the leaf spoke PWs. >> >> [JY] So in the reverse direction, you need to transport both root and >> leaf traffic from PE-rs over a root PW to PE-r, and transport root >> traffic over a leaf PW. It seems against the definition of root PW and >> leaf PW in the multi-PW draft. Don't this make the forwarding plane of >> PE-rs more complex? >> >> The forwarding plane is exactly the same as described in the multi-PW >> draft, where spoke PWs are treated exactly like ACs. >> >> Regards, >> >> Daniel >> >> >> -----Original Message----- >> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] >> Sent: Friday, May 11, 2012 5:03 AM >> To: Daniel Cohn; Alexander Vainshtein; Sam Cao >> Cc: l2vpn@ietf.org >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Daniel and all, >> >> When you set up two PWs from the PE-rs to a PE-r for each of its AC, >> do you mean that one PW is bidirectional root PW and the other is >> bidirectional leaf PW? >> My concern is: where should the leaf traffic be filtered, on the PE-rs >> or on the PE-r? >> If filtered on the PE-r, then lots of bandwidth will be wasted (for >> example, if the PE-r is attached with 9 leafs, then the BUM traffic >> from one of its leafs will be multiplied by 8 times, and be forwarded >> by the PE-rs to the same PE-r). >> If filtered on the PE-rs, not sure how you will design its forwarding >> plane, can you give a hint? >> >> Thanks, >> Yuanlong >> >> ------------------------------ >> Date: Wed, 9 May 2012 09:16:36 +0300 >> From: "Daniel Cohn" >> To: "Alexander Vainshtein" , >>"Sam >> Cao" , >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> Message-ID: <44F4E579A764584EA9BDFD07D0CA08130780CBA6@tlvmail1> >> Content-Type: text/plain; charset=3D"ISO-2022-JP" >> >> Hi Sasha, >> >> It's actually very simple. A frame that originated in a root AC is >> always transmitted only in root PW, no matter what the frame type >> (known/unknown unicast or broadcast). This is how the frame source >> information is propagated across the VPLS. So in the H-VPLS example, >> the PE-r will never forward a frame received over a root PW on any >> leaf PW, only on root PWs (toward the core or toward other spokes). >> >> Hope this clarifies it, regards, >> >> Daniel >> >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >> Of Alexander Vainshtein >> Sent: Wednesday, May 09, 2012 7:59 AM >> To: Sam Cao; l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Sam, Lizhong and all, >> You've written that in the two-PW solution combined with H-VPLS the >> PE- r must set up two PWs with each MTU-s. >> >> If this is the case, what kind of forwarding logic should be used to >> prevent sending a BUM frame received from a root-PW to a given MTU-S: >> - back to the same MTU-S on the corresponding leaf-PW? >> - twice (to both root-PW and Leaf-PW) to another MTU-s? And, BTW, how >> is the PW selected in this case? >> >> I am aware of a technique of multiple split horizon groups in PE-r >> which could be possibly used for this purpose. However, since these >> groups have to be represented explicitly in the data plane, their >> potential number is limited by the forwarding HW. Other methods could >> be probably used for the same purpose, but they would probably subject >> to similar HW-based limitations. >> >> I suspect that with the dual-PW approach, the HW would pose an >> implicit limit, say, on a number of MTU-s that can be connected to the >> same PE-r and that this limit could be quite low in most cases. >> >> Based on this I suspect that the H-VPLS issue as a critical drawback >> of the dual-PW approach to E-Tree. >> >> My 2c, >> Sasha >> >> >> ________________________________________ >> From: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Sam >> Cao [yuqun.cao@gmail.com] >> Sent: Wednesday, May 09, 2012 3:40 AM >> To: l2vpn@ietf.org >> Cc: lizhong.jin@zte.com.cn >> Subject: RE: Discussion on E-Tree and H-VPLS >> >> Hi Lizhong? >> >> Thank you very much for your comments. I updated the result on this >> question. >> >> [Lizhong] agree with the above analysis. And we did not say it is a >> technical problem, but it is an operational problem again. >> [Sam] I agree. Dual-VLAN does not make sense. I also discussed this >> with Giles and Yuanlong in another mail, and we reached agreement on >> this: >> MTU should know the access mode, VPWS or VPLS, VPWS mode should >> configure VLAN ID on MTU but VPLS mode can not. I thought this is NOT >> reasonable :), but we can figure this out in draft. It seems ok. >> >> [Lizhong] not fully understand. Do you mean, when VPWS accessing for >> H-VPLS, the PE-r is also necessary to configure two PWs (root and leaf >> PW) for each AC access? >> [Sam] Yes. >> >> Thanks, >> >> Sam >> >> >> >> > > > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jiangyuanlong@huawei.com Fri Jun 15 00:05:34 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABBD21F86F7 for ; Fri, 15 Jun 2012 00:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 i-d32B7ag+pg for ; Fri, 15 Jun 2012 00:05:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAF521F86F6 for ; Fri, 15 Jun 2012 00:05:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGY14942; Fri, 15 Jun 2012 03:05:33 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 15 Jun 2012 00:02:42 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 15 Jun 2012 00:02:40 -0700 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.75]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Fri, 15 Jun 2012 15:02:23 +0800 From: Jiangyuanlong To: "l2vpn@ietf.org" Subject: Fwd: New Version Notification for draft-jiang-l2vpn-vpls-pe-etree-06.txt Thread-Topic: New Version Notification for draft-jiang-l2vpn-vpls-pe-etree-06.txt Thread-Index: AQHNSqxJIzbUrbSqWEuXED8TelXzsZb68vWQ Date: Fri, 15 Jun 2012 07:02:21 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B1D417658@szxeml546-mbs.china.huawei.com> References: <20120615040639.13074.49287.idtracker@ietfa.amsl.com> In-Reply-To: <20120615040639.13074.49287.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sajassi@cisco.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 07:05:34 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIHVwZGF0ZWQgdGhlIER1YWwtVkxBTiBJLUQgdG8gdmVyc2lvbiAw NiBub3csIHdoaWNoIGluY2x1ZGVzIGEgbmV3IFNlY3Rpb24gb24gT0FNIGNvbnNpZGVyYXRpb25z LCBhbmQgYSBkZXRhaWxlZCBCR1AgU2VjdGlvbi4NCkl0IGFsc28gcmVmbGVjdHMgc29tZSBkaXNj dXNzaW9ucyBoYXBwZW5lZCBkdXJpbmcgdGhlIGxhc3QgZmV3IG1vbnRocy4NClBsZWFzZSBoYXZl IGEgbG9vayBhdCBpdCwgeW91ciBjb21tZW50cyBhcmUgZ3JlYXRseSBhcHByZWNpYXRlZC4NCg0K VGhhbmtzLA0KWXVhbmxvbmcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANClNlbnQ6IEZyaWRheSwgSnVuZSAxNSwgMjAxMiAxMjowNyBQTQ0KVG86IEppYW5neXVhbmxv bmcNCkNjOiBzYWphc3NpQGNpc2NvLmNvbTsgZnJlZGVyaWMuam91bmF5QG9yYW5nZS5jaDsgbWFu dWVsLnBhdWxAdGVsZWtvbS5kZTsgZmxvcmluLmJhbHVzQGFsY2F0ZWwtbHVjZW50LmNvbTsgd2lt LmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tOyBMdWN5IHlvbmcNClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtamlhbmctbDJ2cG4tdnBscy1wZS1ldHJlZS0w Ni50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtamlhbmctbDJ2cG4tdnBscy1w ZS1ldHJlZS0wNi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWXVhbmxv bmcgSmlhbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC1qaWFuZy1sMnZwbi12cGxzLXBlLWV0cmVlDQpSZXZpc2lvbjoJIDA2DQpUaXRsZToJ CSBWUExTIFBFIE1vZGVsIGZvciBFLVRyZWUgU3VwcG9ydA0KQ3JlYXRpb24gZGF0ZToJIDIwMTIt MDYtMTQNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAy Mw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1qaWFuZy1sMnZwbi12cGxzLXBlLWV0cmVlLTA2LnR4dA0KU3RhdHVzOiAgICAgICAgICBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWppYW5nLWwydnBuLXZwbHMtcGUt ZXRyZWUNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt amlhbmctbDJ2cG4tdnBscy1wZS1ldHJlZS0wNg0KRGlmZjogICAgICAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWppYW5nLWwydnBuLXZwbHMtcGUtZXRyZWUt MDYNCg0KQWJzdHJhY3Q6DQogICBBIGdlbmVyaWMgVlBMUyBzb2x1dGlvbiBmb3IgRS1UcmVlIHNl cnZpY2VzIGlzIHByb3Bvc2VkIHdoaWNoIHVzZXMNCiAgIFZMQU5zIHRvIGluZGljYXRlIHJvb3Qv bGVhZiB0cmFmZmljLiBBIFZQTFMgUHJvdmlkZXIgRWRnZSAoUEUpIG1vZGVsDQogICBpcyBpbGx1 c3RyYXRlZCBhcyBhbiBleGFtcGxlIGZvciB0aGUgc29sdXRpb24uIEluIHRoZSBzb2x1dGlvbiwg RS0NCiAgIFRyZWUgVlBMUyBQRXMgYXJlIGludGVyY29ubmVjdGVkIGJ5ICBQV3Mgd2hpY2ggY2Fy cnkgdGhlIFZMQU4NCiAgIGluZGljYXRpbmcgdGhlIEUtVHJlZSBhdHRyaWJ1dGUsIHRoZSBNQUMg YWRkcmVzcyBiYXNlZCBFdGhlcm5ldA0KICAgZm9yd2FyZGluZyBlbmdpbmUgYW5kIHRoZSBQVyB3 b3JrIGluIHRoZSBzYW1lIHdheSBhcyBiZWZvcmUuIEENCiAgIHNpZ25hbGluZyBtZWNoYW5pc20g Zm9yIEUtVHJlZSBjYXBhYmlsaXR5IGFuZCBWTEFOIG1hcHBpbmcNCiAgIG5lZ290aWF0aW9uIGlz IGZ1cnRoZXIgZGVzY3JpYmVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg== From monikama@microsoft.com Fri Jun 15 09:27:29 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1A421F856C; Fri, 15 Jun 2012 09:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 MR8YDUhqwEtK; Fri, 15 Jun 2012 09:27:29 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id BC24721F8567; Fri, 15 Jun 2012 09:27:28 -0700 (PDT) Received: from mail27-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 16:26:17 +0000 Received: from mail27-va3 (localhost [127.0.0.1]) by mail27-va3-R.bigfish.com (Postfix) with ESMTP id BCADA3A03FF; Fri, 15 Jun 2012 16:26:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zf7Iz9371Ic89bh14ffI168aJ542M1432Izz1202hzz1033IL8275dhz2fh2a8h683h839h93fhd25hf0ah) Received-SPF: pass (mail27-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=monikama@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail27-va3 (localhost.localdomain [127.0.0.1]) by mail27-va3 (MessageSwitch) id 1339777576571132_6585; Fri, 15 Jun 2012 16:26:16 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.236]) by mail27-va3.bigfish.com (Postfix) with ESMTP id 7D984460100; Fri, 15 Jun 2012 16:26:16 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 16:26:15 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 15 Jun 2012 16:26:56 +0000 Received: from mail73-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 16:25:04 +0000 Received: from mail73-am1 (localhost [127.0.0.1]) by mail73-am1-R.bigfish.com (Postfix) with ESMTP id 5ED452E0209; Fri, 15 Jun 2012 16:25:04 +0000 (UTC) Received: from mail73-am1 (localhost.localdomain [127.0.0.1]) by mail73-am1 (MessageSwitch) id 1339777502712755_32715; Fri, 15 Jun 2012 16:25:02 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.235]) by mail73-am1.bigfish.com (Postfix) with ESMTP id 9BD09460048; Fri, 15 Jun 2012 16:25:02 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 16:25:02 +0000 Received: from BL2PRD0310MB385.namprd03.prod.outlook.com ([169.254.5.94]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0152.000; Fri, 15 Jun 2012 16:26:07 +0000 From: Monika Machado To: Xuxiaohu , "robert@raszuk.net" , Ivan Pepelnjak Subject: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNLdMSNuaNi6eFx0ePsz7p26HZqJbETDaAgDd+G1A= Date: Fri, 15 Jun 2012 16:26:06 +0000 Message-ID: <8449E89910CCB74488B8B95439667F13E718BE@BL2PRD0310MB385.namprd03.prod.outlook.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> <00fe01cd2dca$85427060$8fc75120$@com> <4FAA4E84.4090803@raszuk.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F215E6@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F215E6@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUAWEI.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%RASZUK.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Fri, 15 Jun 2012 09:40:30 -0700 Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:27:30 -0000 SGkgWGlhb2h1LQ0KDQpUaGlzIGlzIGEgdmVyeSBpbnRlcmVzdGluZyBkcmFmdC4gDQpJIGhhdmVu J3Qgc2VlaW5nIGEgbG90IG9mIGNvbW1lbnRzIG9uIHRoaXMsIGRvIHlvdSBoYXZlIGFueSB1cGRh dGUgaG93IGl0IGlzIHByb2dyZXNzaW5nPyBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBWUkYsIGlm IHRoZSB0dW5uZWwgdGVybWluYXRpb24gd291bGQgYmUgYm91bmQgdG8gYSBWUkYsIGlzIHRoZXJl IGFueSBtZWNoYW5pc20gdG8gc2lnbmFsIHdoYXQgcm91dGluZyB0YWJsZSBkb2VzIHRoZSBsb29r dXAgbmVlZHMgdG8gaGFwcGVuPyBEbyB3ZSBuZWVkIGEgc2V0IG9mIHNvdXJjZS9kZXN0IHBhaXJz IHBlciBWUkY/DQoNClRoYW5rcw0KTW9uaWthDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBsM3Zwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDN2cG4tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQpTZW50OiBGcmlkYXksIE1heSAxMSwgMjAxMiAx OjU2IEFNDQpUbzogcm9iZXJ0QHJhc3p1ay5uZXQ7IEl2YW4gUGVwZWxuamFrDQpDYzogbDJ2cG5A aWV0Zi5vcmc7IEtlc2hhdmEgQSBLOyBudm8zQGlldGYub3JnOyBsM3ZwbkBpZXRmLm9yZw0KU3Vi amVjdDogcmU6IFtudm8zXSBGYWNpbGl0YXRpbmcgdGhlIGxvYWQtYmFsYW5jaW5nIG9mIEwyVlBO L0wzVlBOIHRyYWZmaWMgb3ZlciBJUCBQU04gdXNpbmcgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlv bi8vIGZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1tcGxzLWluLXVk cC0wMC50eHQNCg0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBSb2Jl cnQgUmFzenVrIFttYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXRdDQo+IOWPkemAgeaXtumXtDogMjAx MuW5tDXmnIg55pelIDE5OjAxDQo+IOaUtuS7tuS6ujogSXZhbiBQZXBlbG5qYWsNCj4g5oqE6YCB OiBLZXNoYXZhIEEgSzsgbDJ2cG5AaWV0Zi5vcmc7IFh1eGlhb2h1OyBudm8zQGlldGYub3JnOyAN Cj4gbDN2cG5AaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW252bzNdIEZhY2lsaXRhdGluZyB0aGUg bG9hZC1iYWxhbmNpbmcgb2YgTDJWUE4vTDNWUE4gdHJhZmZpYyANCj4gb3ZlciBJUCBQU04gdXNp bmcgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbi8vIGZ3ZDogTmV3IFZlcnNpb24gDQo+IE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQteHUtbXBscy1pbi11ZHAtMDAudHh0DQo+IA0KPiBIaSBJdmFuLA0K PiANCj4gPiBUcnVlLCBidXQgdGhlbiB5b3UgbmVlZCBhIG1lY2hhbmlzbSB0byBkaXNjb3ZlciBh bGwgdGhlIGF2YWlsYWJsZSANCj4gPiBlbmRwb2ludHMsIHdoZXJlYXMgd2l0aCBzaW5nbGUgVlRF UCBwZXIgaG9zdCB5b3UgY2FuIHVzZSBleGlzdGluZyANCj4gPiBtZWNoYW5pc21zIChlaXRoZXIg bGVhcm5pbmcgZnJvbSBzb3VyY2UgSVAgYWRkcmVzcyBvciBuZXh0LWhvcCANCj4gPiBkaXN0cmli dXRpb24gd2l0aCBCR1AtbGlrZSBwcm90b2NvbHMpLg0KPiANCj4gVHJ1ZS4NCj4gDQo+IEkgc2Vl IGZldyBvcHRpb25zOg0KPiANCj4gLSBTaWduYWwgZGlmZmVyZW50IG5leHQgaG9wcyBpbiBCR1Ag Zm9yIHRoZSBhcHBsaWNhdGlvbiB3aGljaCBydW5zIA0KPiBhY3Jvc3MNCj4gDQo+IC0gVHJlYXQg bmV4dCBob3AgaW4gQkdQIGFzIHByZWZpeCBpbmRpY2F0b3Igbm90IGFzIGhvc3Qgcm91dGUuIElu IA0KPiBwYXJ0aWN1bGFyIG5leHQgaG9wIHJlc29sdmVzIGluIElHUCB0byBhIHByZWZpeCB3aGlj aCBpbiB0dXJuIGNvdWxkIGJlIA0KPiB1c2VkIGFzIHNldCBvZiBHUkUgZGVzdGluYXRpb24gYWRk cmVzc2VzDQo+IA0KPiAtIFNpZ25hbCBzdWNoIHJhbmdlIGV4cGxpY2l0bHkuIEkgdGhpbmsgdGhl cmUgd2lsbCBiZSBhIGRyYWZ0IGNvbWluZyANCj4gdXAgb24ganVzdCB0aGF0IHNvb24uDQoNCkhp IGFsbCwNCg0KVGhlIGRyYWZ0IHRoYXQgUm9iZXJ0IG1lbnRpb25lZCBpcyBub3cgYXZhaWxhYmxl IGF0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWlkci10dW5uZWwtYWRkcmVz cy1wcmVmaXgtMDAuICBBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0K DQpCVFcsIHRoYW5rcyBSb2JlcnQgZm9yIHlvdXIgcHJlLWFubm91bmNlbWVudCBvZiB0aGlzIGRy YWZ0IDspDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQoNCg== From giles.heron@gmail.com Fri Jun 15 09:57:01 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8918F21F84A0 for ; Fri, 15 Jun 2012 09:57:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBJcyoeUceiG for ; Fri, 15 Jun 2012 09:57:01 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACAFE21F847E for ; Fri, 15 Jun 2012 09:57:00 -0700 (PDT) Received: by eekd4 with SMTP id d4so1131547eek.31 for ; Fri, 15 Jun 2012 09:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=bUUvy8SynVg6p/n5sfTWM7LeDYpZa+ASP/I2q21jE5U=; b=eaeN4OzyYXUauXfZiWdSeQ+ww49C5z56ViOJC1S0AC0dwxGrY3eTENSJH/wsg09DK7 QqoN8ZGnrLchmWu4lEfIqd9PGrykvbr2gFIBWNSWmuKUN4YdwfTeqolyBwQhVnnSUzHO GJCA/yrhUyw2ObpEFScq6a61Xn0Wd4+uHo24WtuPUL93o3m8stlWnKdOuY3UU8x8QHtt 5KUVMK2pJz1AeMD1+Lds+QgS6BIO+AKWiuVDN56IuCM9hiRQKwUBnbIKPSrOLKEIBiLS 9fEc2K6x4GMUldleSkKJv7qY7k2xZscdizH3Y7Pvu57LcUXPZ7VWiwph2BEt+VmXRHvX bjeg== Received: by 10.14.94.201 with SMTP id n49mr1562024eef.158.1339779419605; Fri, 15 Jun 2012 09:56:59 -0700 (PDT) Received: from [10.147.57.33] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id v16sm31320558eem.17.2012.06.15.09.56.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 09:56:58 -0700 (PDT) User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Fri, 15 Jun 2012 17:56:53 +0100 Subject: Re: PBB E-VPN and TRILL From: Giles Heron To: Lucy yong , Balaji Venkat Venkataswami , "l2vpn@ietf.org" Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQAmBZ9AAAGW1qAADswyEAcXi6Wz In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D33107E1C@dfweml506-mbx> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "sajassi@cisco.com" , "stbryant@cisco.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:57:01 -0000 Hi Lucy, Sorry for the late response on this. It seems to me that there are 3 approaches here: (1) extend the IGP and nicknames over the WAN (your approach) (2) have per-DC IGP and extend nicknames over the WAN (the PBB-EVPN TRILL approach) (3) have per-DC IGP and nicknames (Balaji's approach). Those seem fundamentally very different in terms of scaling characteristics etc. Re your draft I think concerns were expressed at IETF82 in terms of it being simply interconnecting TRILL islands over VPLS or VPWS - so not necessarily being something that required a draft... Giles On 10/05/2012 15:35, "Lucy yong" wrote: > There is another draft to be considered. > > http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt > > Lucy > > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of > Balaji Venkat Venkataswami > Sent: Thursday, May 10, 2012 2:34 AM > To: giles.heron@gmail.com; l2vpn@ietf.org > Cc: sajassi@cisco.com; stbryant@cisco.com > Subject: PBB E-VPN and TRILL > > Hi Giles, > > I totally agree on this point. We have a solution that was presented to the > TRILL > working group as well on the interconnection of TRILL islands. We would like > to > concur with this and request for entering our draft as well into the solution > space. > > The URL for the TRILL draft is as follows. > http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 > > > thanks and regards, > balaji venkat > > Sent: Wednesday, May 09, 2012 6:04 PM > To: l2vpn@ietf.org > Cc: Ali Sajassi (sajassi); Stewart Bryant > Subject: PBB E-VPN and TRILL > > Ali presented the PBB-EVPN draft at IETF83 in Paris: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > > This has since been updated: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. > > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS and > PBB E-VPN probably sets a precedent (since PBB is also unmentioned by the > charter). > > On this basis we would like to ask the WG the following three questions: > > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? > > 2) is the WG happy for the authors to split the TRILL section of the PBB E-VPN > draft into a separate draft? > > 3) is the WG happy for the TRILL draft to be a WG doc? > > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us proceeding...) > > Giles > > From giles.heron@gmail.com Fri Jun 15 10:02:47 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B46621F85BD for ; Fri, 15 Jun 2012 10:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFByPFE2bEhR for ; Fri, 15 Jun 2012 10:02:46 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38B2921F85D3 for ; Fri, 15 Jun 2012 10:02:46 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1130969eaa.31 for ; Fri, 15 Jun 2012 10:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=Kjdccof3IdZIoj39uPe4Vc/lU0yZWYcWrYbygvZl7RI=; b=GHa4W5z+Y1ksE9b5ZS0dmx0G0GqI8A1lhx8ue9KAoxhG3jiUHMyGG3sEtQVSICtP4w 9wo816Emu9z2dtTzT3F2T+nTR8zvTT3rQMJwoEDwBqbpWZ+nL/LKpX4lkk1oFCfQbJGY jtH1geNSCbrUu0sG3StyJzOGVmhcXKp+agiUJDeHYFxIRtoMT5n0l+HlXPJBF0KQ01VL WavCOvuKAVJhCTC0qdWOL8LyzuDUGrHplrMVTz119L+ADcRn471fHySZu0Mya5AVf5x1 ZV3i+QXUc0Lwet6e7xf4cdhDRZJopgaC3xH9SxXAUmMgS6/HS9joNQDkS+eG4KYC32fE pamg== Received: by 10.14.94.73 with SMTP id m49mr1553569eef.224.1339779765080; Fri, 15 Jun 2012 10:02:45 -0700 (PDT) Received: from [10.147.57.33] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id u14sm32980996eem.4.2012.06.15.10.02.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 10:02:43 -0700 (PDT) User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Fri, 15 Jun 2012 18:02:39 +0100 Subject: Re: PBB E-VPN and TRILL From: Giles Heron To: Donald Eastlake , "l2vpn@ietf.org" , Lucy yong Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac1LGKteW1E645n76UShcUGcg87O6w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "stbryant@cisco.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:02:47 -0000 On 10/05/2012 18:56, "Donald Eastlake" wrote: > On Thu, May 10, 2012 at 10:35 AM, Lucy yong wrote: >> There is another draft to be considered. >>=20 >> http://tools.ietf.org/html/draft-yong-trill-trill-o-mpls-01.txt >=20 > There are a number of drafts but I think it is useful to make a > distinction between drafts that provide full connectivity between > TRILL switches (RBridges), so that they merge into a single TRILL > campus, and drafts that provide for data plane connectivity but > limited control plane connectivity for fault isolation, etc. >=20 > TRILL switches are routers. Like IP routers they logically strip the > link envelope from TRILL frames they receive and add a new, possible > different technology, link envelope on TRILL frames they send. Just as > it is possible to have an IP routed region where none of the > connections between IP routers is Ethernet but could be, for example, > PPP, it is possible to have a TRILL campus where none of the > connections between the RBridges is Ethernet but they are all some > other technology X, such as PPP. So, drafts that are "TRILL over X" > that are talking about full TRILL data and control plan connectivity > don't really seem to me to have much to do with L2VPN. Such drafts > should be done in either the TRILL WG or in the WG that does > technology X. I guess in this case VPLS and VPWS can be instances of "X". And they are i= n the L2VPN WG. So by your logic, and following the precedent of PWE3 WG working on Y over PWE for all values of Y, I suspect the work (if any) woul= d be done here. > It seems to me that L2VPN has to do with method that provide limited > data plane interconnection for better fault isolation. Agreed in general. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com >=20 >> Lucy >>=20 >> -----Original Message----- >> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf O= f >> Balaji Venkat Venkataswami >> Sent: Thursday, May 10, 2012 2:34 AM >> To: giles.heron@gmail.com; l2vpn@ietf.org >> Cc: sajassi@cisco.com; stbryant@cisco.com >> Subject: PBB E-VPN and TRILL >>=20 >> Hi =A0Giles, >>=20 >> I totally agree on this point. We have a solution that was presented to = the >> TRILL >> working group as well on the interconnection of TRILL islands. We would = like >> to >> concur with this and request for entering our draft as well into the sol= ution >> space. >>=20 >> The URL for the TRILL draft is as follows. >> http://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 >>=20 >>=20 >> thanks and regards, >> balaji venkat >>=20 >> Sent: Wednesday, May 09, 2012 6:04 PM >> To: l2vpn@ietf.org >> Cc: Ali Sajassi (sajassi); Stewart Bryant >> Subject: PBB E-VPN and TRILL >>=20 >> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>=20 >> This has since been updated: >>=20 >> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>=20 >> During our discussions Ali mentioned that the authors would like the TRI= LL >> section of the draft to be separated out into a separate draft. =A0In resp= onse >> Stewart questioned whether interconnecting TRILL islands is in-scope for >> L2VPN. >>=20 >> Stewart, Nabil and I have just been discussing these issues. =A0Whilst TRI= LL >> interconnect is not explicitly in-charter for L2VPN it would appear to b= e >> implicitly in-charter - our decision to standardise solutions for PBB VP= LS >> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned b= y the >> charter). >>=20 >> On this basis we would like to ask the WG the following three questions: >>=20 >> 1) is the WG happy for us to pursue interconnection of TRILL islands ove= r >> L2VPN? >>=20 >> 2) is the WG happy for the authors to split the TRILL section of the PBB >> E-VPN draft into a separate draft? >>=20 >> 3) is the WG happy for the TRILL draft to be a WG doc? >>=20 >> Please respond by May 22nd if you are unhappy with any of these 3 action= s >> (I'll take no response to mean the WG is in agreement with us proceeding= ...) >>=20 >> Giles >>=20 >>=20 From giles.heron@gmail.com Fri Jun 15 10:04:05 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC7B21F84E1 for ; Fri, 15 Jun 2012 10:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAkfFfAaymuN for ; Fri, 15 Jun 2012 10:04:04 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF63621F85CE for ; Fri, 15 Jun 2012 10:04:03 -0700 (PDT) Received: by eekd4 with SMTP id d4so1133702eek.31 for ; Fri, 15 Jun 2012 10:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=QlvmXh2f3RRjkbLfRI1zNSd+EcGxwJBWPkkQwGmCaiY=; b=TxpM0nE5/B+gUHb4ksjrS9Ej590fCW2p5N2j/oNAcFXGSL2TfOpgpAzfnjP9nqEUu7 4hP/GwcHu9CZFWf7KeybJHLVMOPBVx3kbfaIVzEFtreOJvA0SL1gwjsonuH8r72jUafY 2bSdQJkt9UGl+/5rwLPm3irBTmF/OwrBIj+pdDP2YPclbSqkuqOqK8s6nvNCYoa/a/uA NXsg435+uotj2nGw3hH2o4iBbKdlRrVrOVeTtoNxoL9HoW1EBWLbIBCektZZeEO5mzn+ sUNYG+FylBcijfeR/a77nV1BmoSRbeQfXTObOyz5ChQPpARt5v63BvCxIXZEyzX2+7pO YUyw== Received: by 10.14.189.12 with SMTP id b12mr1461962een.140.1339779842948; Fri, 15 Jun 2012 10:04:02 -0700 (PDT) Received: from [10.147.57.33] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id q53sm32971908eef.8.2012.06.15.10.04.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 10:04:01 -0700 (PDT) User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Fri, 15 Jun 2012 18:03:51 +0100 Subject: Re: PBB E-VPN and TRILL From: Giles Heron To: Sam Aldrin , Ali Sajassi Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac1LGNZIRnxK6eX3hUiVrtvZ2v/3JQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "l2vpn@ietf.org" , "Stewart Bryant \(stbryant\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:04:05 -0000 On 10/05/2012 20:57, "Sam Aldrin" wrote: > I do not agree that It is just a name change of the document. > > As far as the content goes, there is lot more to just BGP route. > All the content w.r.t unicast forwarding, multicast forwarding etc was added > recently. Atleast it was not present when the document was adopted as WG one. > > So, without taking groups consensus for WG adoption is not right, IMO. As the > content is more TRILL specific, it should be polled within that WG as well. I'm not sure we'd poll an L2VPN WG doc in another WG? But we can certainly ask other WGs for comments. > -sam > On May 10, 2012, at 12:41 PM, Ali Sajassi wrote: > >> >> When the doc was adopted as WG draft over 14 months ago, BGP route >> definition and procedures for TRILL DCI were already in place. >> >> It seems like we are having all these email exchanges for a name change of a >> WG doc !! >> >> -Ali >> >> On 5/10/12 11:12 AM, "Sam Aldrin" wrote: >> >>> As I mentioned in my other email, the split document should be asked for WG >>> adoption. It may not be for pbb content but for the TRILL content it should >>> be >>> done. When the doc was adopted as WG doc, trill content was minimal. >>> >>> Sam >>> >>> Sent from my iPhone >>> >>> On May 10, 2012, at 10:59 AM, "Shah, Himanshu" wrote: >>> >>>> Followings are the questions... >>>> >>>> 2) is the WG happy for the authors to split the TRILL section of the PBB >>>> E-VPN draft into a separate draft? >>>> >>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>> >>>> I think we are discussing splitting the trill section as a separate draft >>>> and >>>> making it a WG doc. >>>> >>>> What am I missing? >>>> >>>> /himanshu >>>> >>>> -----Original Message----- >>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>> Sent: Thursday, May 10, 2012 1:53 PM >>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); >>>> Giles >>>> Heron; l2vpn@ietf.org >>>> Cc: Stewart Bryant (stbryant) >>>> Subject: Re: PBB E-VPN and TRILL >>>> >>>> >>>>> >>>>> Based on my understanding, all the proposals are considered BEFORE >>>>> one is picked (with or without consolidation) for WG doc. >>>> >>>> One proposal is already part of WG draft. Would you please read the draft >>>> and then comment. >>>> >>>> Cheers, >>>> Ali >>>> >>>>> >>>>> Thanks, >>>>> himanshu >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>>> Sent: Thursday, May 10, 2012 1:28 PM >>>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); >>>>> Giles >>>>> Heron; l2vpn@ietf.org >>>>> Cc: Stewart Bryant (stbryant) >>>>> Subject: Re: PBB E-VPN and TRILL >>>>> >>>>> Hi Himanshu, >>>>> >>>>> I think every draft should be evaluated based on its own merits and if it >>>>> is >>>>> warranted there can be several drafts on this space. >>>>> >>>>> Cheers, >>>>> Ali >>>>> >>>>> >>>>> On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: >>>>> >>>>>> Hi Ali - >>>>>> >>>>>> Correct. >>>>>> >>>>>> But within the context of previous two, which questions whether to >>>>>> consider interconnecting TRILL islands via L2VPN as part of WG charter, I >>>>>> think you >>>>>> would agree that once TRILL portion is split from your base document, >>>>>> it might be worth to check if other proposals has merits. >>>>>> >>>>>> Saying differently, if your split TRILL doc becomes WG doc at the same >>>>>> time >>>>>> we >>>>>> include this work in the charter, other proposals would have no chance to >>>>>> be >>>>>> even considered..:-( >>>>>> >>>>>> IMHO - himanshu >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>>>> Sent: Thursday, May 10, 2012 12:47 PM >>>>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare); >>>>>> Giles >>>>>> Heron; l2vpn@ietf.org >>>>>> Cc: Stewart Bryant (stbryant) >>>>>> Subject: Re: PBB E-VPN and TRILL >>>>>> >>>>>> Himanshu, >>>>>> >>>>>> PBB-EVPN is already a WG draft! And the TRILL portion of it has been >>>>>> presented to L2VPN WG and has been in discussions for quite some time. >>>>>> All >>>>>> we are doing is separating SPB/PBB from TRILL - nothing new is getting >>>>>> added. Whereas, the other drafts are all new and they came about during >>>>>> last >>>>>> IETF meeting. >>>>>> >>>>>> -Ali >>>>>> >>>>>> >>>>>> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >>>>>> >>>>>>> Yes to first 2. >>>>>>> >>>>>>> As for 3rd, before we induct the stated draft as WG doc, we should >>>>>>> consider >>>>>>> other two proposals >>>>>>> mentioned in the mailing list, as part of due diligence. This is the >>>>>>> only >>>>>>> fair >>>>>>> way, and in fact, >>>>>>> consideration to responses to third question be postponed until other >>>>>>> proposals have been given >>>>>>> chance to be reviewed at the WG, IMO. >>>>>>> >>>>>>> /himanshu >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>>>>> Of >>>>>>> Henderickx, Wim (Wim) >>>>>>> Sent: Thursday, May 10, 2012 12:27 PM >>>>>>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>> Subject: RE: PBB E-VPN and TRILL >>>>>>> >>>>>>> Same, yes to all 3 >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>>>>> Of >>>>>>> Santiago Alvarez (saalvare) >>>>>>> Sent: donderdag 10 mei 2012 18:26 >>>>>>> To: Giles Heron; l2vpn@ietf.org >>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>> Subject: RE: PBB E-VPN and TRILL >>>>>>> >>>>>>> Yes to all three. >>>>>>> >>>>>>> SA >>>>>>> -- >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf >>>>>>> Of >>>>>>>> Giles Heron >>>>>>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>>>>>> To: l2vpn@ietf.org >>>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>>> Subject: PBB E-VPN and TRILL >>>>>>>> >>>>>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>>>>> >>>>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>>>>> >>>>>>>> This has since been updated: >>>>>>>> >>>>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>>>>> >>>>>>>> During our discussions Ali mentioned that the authors would like the >>>>>>> TRILL >>>>>>>> section of the draft to be separated out into a separate draft. In >>>>>>> response >>>>>>>> Stewart questioned whether interconnecting TRILL islands is in-scope >>>>>>> for >>>>>>>> L2VPN. >>>>>>>> >>>>>>>> Stewart, Nabil and I have just been discussing these issues. Whilst >>>>>>> TRILL >>>>>>>> interconnect is not explicitly in-charter for L2VPN it would appear to >>>>>>> be >>>>>>>> implicitly in-charter - our decision to standardise solutions for PBB >>>>>>> VPLS >>>>>>>> and PBB E-VPN probably sets a precedent (since PBB is also unmentioned >>>>>>> by >>>>>>>> the charter). >>>>>>>> >>>>>>>> On this basis we would like to ask the WG the following three >>>>>>> questions: >>>>>>>> >>>>>>>> 1) is the WG happy for us to pursue interconnection of TRILL islands >>>>>>> over >>>>>>>> L2VPN? >>>>>>>> >>>>>>>> 2) is the WG happy for the authors to split the TRILL section of the >>>>>>> PBB E- >>>>>>>> VPN draft into a separate draft? >>>>>>>> >>>>>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>>>> >>>>>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>>>>> actions >>>>>>>> (I'll take no response to mean the WG is in agreement with us >>>>>>> proceeding...) >>>>>>>> >>>>>>>> Giles >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From aldrin.ietf@gmail.com Fri Jun 15 10:06:28 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CBC21F8620 for ; Fri, 15 Jun 2012 10:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSsjLz+jcRRt for ; Fri, 15 Jun 2012 10:06:24 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0810F21F85D3 for ; Fri, 15 Jun 2012 10:06:21 -0700 (PDT) Received: by dacx6 with SMTP id x6so4304418dac.31 for ; Fri, 15 Jun 2012 10:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=Y1kGTrO7J8CXusIO9/uC6e3K22mR+j0UYbyPMALFRHo=; b=bYrafQit5IrBHdzlrUS5MmJRtz6cjybJUoDhfGBBCKBaSxaYc9i2NhHLg8/1j9/brj AlJh+K9VHifAyMOKp+oQcqEHpHgBkvqiJH6ctymjZAo01dB629LUa3z9moivnwQK015w HBYJ34k7Ok10egW4VC3kcvBBLchAoPEOFqPn7NwxPUMNbKT0vhPI8HqO23GbIvI7WsNY AiRBLAmCYHG6s6Tww25qaoyEtv1ACPVQ4tPD5TMF2hHzP3A0WJnqOdOE2a0svy9QJ+M3 fhw5qbZGqbDI6IEE2JufT3EE54GFjqctbZbdEfLqkIvXrI2yIgrLzZhzmz6jD6Snr7CQ D6zA== Received: by 10.68.228.102 with SMTP id sh6mr19247360pbc.134.1339779980630; Fri, 15 Jun 2012 10:06:20 -0700 (PDT) Received: from [192.168.1.4] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id ny4sm13800032pbb.57.2012.06.15.10.06.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 10:06:19 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <685E8F85-63AD-471A-ADDB-85B4554E91AD@gmail.com> X-Mailer: iPad Mail (9B206) From: Sam Aldrin Subject: Re: PBB E-VPN and TRILL Date: Fri, 15 Jun 2012 10:06:17 -0700 To: Giles Heron Cc: "l2vpn@ietf.org" , Ali Sajassi , "Stewart Bryant \(stbryant\)" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:06:29 -0000 Hi Giles, I replied in subsequent email that my understanding is wrong. I fully support the document and it's adoption. Cheers Sam Sent from my iPad On Jun 15, 2012, at 10:03 AM, Giles Heron wrote: > On 10/05/2012 20:57, "Sam Aldrin" wrote: >=20 >> I do not agree that It is just a name change of the document. >>=20 >> As far as the content goes, there is lot more to just BGP route. >> All the content w.r.t unicast forwarding, multicast forwarding etc was ad= ded >> recently. Atleast it was not present when the document was adopted as WG o= ne. >>=20 >> So, without taking groups consensus for WG adoption is not right, IMO. As= the >> content is more TRILL specific, it should be polled within that WG as wel= l. >=20 > I'm not sure we'd poll an L2VPN WG doc in another WG? But we can certainl= y > ask other WGs for comments. >=20 >> -sam >> On May 10, 2012, at 12:41 PM, Ali Sajassi wrote: >>=20 >>>=20 >>> When the doc was adopted as WG draft over 14 months ago, BGP route >>> definition and procedures for TRILL DCI were already in place. >>>=20 >>> It seems like we are having all these email exchanges for a name change o= f a >>> WG doc !! >>>=20 >>> -Ali >>>=20 >>> On 5/10/12 11:12 AM, "Sam Aldrin" wrote: >>>=20 >>>> As I mentioned in my other email, the split document should be asked fo= r WG >>>> adoption. It may not be for pbb content but for the TRILL content it sh= ould >>>> be >>>> done. When the doc was adopted as WG doc, trill content was minimal. >>>>=20 >>>> Sam >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On May 10, 2012, at 10:59 AM, "Shah, Himanshu" wrote:= >>>>=20 >>>>> Followings are the questions... >>>>>=20 >>>>> 2) is the WG happy for the authors to split the TRILL section of the P= BB >>>>> E-VPN draft into a separate draft? >>>>>=20 >>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>=20 >>>>> I think we are discussing splitting the trill section as a separate dr= aft >>>>> and >>>>> making it a WG doc. >>>>>=20 >>>>> What am I missing? >>>>>=20 >>>>> /himanshu >>>>>=20 >>>>> -----Original Message----- >>>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>>> Sent: Thursday, May 10, 2012 1:53 PM >>>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare)= ; >>>>> Giles >>>>> Heron; l2vpn@ietf.org >>>>> Cc: Stewart Bryant (stbryant) >>>>> Subject: Re: PBB E-VPN and TRILL >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Based on my understanding, all the proposals are considered BEFORE >>>>>> one is picked (with or without consolidation) for WG doc. >>>>>=20 >>>>> One proposal is already part of WG draft. Would you please read the dr= aft >>>>> and then comment. >>>>>=20 >>>>> Cheers, >>>>> Ali >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> himanshu >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>>>> Sent: Thursday, May 10, 2012 1:28 PM >>>>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvare= ); >>>>>> Giles >>>>>> Heron; l2vpn@ietf.org >>>>>> Cc: Stewart Bryant (stbryant) >>>>>> Subject: Re: PBB E-VPN and TRILL >>>>>>=20 >>>>>> Hi Himanshu, >>>>>>=20 >>>>>> I think every draft should be evaluated based on its own merits and i= f it >>>>>> is >>>>>> warranted there can be several drafts on this space. >>>>>>=20 >>>>>> Cheers, >>>>>> Ali=20 >>>>>>=20 >>>>>>=20 >>>>>> On 5/10/12 10:03 AM, "Shah, Himanshu" wrote: >>>>>>=20 >>>>>>> Hi Ali - >>>>>>>=20 >>>>>>> Correct.=20 >>>>>>>=20 >>>>>>> But within the context of previous two, which questions whether to >>>>>>> consider interconnecting TRILL islands via L2VPN as part of WG chart= er, I >>>>>>> think you >>>>>>> would agree that once TRILL portion is split from your base document= , >>>>>>> it might be worth to check if other proposals has merits. >>>>>>>=20 >>>>>>> Saying differently, if your split TRILL doc becomes WG doc at the sa= me >>>>>>> time >>>>>>> we >>>>>>> include this work in the charter, other proposals would have no chan= ce to >>>>>>> be >>>>>>> even considered..:-( >>>>>>>=20 >>>>>>> IMHO - himanshu >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Ali Sajassi [mailto:sajassi@cisco.com] >>>>>>> Sent: Thursday, May 10, 2012 12:47 PM >>>>>>> To: Shah, Himanshu; Henderickx, Wim (Wim); Santiago Alvarez (saalvar= e); >>>>>>> Giles >>>>>>> Heron; l2vpn@ietf.org >>>>>>> Cc: Stewart Bryant (stbryant) >>>>>>> Subject: Re: PBB E-VPN and TRILL >>>>>>>=20 >>>>>>> Himanshu, >>>>>>>=20 >>>>>>> PBB-EVPN is already a WG draft! And the TRILL portion of it has been= >>>>>>> presented to L2VPN WG and has been in discussions for quite some tim= e. >>>>>>> All >>>>>>> we are doing is separating SPB/PBB from TRILL - nothing new is getti= ng >>>>>>> added. Whereas, the other drafts are all new and they came about dur= ing >>>>>>> last >>>>>>> IETF meeting. >>>>>>>=20 >>>>>>> -Ali >>>>>>>=20 >>>>>>>=20 >>>>>>> On 5/10/12 9:38 AM, "Shah, Himanshu" wrote: >>>>>>>=20 >>>>>>>> Yes to first 2. >>>>>>>>=20 >>>>>>>> As for 3rd, before we induct the stated draft as WG doc, we should >>>>>>>> consider >>>>>>>> other two proposals >>>>>>>> mentioned in the mailing list, as part of due diligence. This is th= e >>>>>>>> only >>>>>>>> fair >>>>>>>> way, and in fact, >>>>>>>> consideration to responses to third question be postponed until oth= er >>>>>>>> proposals have been given >>>>>>>> chance to be reviewed at the WG, IMO. >>>>>>>>=20 >>>>>>>> /himanshu >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Beh= alf >>>>>>>> Of >>>>>>>> Henderickx, Wim (Wim) >>>>>>>> Sent: Thursday, May 10, 2012 12:27 PM >>>>>>>> To: Santiago Alvarez (saalvare); Giles Heron; l2vpn@ietf.org >>>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>>> Subject: RE: PBB E-VPN and TRILL >>>>>>>>=20 >>>>>>>> Same, yes to all 3 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Beh= alf >>>>>>>> Of >>>>>>>> Santiago Alvarez (saalvare) >>>>>>>> Sent: donderdag 10 mei 2012 18:26 >>>>>>>> To: Giles Heron; l2vpn@ietf.org >>>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>>> Subject: RE: PBB E-VPN and TRILL >>>>>>>>=20 >>>>>>>> Yes to all three. >>>>>>>>=20 >>>>>>>> SA >>>>>>>> -- >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Be= half >>>>>>>> Of >>>>>>>>> Giles Heron >>>>>>>>> Sent: Wednesday, May 09, 2012 5:34 AM >>>>>>>>> To: l2vpn@ietf.org >>>>>>>>> Cc: Ali Sajassi (sajassi); Stewart Bryant (stbryant) >>>>>>>>> Subject: PBB E-VPN and TRILL >>>>>>>>>=20 >>>>>>>>> Ali presented the PBB-EVPN draft at IETF83 in Paris: >>>>>>>>>=20 >>>>>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 >>>>>>>>>=20 >>>>>>>>> This has since been updated: >>>>>>>>>=20 >>>>>>>>> http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 >>>>>>>>>=20 >>>>>>>>> During our discussions Ali mentioned that the authors would like t= he >>>>>>>> TRILL >>>>>>>>> section of the draft to be separated out into a separate draft. I= n >>>>>>>> response >>>>>>>>> Stewart questioned whether interconnecting TRILL islands is in-sco= pe >>>>>>>> for >>>>>>>>> L2VPN. >>>>>>>>>=20 >>>>>>>>> Stewart, Nabil and I have just been discussing these issues. Whil= st >>>>>>>> TRILL >>>>>>>>> interconnect is not explicitly in-charter for L2VPN it would appea= r to >>>>>>>> be >>>>>>>>> implicitly in-charter - our decision to standardise solutions for P= BB >>>>>>>> VPLS >>>>>>>>> and PBB E-VPN probably sets a precedent (since PBB is also unmenti= oned >>>>>>>> by >>>>>>>>> the charter). >>>>>>>>>=20 >>>>>>>>> On this basis we would like to ask the WG the following three >>>>>>>> questions: >>>>>>>>>=20 >>>>>>>>> 1) is the WG happy for us to pursue interconnection of TRILL islan= ds >>>>>>>> over >>>>>>>>> L2VPN? >>>>>>>>>=20 >>>>>>>>> 2) is the WG happy for the authors to split the TRILL section of t= he >>>>>>>> PBB E- >>>>>>>>> VPN draft into a separate draft? >>>>>>>>>=20 >>>>>>>>> 3) is the WG happy for the TRILL draft to be a WG doc? >>>>>>>>>=20 >>>>>>>>> Please respond by May 22nd if you are unhappy with any of these 3 >>>>>>>> actions >>>>>>>>> (I'll take no response to mean the WG is in agreement with us >>>>>>>> proceeding...) >>>>>>>>>=20 >>>>>>>>> Giles >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>=20 >>=20 >=20 >=20 From xuxiaohu@huawei.com Sun Jun 17 18:58:49 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F61521F85D1; Sun, 17 Jun 2012 18:58:49 -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 YmXj3aRAm7eP; Sun, 17 Jun 2012 18:58:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 935C321F85DB; Sun, 17 Jun 2012 18:58:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHH02055; Sun, 17 Jun 2012 21:58:48 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 17 Jun 2012 18:57:46 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 17 Jun 2012 18:57:45 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.113]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Mon, 18 Jun 2012 09:57:33 +0800 From: Xuxiaohu To: Monika Machado , "robert@raszuk.net" , Ivan Pepelnjak Subject: re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Topic: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNLdMSNuaNi6eFx0ePsz7p26HZqJbETDaAgDd+G1CAA8I4oA== Date: Mon, 18 Jun 2012 01:57:32 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0751E73F@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F20BF9@szxeml525-mbs.china.huawei.com> <005a01cd2d9e$900f0ac0$b02d2040$@com> <4FAA1C30.6090303@raszuk.net> <00fe01cd2dca$85427060$8fc75120$@com> <4FAA4E84.4090803@raszuk.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F215E6@szxeml525-mbs.china.huawei.com> <8449E89910CCB74488B8B95439667F13E718BE@BL2PRD0310MB385.namprd03.prod.outlook.com> In-Reply-To: <8449E89910CCB74488B8B95439667F13E718BE@BL2PRD0310MB385.namprd03.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "l2vpn@ietf.org" , "nvo3@ietf.org" , "l3vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 01:58:49 -0000 DQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBNb25pa2EgTWFjaGFkbyBb bWFpbHRvOm1vbmlrYW1hQG1pY3Jvc29mdC5jb21dDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDbm nIgxNuaXpSAwOjI2DQo+IOaUtuS7tuS6ujogWHV4aWFvaHU7IHJvYmVydEByYXN6dWsubmV0OyBJ dmFuIFBlcGVsbmphaw0KPiDmioTpgIE6IGwydnBuQGlldGYub3JnOyBLZXNoYXZhIEEgSzsgbnZv M0BpZXRmLm9yZzsgbDN2cG5AaWV0Zi5vcmcNCj4g5Li76aKYOiBSRTogW252bzNdIEZhY2lsaXRh dGluZyB0aGUgbG9hZC1iYWxhbmNpbmcgb2YgTDJWUE4vTDNWUE4gdHJhZmZpYyBvdmVyIElQDQo+ IFBTTiB1c2luZyBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uLy8gZndkOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTAwLnR4dA0KPiANCj4gSGkg WGlhb2h1LQ0KPiANCj4gVGhpcyBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgZHJhZnQuDQo+IEkgaGF2 ZW4ndCBzZWVpbmcgYSBsb3Qgb2YgY29tbWVudHMgb24gdGhpcywgZG8geW91IGhhdmUgYW55IHVw ZGF0ZSBob3cgaXQgaXMNCj4gcHJvZ3Jlc3Npbmc/IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IFZS RiwgaWYgdGhlIHR1bm5lbCB0ZXJtaW5hdGlvbiB3b3VsZCBiZQ0KPiBib3VuZCB0byBhIFZSRiwg aXMgdGhlcmUgYW55IG1lY2hhbmlzbSB0byBzaWduYWwgd2hhdCByb3V0aW5nIHRhYmxlIGRvZXMg dGhlDQo+IGxvb2t1cCBuZWVkcyB0byBoYXBwZW4/IERvIHdlIG5lZWQgYSBzZXQgb2Ygc291cmNl L2Rlc3QgcGFpcnMgcGVyIFZSRj8NCg0KSGkgTW9uaWthLA0KDQpUaGUgZWdyZXNzIFBFIHJvdXRl ciBjb3VsZCBrbm93IHdoaWNoIFZSRiB0YWJsZSBzaG91bGQgYmUgdXNlZCBmb3Igcm91dGUgbG9v a3VwIGFjY29yZGluZyB0byB0aGUgVlBOIGxhYmVsIGNvbnRhaW5lZCBpbiB0aGUgcmVjZWl2ZWQg cGFja2V0LiBXZSBkb24ndCBuZWVkIGEgc2V0IG9mIHNyYy9kZXN0IHBhaXJzIHBlciBWUkYsIG9u IHRoZSBjb250cmFyeSwgYSBnaXZlbiBzcmMvZGVzdCBwYWlyIGNvdWxkIGJlIHNoYXJlZCBieSBt YW55IFZSRiBpbnN0YW5jZXMuDQoNCkkgd29uZGVyIHdoZXRoZXIgSSBoYXZlIHVuZGVyc3Rvb2Qg eW91ciBxdWVzdGlvbnMuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IFRoYW5rcw0KPiBN b25pa2ENCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGwzdnBuLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsM3Zwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YNCj4gWHV4aWFvaHUNCj4gU2VudDogRnJpZGF5LCBNYXkgMTEsIDIwMTIgMTo1NiBBTQ0KPiBU bzogcm9iZXJ0QHJhc3p1ay5uZXQ7IEl2YW4gUGVwZWxuamFrDQo+IENjOiBsMnZwbkBpZXRmLm9y ZzsgS2VzaGF2YSBBIEs7IG52bzNAaWV0Zi5vcmc7IGwzdnBuQGlldGYub3JnDQo+IFN1YmplY3Q6 IHJlOiBbbnZvM10gRmFjaWxpdGF0aW5nIHRoZSBsb2FkLWJhbGFuY2luZyBvZiBMMlZQTi9MM1ZQ TiB0cmFmZmljIG92ZXIgSVANCj4gUFNOIHVzaW5nIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24v LyBmd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQteHUtbXBscy1pbi11 ZHAtMDAudHh0DQo+IA0KPiANCj4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4g5Y+R5Lu2 5Lq6OiBSb2JlcnQgUmFzenVrIFttYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXRdDQo+ID4g5Y+R6YCB 5pe26Ze0OiAyMDEy5bm0NeaciDnml6UgMTk6MDENCj4gPiDmlLbku7bkuro6IEl2YW4gUGVwZWxu amFrDQo+ID4g5oqE6YCBOiBLZXNoYXZhIEEgSzsgbDJ2cG5AaWV0Zi5vcmc7IFh1eGlhb2h1OyBu dm8zQGlldGYub3JnOw0KPiA+IGwzdnBuQGlldGYub3JnDQo+ID4g5Li76aKYOiBSZTogW252bzNd IEZhY2lsaXRhdGluZyB0aGUgbG9hZC1iYWxhbmNpbmcgb2YgTDJWUE4vTDNWUE4gdHJhZmZpYw0K PiA+IG92ZXIgSVAgUFNOIHVzaW5nIE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24vLyBmd2Q6IE5l dyBWZXJzaW9uDQo+ID4gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1tcGxzLWluLXVkcC0wMC50 eHQNCj4gPg0KPiA+IEhpIEl2YW4sDQo+ID4NCj4gPiA+IFRydWUsIGJ1dCB0aGVuIHlvdSBuZWVk IGEgbWVjaGFuaXNtIHRvIGRpc2NvdmVyIGFsbCB0aGUgYXZhaWxhYmxlDQo+ID4gPiBlbmRwb2lu dHMsIHdoZXJlYXMgd2l0aCBzaW5nbGUgVlRFUCBwZXIgaG9zdCB5b3UgY2FuIHVzZSBleGlzdGlu Zw0KPiA+ID4gbWVjaGFuaXNtcyAoZWl0aGVyIGxlYXJuaW5nIGZyb20gc291cmNlIElQIGFkZHJl c3Mgb3IgbmV4dC1ob3ANCj4gPiA+IGRpc3RyaWJ1dGlvbiB3aXRoIEJHUC1saWtlIHByb3RvY29s cykuDQo+ID4NCj4gPiBUcnVlLg0KPiA+DQo+ID4gSSBzZWUgZmV3IG9wdGlvbnM6DQo+ID4NCj4g PiAtIFNpZ25hbCBkaWZmZXJlbnQgbmV4dCBob3BzIGluIEJHUCBmb3IgdGhlIGFwcGxpY2F0aW9u IHdoaWNoIHJ1bnMNCj4gPiBhY3Jvc3MNCj4gPg0KPiA+IC0gVHJlYXQgbmV4dCBob3AgaW4gQkdQ IGFzIHByZWZpeCBpbmRpY2F0b3Igbm90IGFzIGhvc3Qgcm91dGUuIEluDQo+ID4gcGFydGljdWxh ciBuZXh0IGhvcCByZXNvbHZlcyBpbiBJR1AgdG8gYSBwcmVmaXggd2hpY2ggaW4gdHVybiBjb3Vs ZCBiZQ0KPiA+IHVzZWQgYXMgc2V0IG9mIEdSRSBkZXN0aW5hdGlvbiBhZGRyZXNzZXMNCj4gPg0K PiA+IC0gU2lnbmFsIHN1Y2ggcmFuZ2UgZXhwbGljaXRseS4gSSB0aGluayB0aGVyZSB3aWxsIGJl IGEgZHJhZnQgY29taW5nDQo+ID4gdXAgb24ganVzdCB0aGF0IHNvb24uDQo+IA0KPiBIaSBhbGws DQo+IA0KPiBUaGUgZHJhZnQgdGhhdCBSb2JlcnQgbWVudGlvbmVkIGlzIG5vdyBhdmFpbGFibGUg YXQNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtaWRyLXR1bm5lbC1hZGRy ZXNzLXByZWZpeC0wMC4gIEFueQ0KPiBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNv bWUuDQo+IA0KPiBCVFcsIHRoYW5rcyBSb2JlcnQgZm9yIHlvdXIgcHJlLWFubm91bmNlbWVudCBv ZiB0aGlzIGRyYWZ0IDspDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCg0K From giles.heron@gmail.com Tue Jun 19 11:47:09 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C47421F85C5 for ; Tue, 19 Jun 2012 11:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHH338ANf9HG for ; Tue, 19 Jun 2012 11:47:08 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44EA921F85C4 for ; Tue, 19 Jun 2012 11:47:08 -0700 (PDT) Received: by eekd4 with SMTP id d4so2410375eek.31 for ; Tue, 19 Jun 2012 11:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=2Q6swO/xQsNLkIPqPTugrp09GbpDWI3YBGDGuNNrQZE=; b=ORb+kGpdeT6y9IPvqkI7aRJ+yK8I8Gh8p1KiDCpo7y8C1X3o3fJZQSOkI+siRXpX26 FwPnzonGk54rn1dSRwok4PwP5W+O8XOFEUKOEhFQsWUSNfbozyRSsgAIxi+37/h+1l36 YScKsTnpJ7L6a40qIBf6+2SyxAzPHJE1eL1coNCE4pv7rt3hoJX/4hpMt/Weittmep/n ZWchX03SuqVnHFDSKHlq2GX+xcaltwe+eSw8oY3ZdscULxcWertlcamuG/8qGwvFkraV jw7Y/qrqV4kYpdOGNgOUIv/SO2oA08m8UC7E03z980hocPNvSXDifIosVh8b3VNXeIYJ J/DA== Received: by 10.14.22.2 with SMTP id s2mr4740392ees.55.1340131627406; Tue, 19 Jun 2012 11:47:07 -0700 (PDT) Received: from [10.61.104.248] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id g46sm79634364eea.14.2012.06.19.11.47.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 11:47:05 -0700 (PDT) User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Tue, 19 Jun 2012 19:46:49 +0100 Subject: Re: PBB E-VPN and TRILL From: Giles Heron To: Message-ID: Thread-Topic: PBB E-VPN and TRILL Thread-Index: Ac0t4AvyMdWKxMA3AUSUMcn62xbEYQga9Zdt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "Ali Sajassi \(sajassi\)" , Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 18:47:09 -0000 Hi all, following recent discussions on the list I think we have strong consensus on items 1 and 2, and reasonable consensus on item 3. So on that basis Ali, could you please publish a new version of PBB-EVPN with no TRILL content, and also create draft-ietf-l2vpn-trill-evpn-00 for the TRILL content? We will be willing to consider other drafts that take a different approach to interconnecting TRILL islands over L2VPN (e.g. using nicknames per site instead of global nicknames) if these can be shown to be sufficiently compelling. Giles On 09/05/2012 13:34, "Giles Heron" wrote: > Ali presented the PBB-EVPN draft at IETF83 in Paris: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01 > > This has since been updated: > > http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-02 > > During our discussions Ali mentioned that the authors would like the TRILL > section of the draft to be separated out into a separate draft. In response > Stewart questioned whether interconnecting TRILL islands is in-scope for > L2VPN. > > Stewart, Nabil and I have just been discussing these issues. Whilst TRILL > interconnect is not explicitly in-charter for L2VPN it would appear to be > implicitly in-charter - our decision to standardise solutions for PBB VPLS > and PBB E-VPN probably sets a precedent (since PBB is also unmentioned by > the charter). > > On this basis we would like to ask the WG the following three questions: > > 1) is the WG happy for us to pursue interconnection of TRILL islands over > L2VPN? > > 2) is the WG happy for the authors to split the TRILL section of the PBB > E-VPN draft into a separate draft? > > 3) is the WG happy for the TRILL draft to be a WG doc? > > Please respond by May 22nd if you are unhappy with any of these 3 actions > (I'll take no response to mean the WG is in agreement with us proceeding...) > > Giles > > From internet-drafts@ietf.org Wed Jun 20 16:09:37 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C694B21F85A0; Wed, 20 Jun 2012 16:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 rVKmSLHGxLNY; Wed, 20 Jun 2012 16:09:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3782221F8573; Wed, 20 Jun 2012 16:09:37 -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 Subject: I-D Action: draft-ietf-l2vpn-pbb-evpn-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120620230937.31526.17130.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2012 16:09:37 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 23:09:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : PBB-EVPN Author(s) : Ali Sajassi Samer Salam Sami Boutros Nabil Bitar Aldrin Isaac Lizhong Jin Filename : draft-ietf-l2vpn-pbb-evpn-03.txt Pages : 20 Date : 2012-06-20 Abstract: This document discusses how Ethernet Provider Backbone Bridging [802.1ah] can be combined with E-VPN in order to reduce the number of BGP MAC advertisement routes by aggregating Customer/Client MAC (C- MAC) addresses via Provider Backbone MAC address (B-MAC), provide client MAC address mobility using C-MAC aggregation and B-MAC sub- netting, confine the scope of C-MAC learning to only active flows, offer per site policies and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. Conventions The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-pbb-evpn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-pbb-evpn-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jun 21 01:42:14 2012 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4229921F8582; Thu, 21 Jun 2012 01:42:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rpxxnkovb2z; Thu, 21 Jun 2012 01:42:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC46C21F8533; Thu, 21 Jun 2012 01:42:13 -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 Subject: I-D Action: draft-ietf-l2vpn-trill-evpn-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120621084213.23311.10555.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 01:42:13 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 08:42:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : TRILL-EVPN Author(s) : Ali Sajassi Samer Salam Sami Boutros Nabil Bitar Sam Aldrin Filename : draft-ietf-l2vpn-trill-evpn-00.txt Pages : 12 Date : 2012-06-20 Abstract: This document discusses how Ethernet VPN (E-VPN) technology is used to interconnect TRILL [TRILL] networks over an MPLS/IP network, with two key characteristics: C-MAC address transparency on the hand-off point and control-plane isolation among the interconnected TRILL networks. Conventions The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-trill-evpn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-trill-evpn-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/